Неужели компилятор Ken Thompson взломал все еще угрозу?

Кен Томпсон Хак (1984)

Кен Томпсон изложил метод коррумпирования двоичного кода компилятора (и другого скомпилированного программного обеспечения, такого как сценарий входа в систему * nix) в 1984 году. Мне было любопытно узнать, исправила ли современная компиляция этот недостаток безопасности или нет.

Краткое описание:

Перепишите код компилятора, содержащий два недостатка:

  • При компиляции собственного бинара компилятор должен скомпилировать эти недостатки
  • При компиляции некоторого другого предварительно выбранного кода (функция входа) он должен скомпилировать произвольный бэкдор

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

Вопросы:

Я не мог найти ответы на них в Интернете:

  • Как это связано с компиляцией «точно вовремя»?
  • Являются ли такие функции, как управление обработкой программы в системе * nix, скомпилированной, когда они работать?
  • Является ли это до сих пор действительной угрозой или произошли изменения в безопасность компиляции с 1984 года, которая мешает этому быть значительная проблема?
  • Это влияет на все языки?

Почему я хочу знать?

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

Справочный материал

150 голосов | спросил Andrew 25 Jpm1000000pmFri, 25 Jan 2013 23:45:19 +040013 2013, 23:45:19

10 ответов


106

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

Что сделало так страшно, что компилятор C был центральной частью программного обеспечения для этих систем. Почти все в системе прошло через компилятор, когда он был впервые установлен (бинарные дистрибутивы были редки из-за гетерогенного оборудования). Все собирали вещи все время. Люди регулярно проверяли исходный код (им часто приходилось вносить коррективы, чтобы заставить его скомпилировать вообще), поэтому включение компилятора в бэкдоры казалось бы своего рода «совершенным преступлением», когда вы не могли быть пойманы.

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

ответил Michael Borgwardt 26 Jam1000000amSat, 26 Jan 2013 01:51:19 +040013 2013, 01:51:19
63

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

Цель состояла в том, что, когда дело доходит до безопасности, мы бы хотели не доверять никому, но, к сожалению, это невозможно. Вы всегда должны доверять кому-то (отсюда заголовок: «Размышления о доверительном доверии»)


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

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

ответил BlueRaja - Danny Pflughoeft 26 Jam1000000amSat, 26 Jan 2013 03:17:17 +040013 2013, 03:17:17
52

Нет

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

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

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

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

Это высокоуровневое самонаправленное программирование, жесткая проблема с ИИ (последнее, что я проверил, современное состояние порождает код, который практически определяется его типами). Посмотрите: мало кто может это сделать; вам нужно будет изучить язык программирования и сначала понять базу кода.

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

Аналогичная атака: доверие к загрузке

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

Пример, который можно легко снять в реальной жизни

Ваша операционная система, скажем Ubuntu Linux, обеспечивает безопасность (целостность) обновлений, проверяя загруженные пакеты обновлений на ключ подписи репозитория (используя криптографию с открытым ключом). Но это гарантирует только подлинность обновлений, если вы можете доказать, что ключ подписи принадлежит законному источнику.

Где вы получили ключ подписи? Когда вы впервые загрузили дистрибутив операционной системы.

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

Любой, кто может MITM подключение к Интернету между вами и сервером загрузки Ubuntu - это может быть вашим интернет-провайдером, правительством, которое контролирует доступ к Интернету (например, Китай), или провайдер хостинга Ubuntu - мог бы захватить этот процесс:

  • Определите, что вы загружаете образ компакт-диска Ubuntu. Это просто: см., Что запрос отправляется в любое из (общедоступных) зеркал Ubuntu и запрашивает имя файла ISO.
  • Подайте запрос с их собственного сервера, предоставив вам образ компакт-диска, содержащий открытый ключ злоумышленника и местоположение репозитория, а не Ubuntu.

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

Вы можете предотвратить атаку, убедившись, что оригинал аутентичен. Но для этого требуется, чтобы вы подтвердили загруженное изображение компакт-диска с помощью хэша ( несколько человек на самом деле делают это ) â € ", и хэш должен быть загружен безопасно, например. над HTTPS. И если ваш злоумышленник может добавить сертификат на свой компьютер (обычный в корпоративной среде) или контролирует центр сертификации (например, Китай), даже HTTPS не обеспечивает защиту.

ответил Mechanical snail 26 Jam1000000amSat, 26 Jan 2013 03:03:15 +040013 2013, 03:03:15
23

