Диагностика ошибки Heartbleed в OpenSSL. (Окончательный диагноз ещё не поставлен, хотя лечение уже идёт вовсю)

[@VBart]

И самое главное: чем больше ваш запрашиваемый блок, тем больше вероятность, что он будет обслужен mmap, а не sbrk.

Только непонятно, каким образом размер запрашиваемого блока связан с размером блока памяти, в котором собственно лежит запрос и, собственно, за границы которого происходит чтение.

Как выделена память тут: buffer = OPENSSL_malloc(1 + 2 + payload + padding); — значение не имеет.

[@Noospheratu]

Кажется, автор статьи недостаточно прояснил вопрос, каким образом утекают данные.

Из кода я вижу, что запрашивающей стороне отправляется содержимое необнулённого массива buffer, выделенного malloc'ом в куче.
Посмотрев код, никакой связи адреса расположения buffer'a с адресом структуры SSLv3, об окрестностях которой говорит автор статьи, не обнаружил.
Если бы OPENSSL_malloc обнулял содержимое выделяемой памяти, уязвимость не имела бы таких последствий.
Но, к сожалению, OPENSSL_malloc это простой malloc с дополнительными проверками, но без обнуления.

[@VBart]

Дело не в том, что делается с отправляемым буфером. Дело в том, что в него копируется. А в него копируется существенно больше данных, чем прислал клиент. В этом и уязвимость, что в него попадают данные расположенные за пределами присланного клиентом объема.

[@Noospheratu]

Автор тоже думал всё это время и поправил оригинальный пост:

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.

[@VBart]

Наиболее интересный момент, каким образом «interesting stuff» оказывается «reachable from pl» — так и остался за кадром.

[@Noospheratu]

«Продолжение — в следующей серии» (С)
Ждём апдейтов от автора. Я его пост уже в WebSite Watcher добавил.
Будут новости — опубликую.

[@d00kie]

Это как раз очевидно — класика Use-After-Free:

//юзер 1 пришел
a = malloc(size)
write(a,SECRET_FROM_USER_1);
free(a)
//… юзер 1 ушел. пришел второй запрос в тот же процесс, но уже от второго юзера.
b= malloc(size)
read(b,size)

А теперь Вы спрашиваете почему в b будет SECRET_FROM_USER_1

[@d00kie]

Классика*

[@d00kie]

Да, это не UAF, я погорячился, так как указатель новый, а не старый. Но суть от этого не меняется.

[@bubuq]

Библиотека распространяется в объектном виде, и не имеет значения, на каком языке она написана, если язык компилируется.

[@bubuq]

1. Я знаю несколько (Lisp, Ada, OCaml, Haskell), но ведь для наших целей достаточно одного, верно? Любой из них обеспечит большую безопасность, поскольку нигде не нужно выделять память руками.

2. Не очень понятно. Вот вы написали на C, а вот вы написали на хаскеле, gcc -c вызвать, или ghc -c, разницы нет. Платформ в природе не так уж много разных, и популярные среды несомненно поддерживают все.

3. Функция, которая в объектном файле, уже не сишная, как бы. Она уже скомпилирована. Про С++ судить не могу, но нет никаких проблем вызывать хаскелл из си. Любой более-менее развитый компилируемый язык предоставит байндинги и сгенерит хедеры для линкования с си.

[@farcaller]

В рассылке rust-dev обсуждали уже что rust был бы хорошим выбором для нового libssl, не считая того что написать качественную криптографическую либу с нуля очень сложно и надо бы компилятор постабильнее, перед тем как думать о таких объемах.

[@pbludov]

Просто отличное голосование:

Я бы не пожалел для этого усилий. А вы?
* Да, я не пожалел бы.
* Нет, я не пожалел бы.

[@Noospheratu]

"Без использования какой-либо конфиденциальной информации или учетных данных мы смогли украсть у себя
секретные ключи, используемые для наших сертификатов X.509,
имена пользователей и пароли,
мгновенные сообщения,
электронную почту и
важные деловые документы и общения."

И всё это хранилось в куче?! Даже без наложенной маски?!

А можно узнать, каким ПО пользовались эксперты?
Чтобы избегать таких неправильно написанных программ?

[@bubuq]

Эксперты использовали специально модицифированный веб сервер, которй при старте считывает все секретные ключи, все пароли всех пользователей, расшифровывает их, архив мновенных сообщений и почты, а также важные деловые документы, и держит их в специально выделенной памяти ;)

[@toxicdream]

При наличии времени, я выбрал бы

Начать писать альтернативные реализации на более безопасных языках.

В крайнем случае, можно попытаться выделить из Си «множество безопасных команд» и начать переписывать код по этому множеству.
В случае использования потенциально опасных команд и невозможности от них отказаться — аудит этих участков кода. Можно и независимый, и платный.
В общем, я фанат и последователь Н.Вирта.

[@0serg]

