можно ли считать отдельно взятый «компилятор в вакууме» доверенным?

man теория компиляторов
По поводу открытых компиляторов можешь не беспокоиться.
И да, под термином «backdoor» чаще всего подразумевается хитрый скрытый баг, который можно поэксплуатировать, а не явно вредоносный код.

есть ли теоретическая возможность

Да.

liberatum.ru

Бгг.

По поводу открытых компиляторов можешь не беспокоиться.

С каких пор открытость ПО - это гарантированное отсутствие закладок?

По поводу открытых компиляторов можешь не беспокоиться.

А их давно никто не смотрит. :)) Потому что на изучение и понимание 1 ГБ развёрнутого комплекта LLVM/Clang 4.0 в ассемблерном виде вряд ли хватит человеческой жизни.

Аноним, что ты подразумеваешь под «закладкой»?
Открытый компилятор делает ровно то что написано в исходниках, и ничего больше.
Кстати, man bootstrapping.
Допустим у меня в OpenBSD:

$ du -hs /usr/src/gnu/gcc
81.3M   /usr/src/gnu/gcc

$ cd /usr/src/gnu/gcc
$ find . | xargs wc -l
   17016 total

Хммм пардон.

$ find . -name "*.c" -print | xargs wc -l  
  982506 total

Ты проводил этот аудит?

Мой вопрос заключался в том, с каких пор открытость ПО - это гарантия того, что этому коду можно доверять? Ты же именно так написал - можешь не беспокоится, раз код открыт.

Два чая этому господину.

Ты проводил этот аудит?

Нет.

с каких пор открытость ПО - это гарантия того, что этому коду можно доверять?

Нет такой гарантии, но если что-нибудь вредоносное кто-нибудь попытается включить, это скорее всего сразу будет видно.
ТС привёл как пример новость о закрытом компиляторе, аудит которому невозможен.

Видно будет с такой же степень вероятности, как и в закрытом. Потому как вредоносность так или иначе себя проявит. И нет никакой разницы где ее раньше заметят в закрытом ПО или открытом.

ТС привёл как пример новость о закрытом компиляторе, аудит которому невозможен.

Вы статью читали? Ведь там каким-то образом провели «аудит» и нашли откуда растут уши у кода, взявшегося «из ниоткуда».

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

В статье речь о современном компиляторе с закрытым кодом, в который встроен современный бэкдор, который потом заменят на другой бэкдор.

Видно будет с такой же степень вероятности, как и в закрытом.

Работу закрытого компилятора легче разобрать чем открытого?

Потому как вредоносность так или иначе себя проявит.

http://stackoverflow.com/questions/15538366/can-memset-function-call-be-remov...
«Вредоносность» можно не заметить.

нет никакой разницы где ее раньше заметят в закрытом ПО или открытом

Результат работы открытого компилятора предсказуемее.

Провели «аудит»

Разбор бинарника собранного закрытым компилятором != аудит закрытого компилятора.
https://en.wikipedia.org/wiki/Software_audit_review

A software audit review, or software audit, is a type of software review in which one or more auditors who are not members of the software development organization conduct «An independent examination of a software product, software process, or set of software processes to assess compliance with specifications, standards, contractual agreements, or other criteria».

«Вредоносность» можно не заметить.

Если вредоносность незаметна, как ты ее собираешься заметить в открытом ПО. Я тебя еще раз спрашиваю, какое количество аудита исходных кодов открытого ПО ты в своей жизни провел?

Всякую вредоносность, как и большинство уязвимостей, находят в непосредственно работающем ПО, а к исходникам прибегают только с целью локализовать найденное или расширить\опровергнуть предположение о найденном.

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

Кто заметит её в закрытом? Тот кто её написал и положил туда? Он тебе не расскажет.

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

Я тебя еще раз спрашиваю, какое количество аудита исходных кодов открытого ПО ты в своей жизни провел?

Не дави.
Просматривал исходный код утилит doas, ping и почтового клиента sylpheed, полностью просмотреть базовую систему и используемые программы на данный момент времени у меня нет.

Если вредоносность незаметна, как ты ее собираешься заметить в открытом ПО

Ты сказал «вредоносность так или иначе себя проявит», я ответил что её «можно и не заметить».
Очевидно, что в открытом ПО «вредоносность» в любом случае проще заметить, разбирать закрытый бинарник практически никто не будет.

Всякую вредоносность находят в непосредственно работающем ПО

Я разобрал скрипт, нашёл

rm -rf / somedir

если компилятор будет встраивать закладку в каждую программу, то она рано или поздно вылезет при дизассемблировании небольшой программы

Как быть если «закладка» встраивается только в определённую функцию?

Платиновые треды ЛОРа.

Ты не понял суть его идеи. Чтобы исходники компилятора стали компилятором, их надо скомпилировать с помощью другого компилятора. А теперь представь, что этот другой компилятор скрытно модифицирует каждый выходной исполняемый файл, добавляя туда закладку. В итоге в полученном в результате компиляции исполняемом файле будет дополнительный функционал, которого не было в исходниках. И если он не заметен, то о нём никто может и не узнать.

Это, конечно, уже сродни теории заговора, но давайте представим такую теоретическую ситуацию:

Некий компилятор скрыто заменяет все вызовы к файловым операциям (open, read, write) на некоторые обёртки, которые делают вот что:

1) Если мы открыли на запись исполняемый файл и пишем туда исполняемый код (можно определить по заголовкам ELF и PE), то дописать туда бекдор.

