>>Если ты контролируешь лишь часть, то ты можешь столкнуться с тем, что разработчики заметят, что разные сборки профайлера выдают разные результаты.
> Да. Но разработчики профайлеров, компиляторов, отладчиков, декомпиляторов, гипервизоров,
> биосов - это приоритетные цели.Нет. Приоритетные цели -- это _потенциальные_ разработчики профайлеров, компиляторов... и далее по списку. В приоритете любой Васян, которому приспичит поковырять недра компилятора, или написать свой компилятор, или свой отладчик, или гипервизор. Любой такой Васян может напороться на странность, забить на свой проект компилятор-just-for-fun и заняться ковырянием непонятности, на которую он напоролся.
> Атакующий первым делом бы составил список категорий софта, которые могут быть ему
> полезны. Потом бы составил список всех продуктов. Потом бы подготовил патчи.
> Потом бы атаковал всех разрабов этих продуктов. В первую очередь -
> разрабов компиляторов и детектирующего софта. Компиляторов - потому что через них
> заразит всех остальных, разрабов детектирующего софта - чтобы никто не обнаружил,
> ибо софт должен скрыть. План в принципе очень маловероятный, можно налажать
> и спалиться. С другой стороны, если никто выискивать не будет и
> всем пофиг, то даже фатально налажав можно долгое время не палиться.
> Долгое - это достаточное для фикса.
Тут ты сильно всё упрощаешь. Невозможно составить список всех продуктов. Разработчики вовсе не сидят все на одинаковых компиляторах и тем более на одинаковых версиях компиляторов. Они не пользуются одинаковыми тулзами, типа дебаггеров, профайлеров, бла-бла-бла. Каждый пользуется тем, что ему удобнее. У них при этом могут быть самописные утилиты. Любые из этих утилит могут не перекомплироваться годами -- нафига мне нужен распоследний gcc, если я не пользуюсь новыми фичами C? Разработчики могут работать с нескольких машин -- ноут, домашний десктоп, десктоп на работе, сборочный сервер, и на всех этих машинах могут стоять разные версии софта. Уже здесь возникает такой зоопарк, что проблема возникнет не на этапе составления списка софта, а уже на этапе составления списка возможных режимов провала, которые надо учесть разрабатывая схему инфецирования.
>> Вполне вероятно, да. Но если это повторится сто раз, то это будет менее вероятно.
> Я сильно сомневаюсь, что во всём мире есть хотя бы десяток разрабов,
> патчащих профайлеры под свои нужды регулярно.
А не надо никакой регулярности. Достаточно чтобы в год писалась бы сотня наколенных профайлеров. И даже не важна дальнейшая судьба этих профайлеров, даже не важно чтобы из них получалось что-нибудь завершённое, даже неудачная попытка написать профайлер может вскрыть странное поведение компилятора. Так же как и неудачная попытка написать дебуггер или гипервизор. Такие неудачные попытки -- это отличный способ понять принципы работы профайлера, дебуггера или гипервизора. Сколько реально таких попыток в год происходит оценить сложно: неудачные проекты, которые не добрались до чего-то хотя бы похожего на правду, остаются гнить на жёстком диске разработчика -- мы про них не узнаем никогда, и посчитать их не можем.
>> Это ещё почему? gcc -- это неплохая реалистичная тестовая нагрузка на процессор, которая всегда под рукой.
> GCC - это сложная программа, аномалии в поведении которой могут иметь много
> причин. Для теста профайлера она не подходит. Для теста профайлера нужны
> маленькие программы с полностью предсказуемым поведением и производительностью.
Маленькие тоже нужны, но gcc интересен как раз тем, что он выполняет много io, и вычислительно он нагружает процессор, и всякие заморочные структуры в памяти выстраивает. Тут тебе и парсинг, и всё что угодно. Плюс, ежели ты пишешь профайлер, то далеко не факт, что ты заглядывал в код файрфокса, а вот с кодом gcc скорее всего плюс-минус знаком, и поэтому он гораздо лучше подходит для тестов.
На простых тестовых программах ты можешь проверить, что твой профайлер делает именно то, что нужно. Но ты замучаешься придумывать тестовые программы, чтобы покрыть все edge cases, а если ты прогонишь свой профайлер через реалистичную нагрузку, вот тут эти самые edge cases и полезут изо всех щелей. Что позволит тебе написать тестовые программы, демонстрирующие эти edge cases.
>> Ещё раз говорю: ты не понимаешь менталитета исследователя. Если оно внезапно и необъяснимо пропадёт, то от этого ещё интереснее.
> Может и интереснее, но у людей свои проекты, исследовать что там налажали
> разрабы компилятора никому не упёрлось.
Вот сейчас ты рассуждаешь о разрабах так, будто они все одинаковы. Разработчики люди, а это значит, что они разные. Среди них есть такие, которые работают за еду, и всё за что не платят им не упёрлось. Но среди них есть и такие, для кого исследовательская деятельность является терминальной ценностью, то есть для того, чтобы заняться исследованием не нужно причин, достаточно найти возможность. И среди таких есть у кого есть на это время. И, я заверяю тебя, таких людей предостаточно.
>> Это ты к чему сейчас сказал?
> К тому что даже если дедлайны не горят, заниматься непрофильными исследованиями "шо
> там у разрабов компилятора за ошибка появилась и исчезла" в рабочее
> время ни один босс не позволит. "Исчезла, бизнес-процессы не блокирует -
> просто отлично, возвращайтесь к работе!" - скажет любой босс.
Начхать на этого босса. Дома я могу заниматься тем, что мне больше нравится, а не только тем, что хочется боссу.
>> Там очень много проблем с наложением патчей. Их надо разослать так, чтобы никто ни при каких настройках файрволов ничего бы не заметил.
> Но и файрволы, и DLP тоже можно пропатчить. Это если предположить, что
> ресурсы, выделенные на этот проект, достаточны. Я оценить ресурсы, необходимые для
> его реализации, не могу. Но явно меньше тысячи человек на фуллтайм
> требуется. АНБ точно по карману: AAA игры сравнимое количество разрабов делает.
Тебе придётся пропатчить все файрволлы. Для некоторых из них у тебя не будет сорцов. Тебе придётся пропатчить все антивирусы -- в венде они популярны, и они суют свой нос куда ни попадя. Они тоже подчастую без сорцов. Тебе придётся активно заниматься реверс-инжинирингом, и готовить бинарные патчи, и обновлять эти патчи при каждом минорном обновлении версии. Прежде чем пальцем в небо тыкать предполагать количество людей необходимых под такое, попробуй оценить количество пунктов в списке софта, который надо пропатчить, а потом посчитать суммарное количество обновлений версий софта из этого списка за год.
>>Нужно чтобы это произошло в весьма сжатые сроки, потому что если в мире будут существовать обновлённые компиляторы и необновлённые, то они будут генерить разные результаты, а это огромное палево: для исследователя безопасности изучать разницу гораздо переспективнее.
> Да. Спалиться можно. Но исследователей безопасности в мире не так много, и
> все заняты работой над конкретной программой.
Исследователем безопасности становится любой, кто напоролся на непонятность, заинтересовался, разобрался в причинах, и причина оказалась отличной от его ошибки. Я не являюсь исследователем безопасности, но со мной бывает, что я напарываюсь на что-то непонятное, и начинаю копать, просто для того, чтобы понять. Когда-то давным-давно я запускал снифер на сетевом интерфейсе и смотрел какие пакеты пролетают, и находя непонятный мне пакет начинал разбираться. Не потому, что я искал дыры, просто потому, что мне было интересно. Если бы в этот момент компилятор решил бы скачать обновлённый свой патч, я бы очень заинтересовался неожиданными пакетами. Если бы они не повторились бы, я бы нашёл способ отлавливать их и писать в лог информацию когда они возникают.
Последний раз я компилировал в ассемблер код наверное полгода назад -- я не помню, что там было, но происходило что-то непонятное мне, и я не понимал как так: у меня программа не работала так, как я задумал, и я не понимал что не так. Поэтому я начал втыкать в ассемблерные дампы, и сопоставлять инструкции ассемблера и строки исходного кода. Когда я разобрался в чём мой косяк, я ещё немного поигрался с кодом, уже чисто по фану, разглядывая на какие оптимизации компилятор способен, а на какие нет.
А, ещё тут как-то была моя попытка скомпилировать rust'овый код под дос -- там всё вообще было интересно, и пришлось разбираться с тем, что там rustc генерит, что там генерит llvm, как научить и тот и этот генерить 16-bit код, бла-бла-бла.
Года два назад, я компилировал в ассемблер потому что мне было интересно, что получится если на rust'е писать под avr. Сейчас я планирую заняться компиляцией в ассемблер mips -- мне сам mips любопытен, и... ну и под mips некоторые rust'овые пакеты не собираются (особенно из криптографии), потому как там оптимизации на ассемблере, а mips недостаточно популярен, я хочу поспособствовать исправлению ситуации. Но ты ж понимаешь, что прежде чем писать на асме, я приложу все усилия к тому, чтобы написать на rust'е, получив ту же производительность. А это значит, многократные компиляции в ассемблер с повышенным уровнем оптимизации, эти компиляции будут непонятны и запутанны, поэтому я начну компилировать в бинарь, и потом отлаживать инструкция за инструкцией, ну и... и значит что ежели компилятор будет добавлять лишний код, то я начну искать зачем он добавляет, я начну искать причину добавления, чтобы устранить эту причину. Возможно этой причиной будет несовершенство оптимизатора, возможно что-то ещё. Может быть причина будет неустранима, может быть нет. Но если у меня возникнут сомнения, я пойду обсуждать это с другими.
Я не исследую безопасность, но я нечаянно могу напороться на дыру в безопасности.
>> Тут столько граблей на пути, что обязательно что-нибудь пойдёт не так.
> Грабель действительно более чем дофига. Но я не уверен, что те организации,
> которым такое по карману, могут это зафейлить. Они и не такое
> проворачивали прямо под носом своих конкурентов. Чего только краденная документация по
> манхеттанскому проекту стоит, которую тппа должны были яро охранять, не то
> что какой-то компилятор, на который всем нaсрaть, но компрометация которого де-факто
> компрометирует всё.
Я по пунктам разберу написанное тобой:
1. Сложность проекта такого рода оценивается количеством грабель, на которые можно наступить, и я не уверен, что хоть одна из организаций, которое такое по карману, когда-нибудь сталкивалась с таким количеством граблей.
2. На манхеттенский проект ты смотришь, но видишь не то, что нужно. Манхеттенский проект было гораздо проще сокрыть, нежели инфекцию всех компиляторов, и тем не менее это не удалось.
3. На компилятор и возможность его компрометации не всем нacpaть. Тут иногда проскакивают новости о компиляторе C, написанном на схеме, которая написана на C. Мне лень искать ссылки, но там вся фишка в том, чтобы сделать bootstrappable компилятор C. Как ты думаешь, зачем люди этим заняты? А воспроизводимые сборки софта -- это зачем, как ты думаешь? Одна из причин заниматься и тем и этим -- избавиться от влияния существующего компилятора. И даже если это не даёт 100% защиты, это добавляет ещё больше граблей на пути у тех организаций во всемогущество которых ты веришь.
