Автор тоже думал всё это время и поправил оригинальный пост:
The allocations for bp don't matter at all, actually. The allocation for pl, however, matters a great deal. It's almost certainly allocated with sbrk because of the mmap threshold in malloc. However, interesting stuff (like documents or user info), is very likely to be allocated with mmap and might be reachable from pl. Multiple simultaneous requests will also make some interesting data available.
"Без использования какой-либо конфиденциальной информации или учетных данных мы смогли украсть у себя секретные ключи, используемые для наших сертификатов X.509,
имена пользователей и пароли,
мгновенные сообщения,
электронную почту и
важные деловые документы и общения."
И всё это хранилось в куче?! Даже без наложенной маски?!
А можно узнать, каким ПО пользовались эксперты?
Чтобы избегать таких неправильно написанных программ?
Кажется, автор статьи недостаточно прояснил вопрос, каким образом утекают данные.
Из кода я вижу, что запрашивающей стороне отправляется содержимое необнулённого массива buffer, выделенного malloc'ом в куче.
Посмотрев код, никакой связи адреса расположения buffer'a с адресом структуры SSLv3, об окрестностях которой говорит автор статьи, не обнаружил.
Если бы OPENSSL_malloc обнулял содержимое выделяемой памяти, уязвимость не имела бы таких последствий.
Но, к сожалению, OPENSSL_malloc это простой malloc с дополнительными проверками, но без обнуления.
Согласен с Вами. В единичных случаях можно прогнозировать самому, ну а если надо будет массово эти операции проводить — лучше освободить ум для более интеллектуальных вещей.
Ни о каких правоохранительных применениях и речи нет.
Правоохранителям не обязательно получать с помощью этой технологии доказательства, которые примет любой суд.
Им достаточно «наводки\наколки», а потом — соберут улики классическим способом.
"Переходный процесс — в теории систем представляет реакцию динамической системы на приложенное к ней внешнее воздействие с момента приложения этого воздействия до некоторого установившегося значения во временной области. ..."
Вероятно, напасёшься :).
Ждём апдейтов от автора. Я его пост уже в WebSite Watcher добавил.
Будут новости — опубликую.
секретные ключи, используемые для наших сертификатов X.509,
имена пользователей и пароли,
мгновенные сообщения,
электронную почту и
важные деловые документы и общения."
И всё это хранилось в куче?! Даже без наложенной маски?!
А можно узнать, каким ПО пользовались эксперты?
Чтобы избегать таких неправильно написанных программ?
Из кода я вижу, что запрашивающей стороне отправляется содержимое необнулённого массива buffer, выделенного malloc'ом в куче.
Посмотрев код, никакой связи адреса расположения buffer'a с адресом структуры SSLv3, об окрестностях которой говорит автор статьи, не обнаружил.
Если бы OPENSSL_malloc обнулял содержимое выделяемой памяти, уязвимость не имела бы таких последствий.
Но, к сожалению, OPENSSL_malloc это простой malloc с дополнительными проверками, но без обнуления.
Правоохранителям не обязательно получать с помощью этой технологии доказательства, которые примет любой суд.
Им достаточно «наводки\наколки», а потом — соберут улики классическим способом.
Только вслух конечную цель не озвучивают.
Пока проект на стадии суборбитальных полётов.
Подождём…
«Цифровая (электронная) подпись» — это добавленный к открытому сообщению его зашифрованный хеш (если совсем уж «на пальцах» объяснять).
По периодичности, продолжительность и изменению интенсивности общения можно сделать различные далеко идущие выводы.
Как, например, сделал Facebook.
Прогоняете ли вы его исходники своим любимым анализатором безопасности перед сборкой?
Сравниваете ли хотя бы контрольную сумму, подпись OpenPGP или ключ .Net перед инсталляцией?