Содержание статьи
3. Атаки на SMM
SMM aka "Ring -2"
Режим системного управления – самый привилегированный режим выполнения на
процессорах архитектуры x86/x86_64, даже более привилегированный, чем режим
"ring 0" и аппаратный гипервизор (VT/AMD-v), известный также, как "ring -1".
Одной из причин, которая позволяет считать код SMM столь высоко
привилегированным, является его способность получать доступ ко всей системной
памяти, включая ядро и память гипервизора. Стандартные механизмы защиты памяти
операционной системы (Page Tables), равно как и средства виртуализации памяти
гипервизора (Shadow Paging, Nested Paging/EPT, IOMMU/VT-d) не срабатывают против
кода SMM.
Кроме того, на процессорах Intel код SMM может "перехватывать" даже
гипервизор VT-x всякий раз, когда поступает запрос на SMI-прерывание. Для
гипервизора существует способ установить специальный логический объект под
названием STM, позволяющий перехватывать SMI-прерывания. Подробнее мы обсудим
это позже. Опираясь на вышеизложенное, мы со всей смелостью можем
идентифицировать SMM как "ring -2".
Трудности с обнаружением уязвимостей в SMM
Наше желание изучить код SMM на наличие потенциальных проблем с безопасностью
столкнулось с нетривиальным затруднением, вызванным тем, что память SMM
оказалась недоступной ни для кого, кроме… самого SMM. Поэтому получить
действительный дамп кода SMM не представляется возможным. А если не будет
доступа к бинарному коду, не будет и возможности выявить в нем потенциальные
уязвимости. Так что на этом этапе мы были вынуждены сделать для себя довольно
обескураживающий вывод: без наличия хотя бы одного бага в коде SMM, который
можно было бы использовать для чтения его памяти, искать баги в памяти SMM
нельзя!
Мы обнаружили яркий пример порочного круга, частично объяснивший нам причины
того, почему в этой области было проведено так мало исследований.
Кого-то может прельстить мысль о том, что самым легким способом считать код
SMM и весь BIOS будет снять чип SPI с материнской платы и сделать дамп его
памяти при помощи программатора. К сожалению, все не так просто, как может
показаться. Выяснилось, что код BIOS в том виде, в котором он присутствует на
чипе, очень сильно упакован специальными алгоритмами и их расшифровка – задача
того же уровня, как скажем распаковка/деобфускация современных вредоносных
приложений, с той лишь разницей, что в процессе распаковки кода BIOS весьма
проблематично применять эмуляцию кода. Да и вообще весь код BIOS исполняется в
очень необычной среде ввода/вывода, которую трудно правильно имитировать.
Поэтому мы выбрали иной подход, о котором расскажем позже. Прежде чем мы
начнем, давайте взглянем на работы в области SMM и связанной с ним безопасности,
проведенные ранее другими экспертами.
Предыдущие исследования, связанные с SMM
Хотя за последние годы было сразу несколько
публикаций, затрагивающих
вопросы безопасности SMM, основной акцент в них делался на то, что
происходило уже после того, как хакер обходил защиту доступа к памяти SMM. В
основном это вызвано тем, что до недавнего времени получить права чтения/записи
памяти SMM было очень легко, для этого нужно было лишь настроить соответствующие
регистры чипсета.
Сегодня большинство современных систем используют целый ряд мер защиты памяти
SMM, в том числе организацию доступа только для чтения для операционной системы,
включая ядро и гипервизор.
Пример №1: баг с переадресацией в материнской плате Q35
Во время конференции Black Hat в августе 2008 года мы упомянули о баге,
обнаруженном нами в BIOS-е материнской платы DQ35JO, который позволял обойти
защиту памяти гипервизора Xen. После устранения бага компанией Intel мы
опубликовали все подробности атаки и образец кода.
При атаке использовалась функция чипсета по переадресации памяти (т.н. memory
reclaiming). В результате ее проведения можно было обойти некоторые механизмы
защиты памяти, используемые процессором и чипсетом. В том числе можно было
получить полный доступ к памяти SMM.
Это позволило нам проанализировать бинарный код SMM и обнаружить там другие
проблемы безопасности, о которых мы расскажем ниже.
Пример №2: VU#127284
10-го декабря прошлого года мы сообщили в Intel Product Security Response
Center об обнаруженных нами новых багах в SMM. Все они проистекали из одной
конструктивной особенности, позволяющей реализовывать определенный функционал
небезопасным способом. Эта недоработка привела к тому, что в обработчике SMM
появилось 40 с лишним дыр, позволяющих внедрить код в режиме SMM. Мы создали
эксплоиты только для двух из них, так как не видели смысла в попытках
использовать другие дыры. Правильное решение данной проблемы должно быть
основано на реконструировании нынешних обработчиков SMM. Не следует однако
путать ошибки в обработчике SMM с проблемами, затрагивающими TXT, речь о которых
пойдет в следующем разделе.
Эти новые дыры в SMM до сих пор не пропатчены Intel. Компания подтвердила их
наличие в материнских платах для мобильных, серверных и обычных платформ, не
уточнив при этом, какие именно модели материнских плат уязвимы. Мы подозреваем,
что данная проблема может быть присуща всем недавно выпущенным материнским
платам и BIOS-ам Intel.
Выход соответствующего патча для них ожидается ближе к лету этого года, а до
тех пор в Intel попросили нас не разглашать детали обнаруженных в SMM
уязвимостей. Мы планируем раскрыть их на конференции Black Hat USA 2009, которая
пройдет в июле.
В компании Intel также уведомили нас о том, что они сообщили об этой проблеме
в CERT CC, поскольку уверены, что аналогичные баги SMM могут присутствовать и в
BIOS-ах других вендоров. CERT CC присвоил этому инциденту номер VU#127284.
Обобщение проблем SMM
Двумя независимыми атаками на обработчики SMM мы показали, что даже
современные системы не в состоянии правильно защитить программы самого
привилегированного уровня, в том числе и те, которые работают в режиме
системного управления (System Management Mode). В определенном смысле код SMM
имеет даже более привилегированный уровень доступа, чем аппаратный гипервизор,
потому что для кода в этом режиме возможен доступ ко всей системной памяти, в
том числе и памяти гипервизора, но не наоборот.
Стоит все же отметить, что наши атаки на SMM по-прежнему не позволяют
перепрошить BIOS, поскольку современный BIOS хорошо защищен от перепрошивки в
него неподписанной версии. Также такие атаки не влияют на технологию Intel AMT,
которая не зависит от центрального процессора и не полагается на безопасность
SMM.
4. Проблема в концепции TXT
Выше мы упомянули о том, что лекарство от опасных обработчиков SMM называется
STM. Также мы выразили сожаление по поводу того, что на данный момент STM на
рынке не доступны, что позволяет применить разработанную нами атаку к любой
современной системе. Цель нашего исследования, помимо получения удовольствия,
заключалась в том, чтобы стимулировать разработчиков к созданию STM.
Поэтому первый вопрос напрашивается сам собой – кто должен взять на себя
ответственность за создание STM? Инженеры Intel считают, что это должны быть
либо поставщики базового оборудования, либо изготовители BIOS. Очевидно, STM
должен стать частью системной BIOS, так же как SMM.
В связи с этим возникает и второй вопрос – если мы не верим в способность
поставщиков оборудования создать безупречный код SMM, то почему мы должны
доверять им создание свободного от изъянов STM? Ведь он куда сложнее, чем
обычный SMM, так как STM – это гипервизор, который должен обеспечивать для
обработчика SMM виртуализацию памяти, ввода/вывода и обработки на процессоре.
Более того, он должен работать параллельно с существующими VMM, такими как Xen.
Два гипервизора должны общаться между собой, что в свою очередь требует создания
стандартизированного протокола обмена данными между гипервизорами. Наверное, нет
нужды говорить, что никакой публично доступной документации по написанию
рабочего STM компания Intel не предоставляет, хотя и заявляет о том, что в его
создании нет ничего сложного, а все необходимые для этого детальные спецификации
будут выложены в ближайшее время.
Процессорный гигант не видит необходимости в том, чтобы делать STM более
безопасным, чем SMM, поскольку его не нужно будет модифицировать так же часто,
как обработчики SMM, которые приходится перенастраивать для каждой новой
материнской платы. STM могут оставаться практически неизменными, что позволит
иметь в обращении всего несколько серьезных и тщательно проверенных образцов.
Тут в голову приходит третий вопрос – если STM на самом деле так легко
написать, то почему компания Intel все еще этого не сделала? Ведь подходящие
платы уже более года присутствуют на рынке, да и проекту Tboot уже не первый
год.
Intel в ответ заявляет, что до сих пор на рынке не было достаточного спроса
на STM, соответственно не были заинтересованы в нем и производители
оборудования.
Однако с такими контрдоводами мы вынуждены будем не согласиться. Во-первых,
не следует забывать о том, что компания Intel сама является производителем
оборудования и BIOS-ов, так как она продает материнские платы и делает
микросхемы BIOS к ним. Во-вторых, когда речь заходит о безопасности, нельзя
называть отсутствие спроса в качестве собственного оправдания. Если бы все
поступали подобным образом, мы до сих пор так и не начали бы пользоваться
функцией snprintf() :).
Поэтому мы должны задаться вопросом, настолько ли хороша была идея создания
такой TXT, которая потребовала введения более сложного инструмента под названием
STM для того, чтобы правильно функционировать? Может быть, было ошибкой
позволять TXT работать без STM? Ведь ее основной целью был отказ от Статического
корня измерения доверия (Static Root of Trust Measurement) в пользу
Динамического измерения доверия (Dynamic Trust Measurement). Даже если
предположить, что STM сам по себе не будет содержать ошибок, безопасность его
интеграции с TXT все равно остается под вопросом. Впрочем, ничего более
конкретного мы сказать не можем, пока не получим возможность взглянуть на
реальное применение STM.
5. Выводы
Мы описали успешную атаку против Intel Trusted Execution Technology. Также мы
установили работающий образец эксплоита, направленный против Xen, загруженного
через Tboot — предлагаемый Intel вариант реализации доверенной загрузки на
основе TXT.
Возможно, таким же интересным аспектом работы, как и сама TXT, стало
исследование новых атак на SMM. Сфера их применения простирается далеко за рамки
нападений на TXT, поскольку они дают возможность создать продвинутые руткиты,
бэкдоры и трояны. Баги в SMM могут быть также использованы для компрометации
памяти гипервизора в виртуализованных системах, даже таких продвинутых, как Xen
Подробности наших новых атак на SMM появятся в открытом доступе сразу после
того, как Intel пропатчит свое программное обеспечение, вероятнее всего, мы
представим все детали на конференции Black Hat USA летом 2009 года. Также мы
опубликуем код нашего эксплоита для TXT.
Оригинал:
http://invisiblethingslab.com/resources/bh09dc/Attacking Intel TXT - paper.pdf
