Comments 67
Напоминает какую-то теорию заговора, если честно. Так же параноидально.
Все возможно.
Сложно, в контексте программирования, опираться на парадигму «Все возможно». Возможно мы все существуем в воображении спящей коалы, и секунду назад еще не было никакого прошлого, а все наши воспоминания это псевдо-память. Но, спасибо бритве Оккама, мы не рассматриваем эту теорию всерьез при разработке ПО.
Ну почитайте прогнозы Столлмана, их тоже называли нереальными =)
Вы правы: я тоже никогда не видел черных лебедей.
(это была ирония, если вдруг кто не понял)
(это была ирония, если вдруг кто не понял)
Огромное спасибо за минус в карму.
"… это не значит, что за вами не следят" ((с) не помню откуда)…
UFO just landed and posted this here
А если закладка добавляется только в сложные программы, которые трудно анализировать?
Как вариант — в те программы, где компилятор может распознать защиту от дизассемблирования ;-)
Более того, отсутствие различия не будет говорить об отсутствии «закладки», таким образом представленная методика, мне кажется, применима не для обнаружения «закладки» в общем случае, а только для обнаружения «закладки», настроенной в том числе и на компилируемую программу! В общем, IDA в руки и сравнивать компилеры :-D
UFO just landed and posted this here
Получившиеся бинарные файлы должен быть идентичны, в противном случае компилятор дискредитирован и имеет вирусный код (программную закладку).
Я, конечно, нуб ещё тот, но… Ведь уровни оптимизации и возможная неоптимизированность одного из компиляторов тоже будут влиять на различия! А некоторые компиляторы ещё и встраивают метаинформацию о файле и прочее. Тут, я считаю, поможет дизассемблирование и сравнение ассемблерного кода по результату выполнения и структуре, а не простое побайтовое сравнение.
Да и закладка может быть настроена так — не вставлять код вируса в те файлы, где меньше 10000 строк кода. Тогда разбирать дизассемблированный листинг можно затрахаться =)
И да, сразу много ироничных фраз всплывает в голове:
Используйте виртуальную машину Python или Java ;-)
Декомпилируйте компилятор и проведите аудит декомпилированного кода
Нужно вернуться в прошлое и запустить программу, которая найдёт первый компилятор с закладкой и уберёт её, тогда мир будет спасён
Всем нужно писать на ассемблере и такой проблемы не возникнет
А Столлман же говорил...
1)берется проверенный исходный текст компилятора S (например gcc-4.7);
По идее, gcc-4.7 должен генерировать при одних и тех же ключиках один и тот же код, независимо от того, с какими ключами оптимизации САМ собран.
Декомпилятор тоже когда-то компилировался, почему вы ему доверяете? :)
Нужен аппаратный аудит, специальный чип на плате, который будет непрерывно анализировать оперативку на наличие в бинарниках закладок.
Почему бы не написать простейший компилятор C напрямую в машинных кодах и не скомпилировать с его помощью GCC? Главное хорошо документировать код нашего первокомпилятора, сделать его максимально доступные для ревью.
UFO just landed and posted this here
Шутки шутками, но потенциальные закладки в процессоре — проблема еще более серьезная, как мне кажется.
Чтоб закладки в процессоре были более интеллектуальны, чем «выйти из строя по сигналу со спутника», они должны быть на порядок сложнее, чем сам процессор…
Не очень понимаю, почему. Разве есть какие-то проблемы с аппаратной реализацией алгоритмов?
Интеллектуальные закладки в процессоре могут быть частично программными. Процессор может содержать небольшое встроенное ПЗУ, содержимое которого недоступно в обычных режимах, и исполнять программу оттуда в случае срабатывания закладки.
Не, есть типа рецептик: сделать к x586 процессору маленькую приблуду сбоку на базе ARM, которая перепрошивается извне, типа со спутника...;-)
Такой процессор уже давным давно есть… в неотъемлемом южном мосту.
И даже статьи пробегали по исследованиям китайских плат с троянцем на борту который использует аппаратные способности виртуализации самого же процессора.
Такой троянец очень хорошо умеет маскироваться — поскольку любые возможные средства отладки и анализа выполняются на… эмулируемой им самим же среде, и даже не могут знать что выполняются не на реальном процессоре.
Правда, стоит вопрос о его функциональности — что он вообще может делать на этом уровне? Как минимум — вывести систему из строя получив сигнал по сети… или прочитать указанную область памяти и отправить заказчику.
И даже статьи пробегали по исследованиям китайских плат с троянцем на борту который использует аппаратные способности виртуализации самого же процессора.
Такой троянец очень хорошо умеет маскироваться — поскольку любые возможные средства отладки и анализа выполняются на… эмулируемой им самим же среде, и даже не могут знать что выполняются не на реальном процессоре.
Правда, стоит вопрос о его функциональности — что он вообще может делать на этом уровне? Как минимум — вывести систему из строя получив сигнал по сети… или прочитать указанную область памяти и отправить заказчику.
Спасибо за инфу про южный мост…
Вот, о функциональности уровня выше чем «прочитать указанную область памяти и отправить заказчику» (кстати, через что — поддержка TCP/IP на уровне микропрограмм южного моста, не мешая при этом основной ОС?) и «вывести систему из строя получив сигнал по сети» (тот же вопрос — по какой сети) я тоже спрашивал выше… Да, и на основании чего заказчик сформирует команду с точным указанием области памяти?.. Тут, похоже, нужны закладки на уровне программ и ядра ОС…
Вот, о функциональности уровня выше чем «прочитать указанную область памяти и отправить заказчику» (кстати, через что — поддержка TCP/IP на уровне микропрограмм южного моста, не мешая при этом основной ОС?) и «вывести систему из строя получив сигнал по сети» (тот же вопрос — по какой сети) я тоже спрашивал выше… Да, и на основании чего заказчик сформирует команду с точным указанием области памяти?.. Тут, похоже, нужны закладки на уровне программ и ядра ОС…
Этот троянец перехватывает даже обращения к портам ввода-вывода, каких трудов ему составит наблюдение за интегрированным сетевым интерфейсом, если он для этой платы и разрабатывался… вся необходимая конфигурация будет перехвачена и троянец будет в курсе конфигурации сети и т.д.
Заказчик дает команду (это может быть код в HTML-странице перехваченный анализом трафика через сетевой интерфейс) считать первые сектора жестких дисков, таким образом легко узнается операционная система, потом подбирается(на стороне заказчика) нужный троян под нужную операционку и внедряется прямо на диск без ведома операционной системы… дальше все ограничивается фантазией заказчика. Троян собственно может работать и на процессоре южного моста, так и на основном — все что он может получить с операционки доступно ему как на ладони. Да собственно, зачем ему какие-то оперативные данные? Иногда достаточно утащить документы с диска.
Насчет доставки команды по сети… запросто может использоваться стеганография — от непосредственного задания за один раз пакетом, до 1 бита в час… и поди ж ты вылови эти биты с такой частотой возникновения в современных объемах трафика.
Заказчик дает команду (это может быть код в HTML-странице перехваченный анализом трафика через сетевой интерфейс) считать первые сектора жестких дисков, таким образом легко узнается операционная система, потом подбирается(на стороне заказчика) нужный троян под нужную операционку и внедряется прямо на диск без ведома операционной системы… дальше все ограничивается фантазией заказчика. Троян собственно может работать и на процессоре южного моста, так и на основном — все что он может получить с операционки доступно ему как на ладони. Да собственно, зачем ему какие-то оперативные данные? Иногда достаточно утащить документы с диска.
Насчет доставки команды по сети… запросто может использоваться стеганография — от непосредственного задания за один раз пакетом, до 1 бита в час… и поди ж ты вылови эти биты с такой частотой возникновения в современных объемах трафика.
Чуть-чуть почесав в затылке, я подумал, что компилятор-то тут вообще не при делах. Достаточно скомпрометировать линкер, и доверенный компилятор будет наивно доверять линкеру вставлять бэкдоры в исполняемые файлы. Из кристально чистых объектных файлов, заметим.
Речь скорее о compiler collection в целом, а не об одной лишь фазе генерации объектных файлов.
Тут всё сложнее. Если скомпрометированы, например, системные вызовы, то даже доверенный компилятор и линкер будут пихать в бинарники что нужно.
Последний раз человечество могло читать программы в машинных кодах на перфокартах и перфолентах.
С момента перехода на магнитные и прочие носители, возможность истинного аудита машинного кода пропала. До определённого момента ленту (спектрумовского уровня) можно было вывести в бинарном виде на печатать с помощью аналогового или примитивного цифрового устройства на мелкой рассыпухе.
Сейчас это уже не возможно, а значит, бэкдор невозможно увидеть «своими» глазами. О нём может только сказать компьютер. А если в компьютере бэкдор, то какой у него стимул палить малину?
Последний раз человечество могло читать программы в машинных кодах на перфокартах и перфолентах.
С момента перехода на магнитные и прочие носители, возможность истинного аудита машинного кода пропала. До определённого момента ленту (спектрумовского уровня) можно было вывести в бинарном виде на печатать с помощью аналогового или примитивного цифрового устройства на мелкой рассыпухе.
Сейчас это уже не возможно, а значит, бэкдор невозможно увидеть «своими» глазами. О нём может только сказать компьютер. А если в компьютере бэкдор, то какой у него стимул палить малину?
Книжка «Черный Лебедь» очень интересная, но на мой взгляд ее основная мысль тут истолкована не правильно.
Основная мысль это не «Мы все должны опасаться всех неожиданностей».
Основная мысль это «Думать о неожиданностях бессмысленно, тк если вы о чем-то, то это уже не неожиданность.
Самое главное — уметь воспользоваться любой ситуацией в свою пользу. Выигрывает тот, кто быстро и трезво принимает решения с незашоренными глазами. „
Основная мысль это не «Мы все должны опасаться всех неожиданностей».
Основная мысль это «Думать о неожиданностях бессмысленно, тк если вы о чем-то, то это уже не неожиданность.
Самое главное — уметь воспользоваться любой ситуацией в свою пользу. Выигрывает тот, кто быстро и трезво принимает решения с незашоренными глазами. „
Какое решение должна принять индейка?
ээ, в смысле как использовать «неожиданность», описанную в статье?
— начать писать компиляторы или джавамашины и прочие интерпретаторы.
— начать писать компиляторы или джавамашины и прочие интерпретаторы.
Мы по прежнему говорим о птичке ко дню благодарения?
Аа, я просто не понял вашего комментария.
Индейке самой решать что и как делать, если ей действительно сворачивают голову, тот тут проблема сродни кирпичу, падающему на голову — от нее сложно увернуться. Но если птичку везут куда-то в машине, то можно попробовать сбежать.
С другой стороны если бы птица воспользовалась свободным временем и занялась написанием компиляторов, то это могло спасти ей жизнь :)
Индейке самой решать что и как делать, если ей действительно сворачивают голову, тот тут проблема сродни кирпичу, падающему на голову — от нее сложно увернуться. Но если птичку везут куда-то в машине, то можно попробовать сбежать.
С другой стороны если бы птица воспользовалась свободным временем и занялась написанием компиляторов, то это могло спасти ей жизнь :)
Эх, надо заново всё делать. Сначала написать ассемблер, в машинных кодах, потом на ассемблере простенький компилятор Си, потом на нём компилятор посложнее. Потом gcc откомпилировать.
Может всё, кроме первого звена, уже есть?
Может всё, кроме первого звена, уже есть?
когда вы будете записывать машинные коды на диск, малварный редактор вставит туда бэкдор. А когда вы попробуете посмотреть на результат — удалит и не покажет. А когда вы редактор пересоберёте, он будет уже с малварью.
Впрочем, при условии скомпрометированного процессора (например, SMM режим в x86), танцы вокруг компиляторов выглядят наивными.
Впрочем, при условии скомпрометированного процессора (например, SMM режим в x86), танцы вокруг компиляторов выглядят наивными.
Интересно, допустим у нас в компиляторе закладка. Это может быть.
Но если в нашем сценарии закладки и в разных комиляторах, линкерах, ОС, редакторах, железе, всё это из разного периода времени, не обнаруживаемое и согласующееся между собой, разве не падает вероятность такой подставы экспоненциально?
Может тогда сделать протокол (т.е. что чем компилировать), допускающий закладку, только если огромное количество разного софта имеет закладки, согласующиеся между собой (и что, следовательно, маловероятно)
Но если в нашем сценарии закладки и в разных комиляторах, линкерах, ОС, редакторах, железе, всё это из разного периода времени, не обнаруживаемое и согласующееся между собой, разве не падает вероятность такой подставы экспоненциально?
Может тогда сделать протокол (т.е. что чем компилировать), допускающий закладку, только если огромное количество разного софта имеет закладки, согласующиеся между собой (и что, следовательно, маловероятно)
Простейший пример «согласованного протокола бэкдоров»: при чтении скрывать участок кода, начинающийся с сигнатуры и выполнять инструкции из него.
При записи: дописывать в начало участок кода, начинающийся с сигнатуры и содержащий инструкцию о том, как поменять entry points, если таковые есть.
При исполнении: перед исполнением, после линковки, выполнить инструкции по замене entry points.
При записи: дописывать в начало участок кода, начинающийся с сигнатуры и содержащий инструкцию о том, как поменять entry points, если таковые есть.
При исполнении: перед исполнением, после линковки, выполнить инструкции по замене entry points.
Тогда заражённая ось, при запуске зараженного компилятора вылечит его, при чтении файла удалив зловреда по сигнатуре.
И, раз уж мы проектируем протокол глобального заговора, то как закладке при компиляции узнать функции компилируемой программы. Например, если это вьювер, то скрывать бекдор, а если это архиватор, то оставлять его (иначе при переносе на другую машину через архив компилятор вылечится).
Кроме того, как быть с размерами? В первом случае (вьювер) юзер должен видеть, что размер файла меньше (вредоносный код отсутствует), а во втором случае (архиватор) код должен остаться в файле и размер файла должен быть больше.
Эти вопросы практически невозможно решить.
Кроме того, как быть с размерами? В первом случае (вьювер) юзер должен видеть, что размер файла меньше (вредоносный код отсутствует), а во втором случае (архиватор) код должен остаться в файле и размер файла должен быть больше.
Эти вопросы практически невозможно решить.
Прямо-таки представляю, в бинарнике после дизассемблирования доверенным дизассемблером, написанным на асме, под доверенной ОС, вбитой механическими переключателями в память на магнитных сердечниках, на полностью открытом железе, спаянном из 32 миллиардов КТ315 вручную… 27 бэкдоров и один print(«Hello world!»)
А закладка - в...
А закладка в этом железе — нанопроцессоры, впаянные в сигнальные провода, соединяющие процессорный блок размером с комнату и блок памяти, занимающий вторую комнату.
в любой программном средстве написанном на компилируемых языках.
Что мешает сделать бинарный вирус для интерпретатора, который будет неявно добавлять закладку в текущую исполняемую программу? Тем более интерпретатор кто-то скомпилировал, даже если интерпретатор интерпретируется другим интерпретатором или мы имеем цепочку интерпретаторов, интерпретирующих следующий за ними интерпретатор, то проблема «начального» интерпретатора остается открытой.
А ведь компиляторы также компилируются компиляторами. Доверенному и проверенному исходному тексту компилятора нельзя верить до тих пор пока он сам не будет собран доверенным компилятором. Собирая новые версии компилятора размножается вирусный код в новых версиях компилятора. Яркий пример проявления проблемы «курицы и яйца».
Около 20 лет проблема считалась нерешаема.
В 2005 году Дэвид Уилер представил решение этой проблемы, позволяющий точно распознать успешно проведенную атаку на компилятор.
Основная сложность теории заключается в том, что необходимо наличие доверенного компилятора.
Что за наркомания? 20 лет думали, что нужен доверенный компилятор для сравнения бинарников?
Даже написав программу на чистых кодах асемблера, можно наткнутся на закладку(или неточность) процессора. А создав свой процессор с нуля можно наткнутся на закладку(или багу) природы.
Объяснение в инфографике imgur.com/a/BWbnU
Про Чёрных лебедей читал на lesswrong, сайте о рациональном мышлении. Идея интересная.
Про Чёрных лебедей читал на lesswrong, сайте о рациональном мышлении. Идея интересная.
UFO just landed and posted this here
Похоже на ночную страшилку для маленького ФСТЭКовца.
Мне рассказывали, что при разработке Бурана софт компилировался Фортраном, после чего декомпилировался программой на Рефале и результат сравнивался с исходниками. Так в компиляторе была найдена ошибка.
Сорри за некропостинг. Нужна была ссылка на статью о "проблеме доверенного компилятора".
Перечитал текст и комменты, но не нашел ссылок на инцидент когда была заражена Delphi, которая потом собирала зараженные бинарники.
Sign up to leave a comment.
Теория «Черного лебедя» и фундаментальная уязвимость автоматизированных систем