06.03.2013

Кремневый беспредел (часть 2.)

image

Продолжим нашу печальную историю…

Автор: R_Т_Т

Первую часть цикла можно посмотреть здесь.

Продолжим нашу печальную историю…

Но сначала еще раз о АМТ.

Распространено мнение, что эта технология присутствует только в некоторых современных чипсетах Intel, и для ухода от проблем безопасности достаточно выбирать чипсеты без поддержки АМТ. На данном этапе это уже не верно, последний чипсет 7 серии во всех модификациях поддерживает данную технологию.

И еще, к сожалению, проблема безопасности АМТ у нас абсолютно не обсуждается в силу безграмотности специалистов ИБ, но на западе полно публикаций на эту тему, с очень жесткими выводами. Наберите в поисковике: «Intel AMT backdoor» и убедитесь сами.

Командные подставы

Начну эту часть издалека. Был (дай бог пускай и сейчас здравствует) такой известный в компьютерных кругах человек Крис Касперски (Николай Лихачёв). Не путать, пожалуйста, с другим Касперским, хоть сферы деятельности этих людей раньше тесно пересекалась, совпадение фамилии одного и псевдонима другого чистая случайность. Крис Касперский был известным специалистом в области «белого» взлома, у него много публикаций на эту тему. Последняя публикация датируется серединой 2008 года и касается обнаруженных им уязвимостей в процессорах фирмы Интел.

Собственно как таковой публикации не было кроме безобидной презентации, ее можно посмотреть по ссылке здесь:

http://conference.hitb.org/hitbsecconf2008kl/materials/D2T1%20-%20Kris%20Kaspersky%20-%20Remote%20Code%20Execution%20Through%20Intel%20CPU%20Bugs.pdf

Но автор собирался сделать полный доклад и демонстрацию конкретного сплойта для обнаруженной им уязвимости в процессорах Intel на конференции Hack In The Box (HITB). Вот новость того времени: http://www.xakep.ru/post/44450/.

Доклад состоялся, но обнаруженная уязвимость и демонстрация ее эксплуатации так и не были представлены…, вместо этого докладчик оказался в Америке на ПМЖ уже осенью того же 2008года.

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

Между давними соперниками процессоростроения произошел крупный конфликт, приведший к «сливу» конфиденциальной информации о бекдорах в процессорах.

Сначала некий «независимый» специалист обнаружил недокументированные возможности в аппаратуре процессоров AMD вот ссылка на первоисточник: http://www.theregister.co.uk/2010/11/15/amd_secret_debugger/ . Речь конкретно шла об доступе к расширенным режимам контроля при вводе секретного ключа в один из РОН (EDI). Получить такую информацию исследовательским путем конечно невозможно, это явный «слив» направленный на дискредитацию производителя.

Но вскоре «империя» AMD нанесла ответный удар.

В середине прошлого года стала публичной информация о недокументированной возможности в аппаратуре процессоров Intel, только на этот раз бекдор сидел в процессорной команде и был гораздо серьезнее, почитать подробнее можно здесь: http://blog.xen.org/index.php/2012/06/13/the-intel-sysret-privilege-escalation/

Кстати, фирма Intel назвала это недокументированную возможность обтекаемой фразой «специфическая реализация» и не признала эту «особенность» бекдором или ошибкой реализации. Фирма так и поставляет процессора с этой, как она выражается; «специфической реализацией команды SYSRET».

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

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

Как ни странно, у нас, « как в Греции,- все есть…» необходимый научный задел в автоматизированной верификации системы команд в стране имеется. Несомненным лидером в этой области является Институт Системного Программирования Российской Академии Наук (ИСП РАН). К сожалению, наработки в области автоматизированной верификации процессорных структур этого института вместо нашего собственного государства использует Корея, фирма Самсунг в частности.

Вот и получается, что имеем не ценим, а окончательно потеряв, даже не заплачем…

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

Страсти по микрокоду

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

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

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

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

Другими словами, содержимое памяти микропрограмм можно подправить уже на действующем оборудовании, для этого используются специальные информационные блоки (microcode update).

У Intel все написано в документации (Vol. 3A глава 9.11 MICROCODE UPDATE FACILITIES). Механизм обновления микрокода для процессоров AMD можно обнаружить на официальном сайте, в документации он не описан. Алгоритмы обновления микрокода у обоих производителей практически одинаковы, различия только в структуре патча. Так что разберем тему на основе официальной документации Intel, вот выдержка:

9.11 MICROCODE UPDATE FACILITIES

The Pentium 4, Intel Xeon, and P6 family processors have the capability to correct errata by loading an Intel-supplied data block into the processor. The data block is called a microcode update. This section describes the mechanisms the BIOS needs to provide in order to use this feature during system initialization. It also describes a specification that permits the incorporation of future updates into a system BIOS.

Intel considers the release of a microcode update for a silicon revision to be the equivalent of a processor stepping and completes a full-stepping level validation for releases of microcode updates.

A microcode update is used to correct errata in the processor. The BIOS, which has an update loader, is responsible for loading the update on processors during system initialization (Figure 9-7). There are two steps to this process: the first is to incorporate the necessary update data blocks into the BIOS; the second is to load update data blocks into the processor.

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

Структура патча состоит из трех частей, первая часть «Header» и последняя «extended signature» описана в документации полностью, но они не несут существенного значения.

