Оказывается американские власти неоднократно предпринимали попытки получить исходный код многочисленных программ. Сейчас они пытаются получить исходники iOS у компании Apple, но такие же требования выдвигались по отношению к другим фирмам, пишет ZDNet со ссылкой на анонимный источник.
Имея в эксклюзивном распоряжении исходный код, спецслужбам значительно проще искать уязвимости в программах. Затем эти уязвимости используются в интересах разведки и для защиты национальной безопасности.
Власти получают исходный код в рамках гражданских дел, которые рассматривают 11 судей секретного Суда по делам внешней разведки (Foreign Intelligence Surveillance Court, FISC) в соответствии с Актом о наблюдении за иностранной разведкой (FISA) от 1978 года.
Дела рассматривают в закрытом режиме, и разглашать информацию запрещено. Источник сообщил, что в таких процессах компании проигрывают «в большинстве случаев».
В министерстве юстиции США официально подтвердили, что и раньше получали исходный код программ в рамках судебных процессов. В процессе против Apple правительство сослалось на дело 2013 года против Lavabit, где суд удовлетворил требования министерства юстиции и затребовал у провайдера защищённой электронной почты Lavabit исходный код и секретные ключи шифрования.
По такой же схеме, на основе прецедента Lavabit, сейчас требуют исходники у Apple.
Издание ZDNet запросило комментарии у десятка крупных IT-компаний из списка Fortune 500, но ни одна из них не согласилась прямо ответить на вопрос, получали ли запросы из секретного суда FISC с требованием выдать исходный код или не получали таких запросов. Из молчания ИТ-компаний можно сделать определённые выводы.
Компания Cisco сказала, что «никогда не передавала и не будет передавать исходный код клиентам, особенно правительствам». Компания IBM сослалась на аналогичное заявление от 2014 года.
Microsoft, Juniper Networks и Seagate официально отказались отвечать. От Dell, EMC, Lenovo, Micron, Oracle, Texas Instruments и Western Digital не пришло никакого ответа.
Заметим, что некоторые из этих компаний упоминаются в 50-страничном каталоге закладок и бэкдоров АНБ, который в 2013 году рассекретил Эдвард Сноуден.
Компания Apple по делу Сан-Бернардино сказала, что не предоставляла никакому правительству проприетарный исходный код iOS, хотя государственные агентства разных стран, в том числе США, регулярно осуществляют аудит новых версий iPhone — компания Apple присылает им образцы для аудита.
Впрочем, если бы исходный код iOS был предоставлен спецслужбам по запросу FISC, то об этом могло не знать даже высшее руководство Apple, потому что суд действует в обстановке строгой секретности. Он обрабатывает 99% всех запросов, связанных с разведкой и слежкой. Например, в прошлые годы он одобрил сбор метаданных всех абонентов мобильной связи США, прослушку каналов связи в других странах, а также проведение целевых хакерских операций АНБ.
Решения суда настолько засекречены, что даже сам факт существования таких решений не подлежит огласке, в соответствии с законом FISA.
Комментарии (28)
meider
19.03.2016 16:38+7А ведь Столлман был в чем то прав,
Big Bro wathing you
Alex_ME
19.03.2016 17:12Но ведь в случае Open Source даже исходники предоставлять не надо. Конечно, security by obscurity (в данном случае — закрытый от спецслужб) далеко не панацея, но это +1 барьер в защите
AllexIn
19.03.2016 17:33это +1 барьер в защите
Не факт. Знание, что твои исходники будут хакать заставит внимательнее относится к качеству кода.Alex_ME
19.03.2016 18:01+1Думаю, Вы правы. В целом, Open Source софт показал себя как очень безопасный.
d_olex
19.03.2016 23:01Нет, наличие открытых исходников какого-либо продукта и количество уязвимостей в нем — это сущности которые не коррелируют друг с другом вообще никак. См. так же https://geektimes.ru/post/272978/#comment_9111022
Keyten
20.03.2016 17:18Почему "вообще никак", если любой может пофиксить уязвимость и отправить pull request / сделать форк?
d_olex
20.03.2016 18:09+3Как показывает жизнь — из того факта что «любой может» никак не следует то, что «любой будет». Так же я думаю что не последнюю роль здесь играет то, что разработчики разбирающиеся в безопасности составляют пренебрежительно малый процент от общего числа.
d_olex
19.03.2016 22:48> Имея в эксклюзивном распоряжении исходный код, спецслужбам значительно проще искать уязвимости в программах.
Это заблуждение которое распространяют люди имеющие туманное представление о том как работает vulnerability research.
Если говорить о ручном анализе — то с какими-то классами уязвимостей удобнее работать по сорцам, с другими же — в дизассемблере. Однако, даже полное отсутствие исходных текстов целевого ПО не является чем-то, что фатально снижает производительность труда исследователя.
Если говорить об автоматизированном анализе — то софт который ищет баги по машинному коду написать проще по той причине, что этот самый машинный код семантически намного проще чем почти любой современный язык используемый в промышленной разработке ПО.
qw1
20.03.2016 22:38+1Я с этим не согласен. Если автоматизированному софту без разницы, где искать подозрительные места, то дальше список передаётся человеку, который должен понять, можно ли тут использовать ошибку и если да, то как.
Например, софт нашёл 100500 ф-ций sprintf без проверки размера буфера. Но в одном случае это находка по адресу 0x004E71FD в процедуре 0x004E7100, а в другом — строка 7128 в ф-ции GenerateObjGUID, где исследователь только по названию ф-ции поймёт, что буфера в 64 байта достаточно под любой GUID и рыть тут больше нечего (а таких мест предстоит проверить ещё 100499)
Кроме того, огромное кол-во уязвимостей основаны на семантических ошибках — не поставили лимит на кол-во попыток входа в минуту, неправильно проверили security cookie (алгоритм никак не может знать, под что используется кука с именем id2, например). Тут только восстановление до семантики исходных кодов. Это очень трудоёмко, а исходники позволяют пропустить этот этап.d_olex
20.03.2016 23:31> Например, софт нашёл 100500 ф-ций sprintf без проверки размера буфера. Но в одном случае это находка по адресу 0x004E71FD в процедуре 0x004E7100, а в другом — строка 7128 в ф-ции GenerateObjGUID, где исследователь только по названию ф-ции поймёт, что буфера в 64 байта достаточно под любой GUID и рыть тут больше нечего (а таких мест предстоит проверить ещё 100499)
Это слишком примитивный пример, для анализаторов о которых говорю я такой проблемы не существует поскольку они работают принципиально по-другому:
1) В начале анализа оператор составляет список «точек входа» через которые исследуемая программа получает данные от потенциального атакующего;
2) Анализатор строит граф потока исполнения и граф потока данных исследуемой программы начиная с этих точек;
3) Когда в процессе построения графа потока исполнения встречается какое-то потенциально интересное место (например копирование данных на стековый буфер с помощью функции sprintf() как в вашем примере) — анализатор генерирует две системы констрейнтов: первая из них должна быть SAT для того что бы поток исполнения дошел до этого места, вторая должна быть SAT для того что бы в данной точке исполнения программа имела интересный атакующему контекст: например запись по адресу стека где хранится адрес возврата из подпрограммы;
4) Анализатор скармливает получившиеся системы констрейнтов SMT солверу, решение которое возвращает солвер (в том случае если оно возможно) — по факту представляет собой описание тех входных данных, которые, грубо говоря, атакующий должен скормить программе для того что бы проэксплуатировать конкретную уязвимость найденную в конкретной точке;
Это очень упрощенное описание того как все происходит, в реальной жизни в ходе подобного анализа применяется ряд дополнительных техник, например комбинация статического и динамического анализа (что бы анализатор имел представление о тех ветвях CFG/DFG которые невозможно разрезолвить в чистой статике), всякие костыли для обхода проблемы symbolic state explosion и прочие хитрые штуки.d_olex
20.03.2016 23:43+1В качестве примера публично доступных систем которые в той или иной мере реазилуют подобные концепции можете посмотреть BitBlaze, BAP, S2E, angr, Triton, misam.
Если хочется поиграться с каким-то совсем простым и наглядным примером — можете посмотреть мою статью про автоматический алгебраический криптоанализ: http://blog.cr4.sh/2015/03/automated-algebraic-cryptanalysis-with.html
В ней рассказывается про то, как из навоза и палок собрать систему которая будет автоматически генерировать кейген, генерация эксплойта для уязвимости почти ничем принципиально не отличается.qw1
21.03.2016 00:13Спасибо за примеры, посмотрю. Но мне казалось, что такой подход должен умереть в комбинаторном взрыве.
d_olex
21.03.2016 01:07+1В общем случае — все так, но для множества частных случаев в которые попадает большая часть всего программного кода это более-менее решается. Вот здесь например есть немного про обход проблемы комбинаторного взрыва: https://www.youtube.com/watch?v=Febh70kldP0
qw1
21.03.2016 00:33Это решает задачу, как уронить программу на некорректных данных, но не применимо к другим примерам:
- уязвимость в отсутствии ограничений на кол-во логинов в минуту.
- несогласованная работа security-компонент, вызванная тем, что одна компонента неправильно проверяет куку, сгенерированную другой компонентой или не проверяет её expire time (в формальной спецификации для солвера это заложить нельзя, т.к. до анализа приложения неизвестно, что эти фичи вообще есть в приложении).
И главное. Если всё с этими солверами так хорошо, что мешает вендорам ПО их использовать? Соответственно, все проблемы, находимые солверами, будут закрыты и останутся лишь уязвимости, которые требуют понимания программы человеком.d_olex
21.03.2016 01:00> Это решает задачу, как уронить программу на некорректных данных, но не применимо к другим примерам
Все перечисленное вполне себе решается, отсутствие исходных текстов ничего принципиально не меняет.
> И главное. Если всё с этими солверами так хорошо, что мешает вендорам ПО их использовать?
Примерно то же самое, что мешает им применять и более простые техники написания безопасного кода — security has no market value. C точки зрения бизнеса выкатить продукт на рынок раньше чем это сделают конкуренты — намного важнее чем выкатить более безопасный продукт когда-нибудь потом.d_olex
21.03.2016 01:40Вполне себе решается старым добрым ручным анализом, имею в виду. Подсистемы реализующе авторизацию, контроль доступа и прочие штуки относящиеся к безопасности — как правило составляют очень незначительный процент от общего кода приложения, плюс они имеют достаточно предсказуемый дизайн и методология их аудита обкатана и формализированна настолько, что это в состоянии освоить кто угодно.
qw1
21.03.2016 02:03Для старого доброго ручного анализа, почему "отсутствие исходных текстов ничего принципиально не меняет"?
Как минимум, прочитать DLL на C++ либо её декомпиляцию в IDA/XRAY — разница по времени на порядок (из-за отсутствия осмысленных наименований меток, нужно их все восстанавливать).d_olex
21.03.2016 02:06В разы, но никак не на порядок. Вы сейчас пытаетесь рассказать человеку который over 10 лет занимается backbox анализом ПО о том как офигенно сложно сделать blackbox анализ ПО.
d_olex
21.03.2016 02:18+1Алсо, это палка о двух концах: исходный текст не является программой, а всего-лишь инструкцией для компилятора о том как сгенерировать программу. В иной раз мне проще работать с машинным кодом, чем разбираться во что именно компилятор развернет трехэтажный С++ шаблон или адский макрос на конкретной версии компилятора с конкретными настройками среды сборки. Как было сказано выше — анализ по исходникам имеет свои плюсы, анализ по бинарникам — свои, утверждать что какой-то из них проще я, увы, не могу.
d_olex
21.03.2016 02:30+1Вот вам кстати вполне конкретный пример когда работать с машинным кодом сильно легче чем с исходниками: пару лет назад мне понадобилось разобраться с тонкостями работы интерфейса системных вызовов ядра Linux на x86_64 (нужно было патчить в нем кое-что на лету из гипервизора), покопавшись несколько часов в исходниках я офигел от адской лапши из директив препроцессора и в конечном итоге выяснил интересные мне подробности просто собрав ядро и загрузив его непожатый бинарник в IDA.
d_olex
21.03.2016 02:48+1Вот еще один пример: когда в 2010-м году для ОС Windows всплыла крайне интересная 0day уязвимость связанная с неправильным использованием функции nt!RtlQueryRegistryValues (http://blog.cr4.sh/2010/12/windows.html) я поставил перед собой цель найти больше 0day уязвимостей подобного класса (и таки нашел: http://blog.cr4.sh/2013/01/zeronights-2012.html). Так вот, даже если бы у меня были актуальные исходники ядра Windows — в том конкретном случае они бы ничем мне не помогли поскольку подобные уязвимости завязаны на значения неиницализированных стековых переменных которые решительно невозможно выяснить работая с исходными текстами.
d_olex
21.03.2016 01:19Алсо, не смотря на то что такими системами мало интересуются вендоры для которых security has no market value, ними очень даже интересуются спецслужбы и прочая военщина для которых vulnerabilities has market value. Та же DARPA спонсирует работу многих коллективов которые разрабатывают подобные системы.
d_olex
21.03.2016 01:24+1Алсо, вот пример «умного» анализатора от российской ИБ компании который вполне себе успешно применяется ними для аудита server side приложений: http://www.ptsecurity.ru/products/ai/
wbnet
Исходники Windows предоставлялись же ФАПСИ для прохождения сертификации. Сильно сомневаюсь, что с других поставщиков ПО этого не требовали. И тем более в США.