Во-первых, моя любимая запись этого хака называется Странные циклы .

Этот конкретный взлом, безусловно, можно было бы сделать (*) сегодня в любом из крупных проектов с открытым исходным кодом ОС, особенно Linux, * BSD и т. п. Я ожидаю, что это будет работать почти одинаково. Например, вы загружаете копию FreeBSD, у которой есть эксплоированный компилятор для изменения openssh. С этого момента каждый раз, когда вы обновляете openssh или компилятор по источнику, вы продолжите проблему. Предполагая, что злоумышленник использовал систему, используемую для упаковки FreeBSD, в первую очередь (вероятно, поскольку само изображение повреждено или злоумышленник на самом деле является упаковщиком), то каждый раз, когда эта система перестраивает двоичные файлы FreeBSD, она будет повторно задавать проблему. Есть много способов для этой атаки потерпеть неудачу, но они не принципиально отличаются от того, как атака Кена могла потерпеть неудачу (**). Мир действительно так сильно не изменился.

Конечно, подобные атаки могут быть легко (или более легко) введены их владельцами в такие системы, как Java, SDK для iOS, Windows или любая другая система. Некоторые виды ошибок безопасности могут даже быть сконструированы в аппаратное обеспечение (в частности, ослабление генерации случайных чисел).

(*) Но «конечно» я имею в виду «в принципе». Если вы ожидаете, что такая дыра существует в какой-либо конкретной системе? Нет. Я бы счел это маловероятным по различным практическим соображениям. Со временем, когда код изменяется и изменяется, вероятность того, что этот вид взлома вызовет странные ошибки, увеличивается. И это повышает вероятность того, что он будет обнаружен. Менее изобретательные бэкдоры потребуют заговоров для поддержания. Разумеется, мы знаем, что в разных телекоммуникационных и сетевых системах установлены «законные перехватывающие» бэкдоры, поэтому во многих случаях такой сложный взлом не нужен. Хак устанавливается открыто.

Так всегда, защита в глубину.

(**) Предполагая, что атака Кена когда-либо существовала. Он просто обсудил, как сделать . Он не сказал, что на самом деле сделал это, насколько мне известно.

ответил Rob Napier 26 Jam1000000amSat, 26 Jan 2013 01:22:15 +040013 2013, 01:22:15
13

Оказывает ли это влияние на все языки?

Эта атака в первую очередь затрагивает языки, которые являются самостоятельными. Это языки, где компилятор написан на самом языке. C, Squeak Smalltalk и интерпретатор PyPy Python будут затронуты этим. Perl, JavaScript и интерпретатор CPython Python не будут.

Как это связано с компиляцией «точно вовремя»?

Не очень. Это сам хостинг-характер компилятора, который позволяет скрывать хак. Я не знаю каких-либо самозагружающихся компиляторов JIT. (Может быть, LLVM?)

Являются ли такие функции, как управление обработкой программы в системе * nix, скомпилированной при их запуске?

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

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

Это все еще теоретическая угроза, но вряд ли.

Одна вещь, которую вы могли бы сделать, чтобы уменьшить ее, - это использование нескольких компиляторов. Например, компилятор LLVM, который сам компилируется GCC, не будет проходить по задней двери. Аналогичным образом, GCC, составленный LLVM, не будет проходить по задней двери. Итак, если вас беспокоит такая атака, вы можете скомпилировать ваш компилятор с другой породой компилятора. Это означает, что злодейский хакер (у вашего поставщика ОС?) Придется испортить оба компилятора, чтобы узнавать друг друга; Гораздо более сложная проблема.

ответил Sean McMillan 26 Jam1000000amSat, 26 Jan 2013 01:47:26 +040013 2013, 01:47:26
10

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

В принципе, используйте как предполагаемый компилятор, так и другой самостоятельно разработанный компилятор для компиляции источника подозрительного компилятора. Это дает вам SC sc и SC T . Теперь скомпилируйте подозреваемый источник, используя оба этих двоичных файла. Если результирующие двоичные файлы идентичны (за исключением множества вещей, которые могут вполне законно меняться, например различные временные метки), подозрительный компилятор фактически не злоупотреблял доверием.

ответил Vatine 26 Jpm1000000pmSat, 26 Jan 2013 16:39:28 +040013 2013, 16:39:28
3

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

  

Как это связано с компиляцией «точно вовремя»?

