А для крутых парней барабаны - часть 10

[dwarkin]

Предыдущие части: 1 2 3 4 5 6 7 8 9

Часть 10.

В комментариях к предыдущей части народ просит слайды жаждет обсудить HeartBleed, но мы все таки начнем с Apple, благо это даже хронологически верная последовательность событий, не говоря уж о том, что «критическая и позорная уязвимость» в яблочном коде оказалась цветочками по сравнению с основной

Comments

[vombatenok]

Офигеть.
Радует только то, что в моей почте нет ничего секретного, а свой доступ к банковскому счету я ограничила исключительно уровнем "смотреть", и никакие операции не разрешила. Ну а состояние кредиток мониторю регулярно, т.к. мне никакого вора не надо, чтобы растратить все заработанное непосильным трудом...

[dwarkin]

Kстати, сегодняшняя новость - в Microsoft Explorer очередная критическая ошибка, дающая возможность "плохому" сайту на твоем компьютере запустить свой код. Заплаток пока нет. Поражены все системы включая XP (под которое Microsoft вроде и не собирается выпускать исправления) и все версии - от MS Explorer 6 до 11, итого 25% всех браузеров.

И кому-кому, а MS денег должно хватать на security review :)

[vombatenok]

Зато от одного знакомого я знаю, что как раз у них очень мало тестировщиков - политика фирмы.
Ну и идиоты, что сказать...

[alexcohn]

Все всегда жалуются на то, что работников мало. По нормам софтверной индустрии, Микрософт относится к тем немногим, у кого дела с тестированием обстоят хорошо.

[irene221b]

> Ни одна из этих фирм не потрудилась исследовать безопасность

А если даже и потрудилась? Легко пропустить и gotofail, и heartbleed. Тесты, которые покрывают каждую строчку кода, вряд ли кто-то себе может позволить кроме оригинального производителя библиотеки. Другое дело, что их можно требовать как стандарт при использовании 3rd party code. Но тогда, как и в любом конфликте между security и productivity, секюрити отдохнет.

[dwarkin]

после драки все умные, но несколько людей в теме уже высказывалось, что нормальный анализатор кода/security review не замыленными глазами должно было и то и другое показать:

вот про heartbleed, этот Ben Laurie - один из контрибьюторов OpenSSL:

http://www.huffingtonpost.com/2014/04/10/heartbleed-bug_n_5120457.html

Хрен его разберет, правда это или чисто политика. Вот сейчас OpenBSD (Theo de Raadt) сказали "this code is beyond repair", типа горбатого могила исправит и основали свой LibreSSL

http://arstechnica.com/information-technology/2014/04/openssl-code-beyond-repair-claims-creator-of-libressl-fork/

Мне лично это выглядит дешевым поиском популярности, но возможно я не понимаю какие-то существенные аспекты.

[alhimik]

Я читал код OpenSSL как то, не могу сказать что он такой ужасный. По моему мнению вполне стандартный код на C. Там во всей красе, правда, то, что C не объектно ориентированный, а так хотелось бы...
А вот то, что привело к epic fail (в плане методологии, не в плане бага, баги все создают):
http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse

[lifewalker]

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

[alhimik]

На самом деле, уязвимость эта попала в OpenSSL по стандартам вендоров относительно недавно, и поэтому многие просто неуспели получить себе эту радость. Но наиболее продвинутые как раз пострадали. Как с "испанкой" - умирали люди с сильной имунной системой.

[baron_pampa]

"The vulnerable code was adopted into widespread use with the release of OpenSSL version 1.0.1 on March 14, 2012" - почти два года o_O

[alhimik]

И ты будешь удивлен, сколько всего пользуется еще версиями 0.9.х
А embedded вообще, насколько я знаю, никогда не пользовались OpenSSL.

[dwarkin]

по нынешним временам уже на MicroSD Linux бегает, а ты говоришь embedded :)

[cryinstone]

один не слишком умный программист, работающий на Apple, копируя свой-же код (вполне нормальная практика, смею заметить) не обратил внимание, что одну и ту-же строчку он написал дважды.

Копирование кода - это бу. Если скопировал с целью изменить копию - сабабушки, но за "програмирование" старинным китайским методом copy-and-paste нужно нещадно бить линейкой по рукам, и разжаловать в дворники.
А вот если "не заметил" - пардон, с интеллектом это не имеет никакой связи.

[dwarkin]

Вот этот код, ты уже сам решай. Болд мой.

static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
uint8_t *signature, UInt16 signatureLen)
{
OSStatus err;
...

if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
goto fail;
...

fail:
SSLFreeBuffer(&signedHashes);
SSLFreeBuffer(&hashCtx);
return err;

[cryinstone]

Ну я к тому, что этот лишний goto fail - очепятка, не имеющая отношения к IQ программиста. Невнимательность != глупость. Все мы в этом положении бывали - чай, не роботы. Может он в этот момент перегрелся, или его мысли на 100 милисекунд переключились на Даму Сердца :)

А вот code review в Ябле либо не делают, либо делают спустя рукава.

[dwarkin]

ну как ты видишь по всем этим заметкам - не у них одних проблемы с code review.

[digest]

настал судный день всего современного программного обеспечения с открытым кодом, и IT Security как индустрии

Если пресса называет что-то "судным днем" ИТ-индустрии, значит можно не волноваться. Любимый баг механика Гаврилова, блин. На самом же деле вещь неприятная, но не ужас-ужас. Бывали баги ГОРАЗДО опаснее, нежели возможнсть прочитать локальный heap процесса, где могут быть пароли, ключи и схема атомной бомбы, а могут и не быть.

[dwarkin]

раскажи про ГОРАЗДО более опасные баги, чем извлечение private encryption key 2/3 серверов в интернете :)

[digest]

Осспади, да полно. Ты ж только что сам про очередной майкрософтовский 0day написал. Уязвимости, позволяющие запускать код (брать appliance жертвы под полный контроль), иные существовавшие по несколько лет кряду, гораздо сурьёзнее теоретической read-only компрометации памяти heartdbleed. В теории дыра, конечно, обалдленная, спору нет. А на практике -- это ужас, но не ужас-ужас. Откуда чушь про 2/3 серверов, откуда еще большая чушь про извлечение private keys? Кто сказал, что именно личные ключи лежат в той же куче процесса и где они лежат? А если я в своей программе личный ключ записал в буфер, созданный не malloc-ом, то как и кем он извлечется?

[dwarkin]

private keys чушь???

вот описание того как чувак выковыривал ключи из Nginx.

http://arstechnica.com/security/2014/04/how-i-used-heartbleed-to-steal-a-sites-private-crypto-key/

кроме того он пишет:

Note: all my experiments and the CloudFlare challenge are targeting Nginx which is single-threaded. It is possible that for a multi-threaded web server, more leakage can be observed.