Языком программирования надо правильно пользоваться. В том же C относительно легко можно создать разумные и безопасные абстракции и пользоваться ими. Проблема, имхо, больше в желании нагородить низкоуровневых велосипедов, когда а) свою абстракцию писать лень и б) использовать чужую абстракцию тоже не хочется.

Менять язык просто для того чтобы помешать разработчикам городить свои велосипеды и навязать какие-то конкретные абстракции — имхо глупо. Все потенциально опасные конструкции все равно не убрать не удастся, зато появится ложное чувство безопасности. Там где заранее понятно что все проблемы все равно выловить не удастся и всех это устраивает ибо оптимизирует соотношение цены и качества, подобный подход разумен — всех проблем не повылавливаем, но хоть их общее число за счет смены языка сократим. А для продуктов уровня OpenSSL где даже одна ошибка это катастрофа это бессмысленно.

[@Nordvind]

Можно начать следовать стандартам и перестать говнокодить, для начала.

Думаю, от С не откажутся, хотя-бы из-за скорости. Но то что надо заставлять следовать хорошим практикам — факт.

[@khim]

Можно начать следовать стандартам и перестать говнокодить, для начала.

Вы тут немного тёплое с мягким перепутали. Беда с TLS — в ДНК. Overengineering — это ещё мягко сказано. Проблема в том, что в последнее время модно складывать два и два с привлечением стандартов для описания которых требуются тысячи страниц. Тут на каком языке ни напиши — ничего хорошего не выйдет. Потому что добавлять уровни индирекции куда проще, чем реально решать проблемы (RFC 1925). Если мы хотим получить хоть какую-то безопасность, то нужно перестать городить вавилонские башни из кубиков когда «hello, world» занимает мегабайты и включает в себя поддержку приготовления яичницы на Луне, но кто ж на это пойдёт? Пока не будут введены санкции (и серъёзные санкции) за выпуск (и, главное, использование) небезопасного софта ничего не изменится. Та же история, что и, например, с карточками: в Америке никто и не собирается особо переходить на чипованные карточки, потому что для разрабочиков гораздо дешевле использовать нечипованные, а случаи мошенничества всё равно расследуются полицией и, соответственно, напрямую на затраты не ложатся (ну там есть, конечно, какие-то затраты, но они несоизмерыми с теми, которые бы банкам и платёжным системам пришлось бы нести, если бы они напрямую содержали полицию). В Европе — переходят, но не потому что там банки сознательнее, а потому что законы этого требуют.

Увы и ах, но безопасность — это то, чего рыночная экономика обеспечить не может. Она поощряет эффективность, «срезание углов» и всемерную экономию средств — а это ну никак не может привести к безопасности. Потому армии даже в самых супер-пупер прогрессивных странах содержит не рыночная экономика, а государство.

[@VBart]

Ну на самом деле OpenSSL ещё тот говнокод, так что в какой-то степени тут одно накладывается на другое.

[@galaxy]

Концентрация безапелляционных утверждений зашкаливает.

Беда с TLS — в ДНК. Overengineering — это ещё мягко сказано. Проблема в том, что в последнее время модно складывать два и два с привлечением стандартов для описания которых требуются тысячи страниц

Это точно про TLS? И где там overengineering, не благоволите пояснить?
Вот стандарт, кстати, 104 страницы

Если мы хотим получить хоть какую-то безопасность, нужно перестать городить вавилонские башни из кубиков

Криптография — это сложно, вам не сказали? Чтобы получить безопасность с учетом атак всевозможного рода, как раз приходится делать весьма причудливые конструкции.

Пока не будут введены санкции… ничего не изменится

А вы не в Госдуме работаете? Логика определенно депутанская: ввести запрет и проблема решится.

безопасность — это то, чего рыночная экономика обеспечить не может

Абсолютную безопасность обеспечить не сможет никто, а пока большинство современных алгоритмов, стандартов и софта — продукт рыночной экономики. Некоторые компании сделали миллиарды на безопасноcти: Verisign, RSA, не считая еще кучи компаний, специализирующихся на корпоративной безопасности. И они ее неплохо обеспечивают, пока как раз государство не сует свой нос, куда не следует (привет NSA и RSA).

Она поощряет эффективность ...

В этом и сила рынка. А вот как и на что пилят колоссальные бюджеты окологосударственные безопасники, и насколько эффективны их продукты, ответить некому.

Потому армии даже в самых супер-пупер прогрессивных странах содержит не рыночная экономика, а государство

Ох… Ну для начала, а кто финансирует государство?
Далее, как вы себе представляете зарабатывание денег армией вообще? Корованы пусть грабят?
Кстати, это сейчас смешно, а в 19-м веке британская армия была по большей части частной и сама себя окупала захватническими войнами в колониях. Весьма, между прочим, эффективно, в отличии от

[@Andrey2008]

Всем, кто спрашивал меня про PVS-Studio: Скучная статья про проверку OpenSSL.