Не уверен, что вы подразумеваете под этим. Является ли JITter иммунным к этому? Нет. Это более уязвимо? На самом деле, нет. Как разработчик ВАШЕ приложение более уязвимо, просто потому, что вы не можете подтвердить, что это не сделано. Обратите внимание, что ваше еще не разработанное приложение в основном невосприимчиво к этому и всем практическим изменениям, вам нужно только беспокоиться о компиляторе, который является более новым, чем ваш код.

  

Являются ли такие функции, как управление обработкой программы в системе * nix, скомпилированной при их запуске?

Это не актуально.

  

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

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

  

Это влияет на все языки?

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

ответил jmoreno 26 Jam1000000amSat, 26 Jan 2013 07:37:27 +040013 2013, 07:37:27
-2

Дэвид Уилер имеет хорошую статью: http://www.dwheeler.com/trusting-trust/

Меня больше беспокоит аппаратные атаки. Я думаю, нам нужна полная конструктивная конструкция VLSI с исходным кодом FLOSS, которую мы можем модифицировать и скомпилировать, что позволяет нам создавать микропроцессор, который не имеет бэкдоров, вставленных инструментами. Инструменты также должны позволить нам понять цель любого транзистора на чипе. Затем мы могли бы открыть образец готовых чипов и осмотреть их микроскопом, убедившись, что у них есть те же схемы, что инструменты сказали, что они должны были иметь.

ответил paul 27 Jpm1000000pmSun, 27 Jan 2013 20:31:29 +040013 2013, 20:31:29
-3

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

ответил Dale Gulledge 27 Jpm1000000pmSun, 27 Jan 2013 19:16:00 +040013 2013, 19:16:00
-4

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

Предположим, что у кого-то есть исходный код для пакета компилятора /компоновщика (скажем, Groucho Suite), написанного таким образом, что его вывод не будет зависеть от каких-либо неопределенных действий или ни на чем другом, кроме содержимого исходных исходных файлов, и один компилирует /связывает этот код с различными независимо создаваемыми компиляторами /компоновщиками пакетов (скажем, Harpo Suite, Chico suite и Zeppo Suite), предоставляя для каждого другой набор exeuctables (назовите их G-Harpo, G- Чико и G-Zeppo). Для этих исполняемых файлов было бы непредсказуемо содержать разные последовательности инструкций, но они должны быть функционально идентичными. Однако доказательство того, что они функционально идентичны во всех случаях, скорее всего, будет неразрешимой проблемой.

К счастью, такое доказательство не понадобится, если использовать только результирующие исполняемые файлы для одной цели: компиляция пакета Groucho снова. Если один компилятор использует пакет Groucho, используя G-Harpo (уступая GG-Harpo), G-Chico (GG-Chico) и G-Zeppo (GG-Zeppo), то все три результирующих файла, GG-Harpo, GG-Chico , и GG-Zeppo, должны быть все байт-байт одинаковыми. Если файлы совпадают, это означало бы, что любой «вирус компилятора», который существует в любом из них, должен существовать одинаково во всех из них (поскольку все три файла побайтно одинаковы, их поведение не может различаться путь).

В зависимости от возраста и происхождения других компиляторов, возможно, будет возможно гарантировать, что такой вирус не может быть правдоподобным в них. Например, если вы используете антикварный Macintosh для подачи компилятора, который был написан с нуля в 2007 году с помощью версии MPW, написанной в 1980-х годах, компиляторы 1980-х годов не знали, куда вставлять вирус в компилятор 2007 года. Сегодня, возможно, компилятор сможет сделать достаточно анализа кода, чтобы понять его, но уровень вычислений, необходимый для такого анализа, намного превосходит уровень вычислений, необходимый для простого компиляции кода, и не мог не остаться незамеченным на рынке, где скорость компиляции была основной точкой продажи.

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

С другой стороны, я не уверен, что вижу, что компиляторы /компоновщики не должны предоставлять режим «канонического вывода», когда вывод зависит только от исходных файлов и «даты компиляции», которые могут быть переопределены пользователем. Даже если компиляция кода в таком режиме потребовала в два раза больше, чем обычная компиляция, я бы предположил, что будет значительная ценность в том, чтобы воссоздать любую «сборку релиза», байт для байта, полностью из исходных материалов, даже если это означало, что релиз сборки займет больше времени, чем «обычные сборки».

ответил supercat 27 Jam1000000amSun, 27 Jan 2013 00:00:16 +040013 2013, 00:00:16

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132