Пара слов про heartbleed

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

Пара слов про heartbleed: 10 комментариев

  1. ну, вобщем-то, стандартный подход писания своих велосипедов — если под вендой (например) оно будет работать медленно, то вой подымется именно на openssl. это как с резолверами — в определенный момент каждый продукт обзаводится своим.

    1. Дело не только в велосипеде — тут встретилось вместе сразу несколько ошибок, но главная проблема в том, что OpenSSL встречается на огромном количестве веб-серверов, и слишком много зависит от ее, так сказать, качества. Вряд ли через heartbleed можно утащить много важных данных, но вот «звоночек» об отвратно поставленном процессе разработки — это куда серьезнее.

  2. >OpenSSL встречается на огромном количестве веб-серверов
    и не только веб

    >Вряд ли через heartbleed можно утащить много важных данных
    нормально можно упереть, он у еРЖД сперли за неделю 70 тыщ карточек

    >но вот “звоночек” об отвратно поставленном процессе разработки – это куда серьезнее.
    да процесс там вобщем-то нормальный и ревью кода был, просто квалификация людей была низкая. те сочетание 2 в одном — охуенный криптограф+охуенный программер слишком редка, чтобы тратить ее на опенсорс проект бесплатно фулл-тайм

    1. > он у еРЖД сперли за неделю 70 тыщ карточек

      Карточки — это хуйня. Вот список моих любимых порносайтов — куда более ценная штука, ящетаю.

      > те сочетание 2 в одном – охуенный криптограф+охуенный программер слишком редка, чтобы тратить ее на опенсорс проект бесплатно фулл-тайм

      Я очень сомневаюсь в том, что опенсорс сейчас разрабатывается бесплатно силами студентов, и склонен даже подозревать, что особо талантливые разработчики могут получать зарплату в двух местах — в условном Red Hat и в условном АНБ (подставить конкретные названия по желанию).

      Не помнишь, часом, историю про патчи OpenSSL в Дебиане?

      1. >Вот список моих любимых порносайтов – куда более ценная штука, ящетаю.
        бля, а што их много??!! я думал один порнолаб.

        >Я очень сомневаюсь в том, что опенсорс сейчас разрабатывается бесплатно силами студентов
        там не студент был, а прости-оссподи, толи хуйдожник, толи еще какой-то хипстер.

        > и склонен даже подозревать, что особо талантливые разработчики могут получать зарплату в двух местах – в условном Red Hat и в условном АНБ (подставить конкретные названия по желанию).
        по-мойму это факт что много опенсорса за зп кодят в редхате-ибм и тд, но нужно быть достаточно грамотным чтоб тебя туда взяли за зп. и да, конкретная ХБ не была результатом закладки

        >Не помнишь, часом, историю про патчи OpenSSL в Дебиане?
        неочень, там были свои патчи с которыми тоже была жопа? а, прочел, там закоментили пару строк кода, которое привело к фатальному упрощению генератора рандомных чисел, и, как следствие, к слабости ключей.
        это другая проблема — люди которые форкают, патчат чужой кот нихуя не понимают всего гемороя по мейнтансу, бэкпортов и мержей с основной веткой и всех проблем, которые они привнесут своими патчами

        1. > там не студент был, а прости-оссподи, толи хуйдожник, толи еще какой-то хипстер.

          Опять же, чисто организационная проблема — code review хипстерами и художниками является лишь имитацией такового.

          > и да, конкретная ХБ не была результатом закладки

          Уверен?

          > это другая проблема – люди которые форкают, патчат чужой кот нихуя не понимают всего гемороя по мейнтансу, бэкпортов и мержей с основной веткой и всех проблем, которые они привнесут своими патчами

          Паранойя подсказывает, что все они прекрасно понимают — и то, какой гемор это приносит, и то, как скрыть свое вмешательство.

          1. >Опять же, чисто организационная проблема – code review хипстерами и художниками является лишь имитацией такового.
            ну да, сам процесс-то здесь косвенно.

            >Уверен?
            нет, но при вдреннении вредоносного кода намеренно в тот же sshd хрен знает сколько лет назад нашли достаточно быстро, за несколько часов, в отличие от распиздяйства по недомыслию здесь.

            >Паранойя подсказывает, что все они прекрасно понимают – и то, какой гемор это приносит, и то, как скрыть свое вмешательство.
            пгостите, вы в коммерческой разработке софта работаете? там просто дебилов хватает налево и направо, или мы таки ведем речь за закладки в ОСС?

            1. > нашли достаточно быстро, за несколько часов

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

              > там просто дебилов хватает налево и направо

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

  3. >Разница в том, что силами дебилов не разрабатывают библиотеки, устанавливаемые на каждый первый компьютер в мире.
    позвольте усомниться :) примеры про лынукс и top-20 суперкомпов, например.
    про дебилов в линуксе всего 3 примера
    — эпичный пробел в деинсталляторе дров от nvidia
    — systemd
    — незаметный коммит в security fix ядра, который принес кучу гемора обладателям атишных карт, при это автор комита прекрасно знал что он поломает, даже насрал в каментах про это

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *