Запоздалые мысли о Heartbleed.

Полезно вспомнить еще две довольно серьезных баги, очень похожие на Heartbleed.

Во-первых, MS Word в 90-х сохранял доки в файлы .doc, это были бинарные файлы. Из-за какой-то баги, в этих файлах мало того что были пустые лакуны, так туда еще попадали тексты из доков, что редактировались в этом редакторе до этого документа.

Можно пошутить, что это немного напоминает junk DNA - куски инфы которые есть в ДНК, но ни на что не влияют, а остались от предыдущих мутаций, от наших далеких предков.

Видел своими глазами в конце 90-х, как приходит официальный документ от нац.банка UA, а в провинциальном банке сидят сисадмины, открывают эти .doc-и в FAR-е, читают совсем другие тексты, ржут. Или начало нулевых - барышня вместо того чтобы писать амурные емылы, писала их в MS Word, просто потому что так привыкла. Потом отправляла кавалеру емылом doc-файлы, в attach-ах. Кавалер открывал их FAR-ом и узнавал о барышне куда больше, чем она о себе рассказывала - из тех текстов, что она писала в Word-е до этого. Стоит ли говорить, насколько всё это плохо. И ничего не нужно было взламывать, троянить, и совесть (относительно) чиста.

Да вы и сейчас можете это оценить, если найдете у себя старые файлы в формате .doc, созданные старыми Word-ами в 90-ые годы. Может быть, вы даже узнаете много нового. (И это при том, что те старые глючные версии MS Word уже никто почти не юзает.)

Потом в MS Word переходили на .rtf, .docx - это уже другие форматы.

Почему так вышло? В Microsoft тесты не отлавливали эту багу. Всё вроде бы работало. Никто не жаловался. А слишком часто лазить hex-редактором в бинарный файл - это занятие слишком муторное и на практике редко нужное.

Во-вторых, первый Intel Pentium в середине 90-х неверно делил. Там была какая-то таблица констант, размером 1066 элемента, для делителя. На какой-то стадии, таблица обрезалась до 1061 элемента - кто-то протупил потому что. Делитель, когда обращался к последним 5-и элементам, не выдавал никаких ошибок, не подкидывал исключений. И снова не словили багу тестами. Считается, что бага была настолько катастрофичной, что это ударило по репутации Интела так, что AMD вырвался вперед и стал раноправным конкурентом Intel.

Ну и о самом Heartbleed.

Когда я кодил ToyTLS и писал о нем (1, 2, 3, 4), я накачал всяких книг про SSL/TLS и начал читать.

Книги можно разделить на 2 части - до 2014 и после 2014. В первой половине книг фича heartbeat не упоминается вовсе. Книги писали люди, что серьезно занимаются этой темой - и они сами не знали, нафик эта фича вообще нужна. Такое ощущение, что про неё просто забыли, но оставили для совместимости ХЗ с чем. Какой от нее толк? Да вроде бы никакого. Наверное потому и не писали про нее. Фича ничем не примечательна.

Книги после 2014-го (включительно) упоминают heartbleed в связи с дырой, и вот здесь автор открытым текстом признается, что не знает зачем нужна была эта фича, да и никто толком не знал:

Heartbeat is implemented as a TLS subprotocol, which means that heartbeat messages can
be interleaved with application data and even other protocol messages. According to the
RFC, heartbeat messages are allowed only once the handshake completes, but in practice
OpenSSL allows them as soon as TLS extensions are exchanged.
It is not clear if Heartbeat is used in practice.
However, it’s supported by OpenSSL and enabled by default. GnuTLS also implements it.
Virtually no one knew what Heartbeat was
until April 2014, when it was discovered that the OpenSSL implementation suffered from a
fatal flaw that allowed the extraction of sensitive data from the server’s process memory.

( Ivan Ristić - BULLETPROOF SSL AND TLS / Understanding and Deploying SSL/TLS and PKI to Secure Servers and Web Applications )

(Хотя справедливости ради, надо добавить, что подобные фичи бывают и в других протоколах. Самый известный - ping через ICMP - клиент посылает какой-то кусок чего-то и сервек должен его скопировать и вернуть назад.)

И всё это очень плохо. Так оно и бывает, (полу)забытая фича подразумевает, что её давно и/или плохо тестировали, если вообще. Когда-то давно, лет 15 назад, я точно так же искал (полу)забытые фичи в Oracle RDBMS и находил их.

Это было не трудно - код Oracle разрабатывается по крайней мере с начала 90-х, а может быть и с конца 1980-х. Иногда у меня даже ностальгия по тем временам. Ковыряние внутренностей Oracle было похоже на какую-то компьютерную игру вроде рогалика, лазишь во тьме по каким-то подземельям, натыкаешься на забытые всеми артефакты, изучаешь, как они работают, даже азарт какой-то. (Я не играю в комп. игры в принципе, но наверное, тот опыт мне восполнял недостачу азарта в играх.)

И если бы очень нужно мне было искать баги сейчас, я бы тоже так и делал бы - искал бы забытые фичи.

По этому поводу есть две новости: хорошая и плохая.

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

И плохая новость - можно потратить очень много времени - месяцы или даже годы. И не факт, что вообще получится что-то. И что на найденной баге можно будет заработать хоть что-то. Ну, в крайнем случае, у вас останется масса знаний о каком-то продукте. Как у меня - об Oracle. И это еще под вопросом, стоило ли мне тратить столько времени и энергии на него? Лучшие годы молодости, так сказать? И другая проблема - авторы могут легко выкинуть код, над котором вы очень долго бились. Не предупреждая вас. Психологически это бывает трудно перенести.

Собственно так и в реальной жизни. Social engineers (эвфемизм для аферистов и мошенников) могут находить в компании какого-то незаметного чморимого всеми (молодого) неудачника, подкатывать к нему, через него вести разведку - это классика жанра. И судя по шпионским историям и книгам, так же вербуют и агентов.

И конечно же, чем более популярна-известна софтина, тем больше у вас конкурентов - таких же пытливых юношей, что массу времени тратят на поиск уязвимостей. И еще не известно, кто раньше найдет багу. Участвовать в таких забегах - это тоже не весело.

(the post first published at 20250310, updated 20250313.)


List of my other blog posts.

Subscribe to my news feed,

Yes, I know about these lousy Disqus ads. Please use adblocker. I would consider to subscribe to 'pro' version of Disqus if the signal/noise ratio in comments would be good enough.