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

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

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

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

Распространено мнение, что эта технология присутствует только в некоторых современных чипсетах 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.

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

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

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

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