На днях прочитал такое мнение по поводу известного бага в OpenSSL:
Yes, tell me more about how crypto should only be written in memory unsafe languages.
Мол, язык C, на котором написана OpenSSL, допускает произвольный доступ к памяти, из-за чего, собственно, и появляется возможность доступа к уже освободившейся памяти, занятой чужими данными. А вот если бы OpenSSL писали на правильном языке, не допускающем таких штук — то все было бы хорошо.
К сожалению, дело не в языке. Начну хотя бы с того, что используемые сегодня процессоры и операционные системы нельзя назвать memory-safe. Любая загруженная библиотека имеет доступ ко всей памяти процесса — и неважно, на каком языке она написана. Предлагается просто поверить в то, что реализация «правильного» языка подобных ошибок не содержит, фактически — перенести ответственность с авторов библиотеки на авторов компилятора или интерпретатора. Напоминает сказку про кашу из топора? Правда, я как-то писал про это, только в другом контексте.
На C, кстати говоря, тоже можно писать в стиле memory-safe. По большому счету это требование — лишь набор некоторых ограничений, которые можно либо соблюдать, либо нет. По большому счету, все упирается в еще одно «критическое» место — реализацию некоторых функций из стандартной библиотеки. Если мы можем предположить, что malloc() и free() реализованы корректно, то можно попробовать доказать или опровергнуть то, что то или иное обращение к памяти будет безопасно. Второй путь, «практический» — реализовать эти функции так, чтобы некорректная работа с памятью приводила к ошибкам и «падению» программы. Так сделано, например, в libc — но…
http://article.gmane.org/gmane.os.openbsd.misc/211963
Оказывается, что в OpenSSL реализованы свои функции распределения памяти, и реализованы они криво (как показывает существование этого бага). А зачем это сделано? Оказывается, на «некоторых платформах» штатные malloc() и free() работают, по мнению авторов OpenSSL, «медленно».
После этого вы хотите поговорить о «memory-safe»? Уверен, что в таком случае талантливые разработчики OpenSSL найдут еще с десяток причин нарушить это ограничение, как бы вы не старались. Страуструп писал в своем талмуде по C++ (по поводу ключевых слов private и public):
Защита закрытых данных базируется на ограничении использования имен членов класса. Эту защиту можно обойти манипулированием с адресами и путем явного преобразования типа. Но это, конечно, уже жульничество. C++ защищает от случайного, а не умышленного нарушения правил. Защиту против злонамеренного доступа к закрытым данным в языке высокого уровня можно осуществить только на аппаратном уровне, и даже это является довольно сложной задачей в реальной системе.
То же самое можно сказать, наверное, о любых ограничениях любого языка. От «грязных хаков» может спасти лишь соответствующее к ним отношение в процессе разработки, своеобразная дисциплина разработчиков — а с этим в OpenSSL туговато. Еще раз призываю перечитать слова Тео де Раадта по ссылке выше и убедиться, что даже с тестированием у них печаль-беда:
On ALL PLATFORMS, because that option is the default, and Ted’s tests show you can’t turn it off because they haven’t tested without it in ages. <…> OpenSSL is not developed by a responsible team.
Печально, что такие безответственные люди разрабатывают одну из важнейших библиотек (и дело даже не в криптографии — скажем, даже в нынешнем виде OpenSSL вполне мог бы удовлетворять российским сертификационным требованиям для класса КС1 или даже КС2).
ну, вобщем-то, стандартный подход писания своих велосипедов — если под вендой (например) оно будет работать медленно, то вой подымется именно на openssl. это как с резолверами — в определенный момент каждый продукт обзаводится своим.
Дело не только в велосипеде — тут встретилось вместе сразу несколько ошибок, но главная проблема в том, что OpenSSL встречается на огромном количестве веб-серверов, и слишком много зависит от ее, так сказать, качества. Вряд ли через heartbleed можно утащить много важных данных, но вот «звоночек» об отвратно поставленном процессе разработки — это куда серьезнее.
>OpenSSL встречается на огромном количестве веб-серверов
и не только веб
>Вряд ли через heartbleed можно утащить много важных данных
нормально можно упереть, он у еРЖД сперли за неделю 70 тыщ карточек
>но вот “звоночек” об отвратно поставленном процессе разработки – это куда серьезнее.
да процесс там вобщем-то нормальный и ревью кода был, просто квалификация людей была низкая. те сочетание 2 в одном — охуенный криптограф+охуенный программер слишком редка, чтобы тратить ее на опенсорс проект бесплатно фулл-тайм
> он у еРЖД сперли за неделю 70 тыщ карточек
Карточки — это хуйня. Вот список моих любимых порносайтов — куда более ценная штука, ящетаю.
> те сочетание 2 в одном – охуенный криптограф+охуенный программер слишком редка, чтобы тратить ее на опенсорс проект бесплатно фулл-тайм
Я очень сомневаюсь в том, что опенсорс сейчас разрабатывается бесплатно силами студентов, и склонен даже подозревать, что особо талантливые разработчики могут получать зарплату в двух местах — в условном Red Hat и в условном АНБ (подставить конкретные названия по желанию).
Не помнишь, часом, историю про патчи OpenSSL в Дебиане?
>Вот список моих любимых порносайтов – куда более ценная штука, ящетаю.
бля, а што их много??!! я думал один порнолаб.
>Я очень сомневаюсь в том, что опенсорс сейчас разрабатывается бесплатно силами студентов
там не студент был, а прости-оссподи, толи хуйдожник, толи еще какой-то хипстер.
> и склонен даже подозревать, что особо талантливые разработчики могут получать зарплату в двух местах – в условном Red Hat и в условном АНБ (подставить конкретные названия по желанию).
по-мойму это факт что много опенсорса за зп кодят в редхате-ибм и тд, но нужно быть достаточно грамотным чтоб тебя туда взяли за зп. и да, конкретная ХБ не была результатом закладки
>Не помнишь, часом, историю про патчи OpenSSL в Дебиане?
неочень, там были свои патчи с которыми тоже была жопа? а, прочел, там закоментили пару строк кода, которое привело к фатальному упрощению генератора рандомных чисел, и, как следствие, к слабости ключей.
это другая проблема — люди которые форкают, патчат чужой кот нихуя не понимают всего гемороя по мейнтансу, бэкпортов и мержей с основной веткой и всех проблем, которые они привнесут своими патчами
> там не студент был, а прости-оссподи, толи хуйдожник, толи еще какой-то хипстер.
Опять же, чисто организационная проблема — code review хипстерами и художниками является лишь имитацией такового.
> и да, конкретная ХБ не была результатом закладки
Уверен?
> это другая проблема – люди которые форкают, патчат чужой кот нихуя не понимают всего гемороя по мейнтансу, бэкпортов и мержей с основной веткой и всех проблем, которые они привнесут своими патчами
Паранойя подсказывает, что все они прекрасно понимают — и то, какой гемор это приносит, и то, как скрыть свое вмешательство.
>Опять же, чисто организационная проблема – code review хипстерами и художниками является лишь имитацией такового.
ну да, сам процесс-то здесь косвенно.
>Уверен?
нет, но при вдреннении вредоносного кода намеренно в тот же sshd хрен знает сколько лет назад нашли достаточно быстро, за несколько часов, в отличие от распиздяйства по недомыслию здесь.
>Паранойя подсказывает, что все они прекрасно понимают – и то, какой гемор это приносит, и то, как скрыть свое вмешательство.
пгостите, вы в коммерческой разработке софта работаете? там просто дебилов хватает налево и направо, или мы таки ведем речь за закладки в ОСС?
> нашли достаточно быстро, за несколько часов
Если мы говорим об одном и том же случае — то нашли, потому что знали, что искать.
> там просто дебилов хватает налево и направо
Разница в том, что силами дебилов не разрабатывают библиотеки, устанавливаемые на каждый первый компьютер в мире.
>Разница в том, что силами дебилов не разрабатывают библиотеки, устанавливаемые на каждый первый компьютер в мире.
позвольте усомниться :) примеры про лынукс и top-20 суперкомпов, например.
про дебилов в линуксе всего 3 примера
— эпичный пробел в деинсталляторе дров от nvidia
— systemd
— незаметный коммит в security fix ядра, который принес кучу гемора обладателям атишных карт, при это автор комита прекрасно знал что он поломает, даже насрал в каментах про это
Вот именно поэтому «лынукс» никогда не будет стоять на каждом первом компьютере в мире. Топ-20 — это все-таки не мой ноутбук, например.