2) Если мы отрыли на чтение исполняемый файл, то при чтении вырезать оттуда бекдор (если он там был, ищем по сигнатурам).

Дописанный бекдор несёт точно такой же функционал (перехват read и write). Если допустить идеальную реализацию + перехват некоторых других системных вызовов (например, stat, чтобы размер файла не учитывал бекдор), а также что весь софт в системе был инфицирован этим бекдором, то он окажется практически необнаруживаемым (ни одна вновь скомпилированная программа не увидит код бекдора в исполняемых файлах, но при этом будет сама его содержать).

Конечно, это очень сложная программная задача, к тому же сейчас слишком много развелось всяких ОС, компиляторов и т. д. и будет тяжело до всех дотянуться, но всё же.

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

man теория компиляторов

лучше man проблема доверенного компилятора

Fully Countering Trusting Trust through Diverse Double-Compiling (DDC)

Просто оставлю это здесь: https://www.dwheeler.com/trusting-trust/

An Air Force evaluation of Multics, and Ken Thompson’s Turing award lecture (“Reflections on Trusting Trust”), showed that compilers can be subverted to insert malicious Trojan horses into critical software, including themselves. If this “trusting trust” attack goes undetected, even complete analysis of a system’s source code will not find the malicious code that is running. Previously-known countermeasures have been grossly inadequate. If this attack cannot be countered, attackers can quietly subvert entire classes of computer systems, gaining complete control over financial, infrastructure, military, and/or business system infrastructures worldwide. This dissertation’s thesis is that the trusting trust attack can be detected and effectively countered using the “Diverse Double-Compiling” (DDC) technique, as demonstrated by (1) a formal proof that DDC can determine if source code and generated executable code correspond, (2) a demonstration of DDC with four compilers (a small C compiler, a small Lisp compiler, a small maliciously corrupted Lisp compiler, and a large industrial-strength C compiler, GCC), and (3) a description of approaches for applying DDC in various real-world scenarios. In the DDC technique, source code is compiled twice: once with a second (trusted) compiler (using the source code of the compiler’s parent), and then the compiler source code is compiled using the result of the first compilation. If the result is bit-for-bit identical with the untrusted executable, then the source code accurately represents the executable.

Статья, объясняющая как это работает: https://www.schneier.com/blog/archives/2006/01/countering_trus.html

2017

Сколько можно уже обсуждать идею, которая появилась ещё, как минимум, в 1984 году?

1) Если мы открыли на запись исполняемый файл и пишем туда исполняемый код (можно определить по заголовкам ELF и PE), то дописать туда бекдор.

2) Если мы отрыли на чтение исполняемый файл, то при чтении вырезать оттуда бекдор (если он там был, ищем по сигнатурам).

Довольно быстро обнаружится, что программы, скомпилированные таким компилятором, портят контрольную сумму файлов при операциях копирования.

Так программа считающая контрольную сумму тоже инфицирована!

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

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

А где гарантия что ОС не содержит вызовов, которые модифицируют бинарный код компилятора, написанного в машинных кодах? Или подразумевается что нужно в машинных кодах написать загрузчик, потом ОС, потом компилятор, потом начать всё это переписывать на более высокоуровневых языках?

[paranoikmodeon]Никто кстати не гарантирует отсутствие закладок в железе, на котором все это будет крутиться.[/paranoikmodeoff]

[paranoikmodeon]Никто кстати не гарантирует отсутствие закладок в железе, на котором все это будет крутиться.[/paranoikmodeoff]

Совершенно верно! Поэтому нужно написать свой процессор, послать на фабрику и молиться чтобы закладку не сделали там. А ещё что её не сделает злобный редактор Verilog'а, который тоже надо написать на доверенном компиляторе, который... Так, стоп!

Ну, интеловский фортран компилятор, который я уже сто лет использую (и который бесплатный под Линукс) на амдшных процах занимался саботажем. Правда можно было указать явно флаги оптимизации, но автоматом они для АМД не врубались, по-моему SSE3, возможно что-то ещё, уже не помню. Сейчас вроде нет такого косяка, по-крайней мере количество сообщений о векторизации петель одинаковое на домашнем FX 8350 и на рабочем Devil's Canyon да и скорости работы в 4 потока примерно одинаковые. Но осадочек остался...

В машинных кода можно было и под MS-DOS писать *.com файлы. То ещё извращение, но какую-нибудь фигню, типа отключения кеша процессора было реально.

Можно много всего, только не понятно, где желаемая вами точка отсчёта. Ведь компилятор уже мог внедрить вредоносный код в ядро ОС, BIOS/EFI... Как вы будете уверены, что выполняется именно введёный вами машинный код?

А если в тех первых компиляторах добрым гением была оставлена лазейка и при компиляции нового компилятора эта лазейка «прошивается» и в него?

Это надо быть реальным гением, чтобы лазейка протащилась через разные компиляторы и ее никто не заметил при дизассемблировании.

никто не может быть уверенным в том, что этот существующий компилятор не был скомпрометирован...

Короче, есть FASM - написан давно на TASM, а дальше сам на себе уже десятилетие точно компилируется. Код компилятора\IDE на ассемблере отлаживали в дизассемблерах и закладок не было. Можно взять FASM и скомпилировать листинг Си программы, например...

Но кто даст гарантии, что нет закладок в биосе\уефи или в процессоре?!

А какой смысл читать всё? Достаточно ведь найти все байты, которые использует система или биос для чтения скан-кодов?

а почему для компилятора отдельно следует рассматривать наличие вредоносного кода? потому что он создает бинарники? так отредактировать бинарник любая прога с правами рута может.