Пара слов про 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).

10 комментариев

  1. xz100500 пишет:

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

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

  2. xz100500 пишет:

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

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

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

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

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

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

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

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

      • xz100500 пишет:

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

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

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

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

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

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

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

          Уверен?

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

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

          • xz100500 пишет:

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

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

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

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

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

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

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

  3. xz100500 пишет:

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

    • Вот именно поэтому “лынукс” никогда не будет стоять на каждом первом компьютере в мире. Топ-20 – это все-таки не мой ноутбук, например.