Re: уязвимость OpenSSL
On Sun, Apr 13, 2014 at 05:19:53PM +0400, Victor Wagner wrote: > On 2014.04.13 at 13:53:17 +0100, Stanislav Maslovski wrote: > > > > Никаких "неинициализированных данных" там и близко нет, там выход за > > > границы. Почитайте лучше про суть атаки, чем фантазировать попусту. > > > > А что это меняет? По последствиям, выход за границы некой структуры в > > пределах общей heap - та же самая утечка, что и через неинициализированные > > данные. > > Не та же самая, а существенно хуже. Дело в том, что разработчики > криптографического софта имеют привычку перед тем как сделать free блоку > памяти, где лежал секретный ключ, затирать его нулями. И в OpenSSL тоже > есть и везде, где положено, применяется функция OPENSSL_cleanse. > > Поэтому чтобы в неинициализированную память попал ключ, кто-то должен > допустит ещё одну ошибку, кроме той, которая позволила эту память > прочитать > > > Безотносительно к конкретному программному механизму утечки, при достаточно > > долгом пассивном наблюдении за каналом и при наличии на руках проблемного > > исходного кода, из собранных данных, вероятно, можно восстановить те же > > самые "до 64 К" памяти поражённого процесса. Понятно, что это сделать > > Нельзя. Потому что благонамеренный софт не шлет пакетов у которых > payload_length не совпадает с актуальной длиной пересылаемых данных. Хорошо, допустим так. Исходники не читал. > "Причем пассивное наблюдение за каналом" это в данном случае MitM. Все это несколько обнадёживает, но... -- Stanislav -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140413133456.ga17...@kaiba.lan
Re: уязвимость OpenSSL
On 2014.04.13 at 13:53:17 +0100, Stanislav Maslovski wrote: > > Никаких "неинициализированных данных" там и близко нет, там выход за > > границы. Почитайте лучше про суть атаки, чем фантазировать попусту. > > А что это меняет? По последствиям, выход за границы некой структуры в > пределах общей heap - та же самая утечка, что и через неинициализированные > данные. Не та же самая, а существенно хуже. Дело в том, что разработчики криптографического софта имеют привычку перед тем как сделать free блоку памяти, где лежал секретный ключ, затирать его нулями. И в OpenSSL тоже есть и везде, где положено, применяется функция OPENSSL_cleanse. Поэтому чтобы в неинициализированную память попал ключ, кто-то должен допустит ещё одну ошибку, кроме той, которая позволила эту память прочитать > Безотносительно к конкретному программному механизму утечки, при достаточно > долгом пассивном наблюдении за каналом и при наличии на руках проблемного > исходного кода, из собранных данных, вероятно, можно восстановить те же > самые "до 64 К" памяти поражённого процесса. Понятно, что это сделать Нельзя. Потому что благонамеренный софт не шлет пакетов у которых payload_length не совпадает с актуальной длиной пересылаемых данных. "Причем пассивное наблюдение за каналом" это в данном случае MitM. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140413131953.ga28...@wagner.pp.ru
Re: уязвимость OpenSSL
On Sat, Apr 12, 2014 at 03:48:24PM +0400, Eugene Berdnikov wrote: > On Sat, Apr 12, 2014 at 11:46:09AM +0100, Stanislav Maslovski wrote: > > On Thu, Apr 10, 2014 at 10:38:43PM +0400, Eugene Berdnikov wrote: > > > Нет, heartbleed это уязвимость против активной атаки специально > > > сконструированными пакетами, которых в нормальном ssl-ном трафике > > > не бывает. Прослушанный трафик в плане heartbleed бесполезен. > > > > Что-то я в это не уверен, хоть в детали и не вникал. Если там > > утечка через неинициализированные данные - > > Никаких "неинициализированных данных" там и близко нет, там выход за > границы. Почитайте лучше про суть атаки, чем фантазировать попусту. А что это меняет? По последствиям, выход за границы некой структуры в пределах общей heap - та же самая утечка, что и через неинициализированные данные. Безотносительно к конкретному программному механизму утечки, при достаточно долгом пассивном наблюдении за каналом и при наличии на руках проблемного исходного кода, из собранных данных, вероятно, можно восстановить те же самые "до 64 К" памяти поражённого процесса. Понятно, что это сделать сложнее, чем в случае активной атаки, но в принципе возможно, я думаю. Так что, лучше перебдеть, чем недобдеть. -- Stanislav -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140413125317.ga14...@kaiba.lan
