Comments 26
В самом деле, нельзя доверять никакому коду, который не написали от начала и до конца вы сами. Никакой верификации на уровне исходников, никакой въедливой проверки не хватит, чтобы защититься от недоверенного кода.
Осталось отправить этот материал регуляторам, которые отвечают за сертификацию программного обеспечения по требованиям безопасности информации (ФСТЭК, ФСБ, МО) и ждать их реакции.
А серьёзно, речь как шла так и идёт о степени доверия разработчику и контролирующему звену. И не важно что это компилятор или бытовой утюг.
Не надо останавливаться на полпути. Что толку писать весь cофтварный код с нуля, если и драйвера OS, и контроллер HDD, и всякие отдельные модули в компе, и микрокод процессора, и вообще архитектура всех чипов не в нашей власти?
Только логарифмические линейки спасут нацию.
Была похожая атака в 2009. Вирус патчил SysConst.dcu из Delphi, заражая в итоге все скомпилированные файлы. Так был заражен QIP у многих его пользователей, из за компрометации разработчика.
Насколько я помню, это был как раз чей-то эксперимент, чтоб показать насколько уязвимы компиляторы, и сам вирус ничего полезного (кросе распространения) не делал.
А я олдфаг и использовал md5 для чексуммы. Хорошо, пропатчим md5. Но как же быть с hexdump'ом? Давайте пропатчим hexdump. А если я открою файл в hexedit? Давайте, пропатчим hexedit. А если я сделаю на питоне простейшую программу для hexdump'а файла? Мы не можем патчить программы на питоне, чтобы исправить поведение (потому что это задача об остановке) или питон (т.к. это будет та же задача об остановке, предсказать, что сделает программа). Мы можем попатчить libc, чтобы она отдавала изменённую версию при чтении.
Но если кто-то сделает dd |python -c myhexdump, то нам нужно будет попатчить её и dd, таким образом, чтобы она скрывала данные при прямом чтении с диска. Но это потребует одновременной поддержки всех файловых систем (файл на vfat будет сильно отличаться от файла в btrfs). Но мы можем отправить файл компилятора в сокет/пайп и он либо будет патчиться (на чистый), либо не будет. Если будет, то простой cat suspicios_compiler > compiler даст нам чистый компилятор.
Если не будет, то cat suspicios_comipler|hexdump даст нам содержимое. Файл может быть отправлен по любому сетевому протоколу и просмотрен tcpdump (и он либо патченный обратно, т.е. чистый, либо с бэкдором).
Т.е. вся модель "evil chain" начинает непрерывно разветляться на новые и новые "if", и чем больше if'ов, тем больше возникает if'ов. Ни какой сверхумный код не может сказать, что сделает мой двухстрочник на перле, а значит, невозможно сделать осмысленный патчинг (для скрытия или, наоборот, для внедрения).
Как только появляется механизм скрытия, то он же может использоваться для получения чистой копии компилятора. Как только появляется метод инъекции, он может использоваться для обнаружения инъекции через несовпадение, потому что анализ производит чистый код на некомпилируемом языке.
Фактически, это инверсия задачи futamura projections, только вместо "некачественного" компилятора у нас появляется зловредный.
В художественной форме опасения про безопасность на хардверном уровне изложены в книге Winn
Schwatau "Terminal Compromise"
По теме скажу лишь, что кто первый начал разработку таких систем с поддержкой кучи программ, софта и тулзов тот и выиграет у какого-нибудь стартапа полугодовой давности на с++. А так это проблема первого компилятора - кто первый его напечатал и внедрил бэкдор в него, тот и поставил весь мир разработки враскаряку
А если получить дамп программы с бэкдором (зловредная дампилка должна скрыть присутствие), затем распечатать его и на другом компьютере с другой архитектурой, другой ОС, другим процессором, перенести дамп обратно в бинарный файл. Он очистится после такой процедуры?
В эпоху MS DOS были вирусы, которые встраивались в исполняемые файлы и скрывали свое присутствие. Их удавалось удалить даже без второго компа. Достаточно было скопировать зараженный файл во что-то, что вирус не считал исполняемым и потому не заражал. Потом переименовываешь файл обратно в исполняемый. Переименование вирус не обрабатывал. В более тяжелом случае можно было бы для переименования загрузиться с чистой дискеты
Вирусы, заражавшие исходники, тоже были. В общем, всё уже придумано до нас
Да, а потом вы увидите, что "print(123)" весит как Фотошоп и тут закрадуться подозрения...
Неплохая демонстрация, но недостаточно исследована тема защиты от этой атаки, и нагнано желтизны. Есть, например, проект gnu mes, который позволяет бутстрапнуть систему с нуля из исходников, вообще не прибегая к недоверенным бинарникам. А чтобы обнаружить evil цепочку в открытой экосистеме, например дебиана, достаточно одной проверки.
Представляете, до сих пор есть люди, считающие что электронное голосование — хорошая идея.
Можно незаметно для себя совершить атаку Томпсона (именно совершить, а не подвергнуться ей) следующим способом:
Пишем свой компилятор языка C. В какой-то момент нам нужно написать код для парсинга строковых литералов (в частности, экранированных символов). У нас в коде компилятора появляется что-то типа:
if(curChar=='\\' && nextChar=='n') literal.append('\n');
Обратная косая черта и буква «n» в тексте литерала приводят к тому, что в буфер памяти для этого литерала добавляется символ '\n'.
Теперь зададим себе вопрос: а где в исходнике компилятора у нас записан код для символа '\n'? Нигде. Мы скопировали код этого символа из бинарника того компилятора, которым мы компилируем наш компилятор, в бинарник нашего компилятора (в частности, компилятор может компилировать сам себя). Мы незаметно для себя вызвали функцию cloneMyselfInsteadOfCompiling(), упомянутую с статье. Чисто гипотетически, можно представить себе, что '\n' — это вирус (или уязвимость), и он только что передался от компилятора к компилятору через компиляцию исходного кода. (С практической точки зрения можно представить, что функция append() имеет два перегруженных варианта — вариант, принимающий символ и вариант, принимающий строку, и компилирующий компилятор парсит литерал '\n' в строку "матерноеСлово\13". Пользователь такого компилятора будет удивляться, откуда у него матерноеСлово в откомпилированной программе).
По моему, для того, чтобы потенциально зловредный компилятор не испортил нам всю малину - достаточно хорошенько прообфусцировать код. Когда компилятор просто не в состоянии понять, что именно ты компилируешь - он не будет знать, куда и где бекдоры присобачивать.
Ну а если настанут времена нейросетей - в процессе обфускации также придется выносить все выводимые сообщения в отдельный файл, к которому компилятор естественно, не подпускать.
А как такой зловред скроется, если скомпилировать ею минимально простую программу и дизасемблировать?
Как собрать зловредный компилятор