На днях прочитал такое мнение по поводу известного бага в 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).
