В своей прошлой статье «Теория «Черного лебедя» и фундаментальная уязвимость автоматизированных систем» я описал программные закладки добавляемые в программы с открытым исходным кодом бинарной версией компилятора, при этом новые версии компилятора скомпилированные этим компилятором также будут создаваться с закладками.
В этой статье я предложил эталонное решение и несколько рекомендаций по снижению вероятности реализации данной угрозы.
Вместо введения
Входите узкими вратами, ибо широки врата и просторен путь, ведущий в геену огненную. (Евангелие от Матфея).
Эталонное решение
Решение достаточно очевидное и заключается в создании эталонного компилятора. И даже не сколько в создании компилятора, сколько в создании открытых спецификаций и методики разработки эталонной версии этого компилятора, которая может быть выполнена в нескольких независимых друг от друга реализациях. Только в этом случае при раздельной компиляции какой-либо прикладной программы несколькими реализациями «доверенного» компилятора в случае идентичности бинарных модулей можно будет говорить об отсутствии вирусного кода в полученных «эталонных» компиляторах и, соответственно, об отсутствии закладок в полученной программе.
Несомненно не стоит забывать о реализации атак через аппаратную часть компьютера, для повышения степени доверия необходимо использовать аппаратную часть разработанную в соответствии с принципами Open Hardware.
Рекомендации по снижению вероятности угрозы
Для создания эталонного компилятора потребуется время и усилия коллектива разработчиков, но проблема стоит уже сейчас и пока не существует доверенного компилятора. Значит необходимо принимать меры по снижению вероятности данных угроз.
Говоря о создании компилятора мы говорим не только о фазе генерации объектных файлов, но и о таких компонентах как препроцессор, компоновщик и т. д. Отдельная собственная реализация препроцессора и компоновщика с учетом всех прочих рекомендаций (в том числе реализация их на других языках) может повлиять на реализацию угрозы.
Предположения по снижению вероятности реализации программных закладок, предположения базируются на модели угроз.
| Угроза | Решение |
| Компилятор с НДВ распознает исходный код целевой программы и добавляет вирусный код. | Обфускация исходного кода компилируемой программы без потери функциональности. |
| В новые бинарные версии компиляторов с НДВ добавляли новые закладки. | Использование самых ранних бинарных версий компиляторов, тогда часть НДВ может оказаться неактуальной. |
| Компилятор с НДВ добавляет вирусный код для платформы на которой был скомпилирован. (Arm, x86) | Кросс-компиляция. Компиляция программ для x86 на Arm и наоборот. |
| Компилятор с НДВ для реализации части закладок использует сторонние библиотеки и ПО. | Компиляция на изолированной системе с минимально необходимым набором программ и утилит. |
| Компилятор с НДВ предусматривает атаки на изолированные от внешних данных системы и активирует НДВ по каким-либо событиям (переполнение памяти, неизвестные ошибки, подключение специализированных устройств, наступление определенного времени и т.п.) | Имитация событий и запуск проверяемого ПО в данных условиях (в том числе при компиляции). |
*НДВ- недокументированные возможности.
Снижение проявлений НДВ в компилируемых программах возможно при объединении представленных методов совместно с динамическим тестированием программного обеспечения.
Послесловие
Сама угроза «Закладок в компиляторах» напоминает теорию заговора и параноидальна, но теоретически осуществима. В комментариях объективная критика и рекомендации приветствуются.
Автор: Krasnoglazik