Самая главная часть («Date» - размер не фиксирован), - тело патча, не описана в документации, структура его не известна. Именно эта часть содержит микропрограммы, которые замещают прошитые на этапе производства микропрограммы процессора. Фирмы Intel и AMD не предоставляют никакой информации для того чтобы узнать хотя бы какие команды и режимы работы процессора подвергаются изменению.

Предполагается (так сказано в документации), что процедура обновления микрокода производится из БИОС, но нет никаких ограничений на ее проведение и во время последующей работы процессора. Другими словами, патчить микропрограмму процессора можно до бесконечности и во время работы операционной системы. Блокировок режима обновления микрокода в аппаратуре процессора не предусмотрено, проверки подлинности патча также нет. А вот это уже некорректно, и попахивает бекдором, скрытым под недокументированными возможностями

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

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

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

Вот пример такого файла обновления микрокода операционной системы Windows.

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

Еще одной проблемой становится БИОС материнских плат, там всегда имеется патч микрокода для процессора, но кто гарантирует, что он корректен? Недобросовестное искажение его содержимого возможно и на этапе его создания в Интел и на этапе заливки в БИОС при производстве материнской платы.

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

Вот мы и подошли к теме современных БИОС, но об этом в следующей части этого печального цикла статей...

или введите имя

CAPTCHA
Страницы: 1  2  3  4  
groovy-h
06-03-2013 16:18:00
Резюмируя обе части статьи, скажу автор подошел к теме довольно поверхностно, поскольку на современном уровне применяются не фиксированные программно-аппаратные "закладки", а динамически компилируемые из массы ничем не примечательного блочного кода (того же BIOS'а, к примеру или маркированного сетевого трафика). Современный загрузчик, обычно жестко зашитый, сам понимает какой код откуда брать и как из него лепить конечно прошиваемый набор инструкций. Прочитать полные исходники этого лодыря вам никто из производителей не даст. Много лет уже как специалисты (в т.ч. отечественные) осилили механизмы дизассемблирования и реверс-инжениринга рабочего кода ПЗУ многих устройств с разнообразными типами и архитектурами процессоров. Их выводы говорят о том, что сейчас наступает эра "облачных" скрытых функций: для примера, необходимы совокупность программной (драйверов, ПО) и аппаратной сред; уровень автономности каждой из них не является критически важным - наоборот, важна минимизация "вылова" этих бэкдоров. Советую почитать статьи и мнения людей о т.н. "Бирусах" (BIOS+virus=birus) в открытом доступе -- любителям конспирологии будет чем себя потешить. Кстати, пионерами в области "тяжелых" закладок являются таки Cisco, IBM и SUN, знаю это по собственному опыту поиска оных. З.Ы. "Тяжелыми" принято называть закладки с серьёзным функционалом, приводящим к полной блокировке базового функционала устройств или сетевых сред. Классификация идёт от какого-то фидошного трёпа MITовцев в начале 90-х (кстати, следы этого треда в инете уже давно иссякли).
0 |
серг
09-03-2013 11:01:23
В Статье "Китайские закладки, продолжение" говорилось о программе Абсолют, прошиваемой в БИОС. Чем Вам не Бирус? И причем здель конспирология? Тут реальные факты применения кода размещаемого в БИОС и на лету модифицируещего в файловой системе загрузочные файлы ОС Windows.
0 |
groovy-h
06-03-2013 16:27:14
Ну и само собой отражение нашей действительно в отдельно взятом "демократическом" государстве... [quote]Требование раскрытия спецификаций оборудования и исходных текстов ПО не являются экстраординарными, это обычная практика, можно привести пример Микрософта, который предоставлет для анализа полные исходные тексты ОС Windows в уполномоченную ФСБ организацию, - ГУП «Орион».[/quote] [offtop] Не ждёт ли нас скорая презентация в Сколково "новейшей российской" операционки "ОрионОС 8" с GUI "Шашечки Попова" "Иммунитетом" Бабушкина и видео-сенсором "Сракотан 360" от КТБ-Секьюрити? [/offtop]
0 |
Гость - вопрос для groovy-h
07-03-2013 10:12:45
ОрионНамедни Майкрософт проводил конференцию по методологии безопасной разработки ПО. Там был доклад от товарищей из Атласа. Кстати, готоворят (сам не присутствовал, к сожалению), доклад весьма интересный. И вроде бы упоминалось, что единственная организация, допущенная к исходникам ПО Майкрософт, это Атлас. Так какая всё-таки организация уполномочена исследовать ПО Майкрософт? Не то чтобы это принципиально важно, но избавиться от путаницы не помещает.
0 |
Для groovy-h
06-03-2013 19:32:49
Ну об таких "писателях" говорилось в первой части..., так что откуда Вы нас уже предупредили. groovy-h, Вы о чем? У автора все конкретно... А у Вас сплошной "этистолярный жанр"
0 |
узнал
06-03-2013 20:39:11
Да нет, он из конторы рангом пониже. ВСТЕК, его мать... ему мать родная. "З.Ы." узнаваемо, встречали этого кадра.
0 |
kazmt
07-03-2013 10:02:34
groovy-h , какие проблемы, напишите свою статью, мы все будем только рады.
0 |
Страницы: 1  2  3  4