Обзор эксплойтов

Крис Касперски

Хакер, номер #095, стр. 095-060-2

Targets

Уязвимости подвержены все версии драйверов от 3 до 4.00.35 включительно, в том числе и Toshiba Bluetooth Stack 4 SP2. Эти драйверы поставляются вместе с оборудованием, выпущенным ASUS, Dell, Sony и другими компаниями. Определить, подвержено ли угрозе конкретно взятое устройство или нет, можно, во-первых, по наличию драйвера TOSRFBD.SYS, а во-вторых, по имени производителя (Toshiba) в свойствах беспроводного устройства.

Exploit

Для реализации атаки exploit'а не требуется, достаточно как следует пропинговать жертву, обрушив на нее шквал L2CAP-echo-запросов, что можно осуществить с помощью linux-утилиты l2ping. Атаки этого типа довольно широко распространены и называются BlueSmack. Подробнее о них можно прочитать на http://trifinite.org/trifinite_stuff_bluesmack.html.

Solution

Фирма Toshiba выпустила заплатки для своих драйверов, доступные для скачки по http://aps.toshiba-tro.de/bluetooth/redirect.php?page=pages/download.php. Однако следует помнить, что многие производители аппаратного обеспечения модифицировали оригинальные драйверы, и в этом случае обновления необходимо брать с их сайтов.

Переполнение буферов в суровых условиях висты

Brief

Есть две новости. Хорошая и плохая. Начну с хорошей. В Windows Vista/Server Longhorn полностью переписан сетевой стек и реализован IPv6, причем реализован очень коряво. Ранние беты повторяли практически все ошибки, допущенные в старом сетевом стеке, вылизываемом годами. И хотя основные дыры в Vista RC1 уже залатаны, сама новизна IPv6 протокола вкупе с непротестированным сетевым стеком выглядит весьма сексапильно и открывает огромные перспективы для всевозможных атак. Для хакеров это настоящий клад. Теперь плохая новость. Microsoft предприняла целый комплекс противохакерских мер, затрудняющих засылку shell-кода и реализацию большинства атак, поэтому, прежде чем виста станет доминирующей системой (а случится это, скорее всего, через год-полтора), злоумышленникам для адаптации к новым условиям потребуется проапгрейдить арсенал своего оружия. Что же это за защитные механизмы, и можно ли их обойти? Вот об этом мы сейчас и поговорим.

Intro

Основные оборонительные сооружения расставлены вокруг переполняющихся буферов, однако эта стратегия обречена на поражение, поскольку повышенный интерес к атакам этого типа уже позади. Достигнув пика своей популярности в 2005 году, переполняющиеся буферы «стали клониться к закату». Хакерская мысль не стоит на месте! Набирают силу атаки, основанные на ошибках синхронизации драйверов, примерами которых являются дыры в драйверах Intel Centrino и Toshiba Bluetooth, дающие захватчикам ядерные привилегии нулевого кольца! Но все-таки вернемся к переполняющимся буферам. Было бы глупо сдаваться без боя, тем более что оборону Microsoft'а сравнительно легко прорвать.

DEP

Доля процессоров с аппаратной поддержкой DEP обречена на неуклонный рост. И хотя на x86-платформах DEP по умолчанию включен только для некоторых системных служб, поскольку все еще существует множество приложений, нуждающихся в исполняемом стеке (особенно это относится к упаковщикам, протекторам и прочим защитным механизмам), разработчики уже отреагировали на эту инициативу. Новые версии (в своей массе) больше не трактуют атрибут PAGE_READ как PAGE_EXECUTABLE, и перед выполнением кода в области памяти, отличной от секции .text, атрибут PAGE_EXECUTABLE присваивается явно для того, чтобы программа могла работать при включенном DEP. Кстати говоря, это обязательное требование, предъявляемое Microsoft'ом при выдаче логотипа Windows Compatible. Несложно спрогнозировать, что через несколько лет программ, конфликтующих с DEP, практически не останется совсем и в очередном Service Packe'е для висты Microsoft запросто сможет поменять политику «DEP выключен по умолчанию для несистемных приложений» на «DEP включен по умолчанию для всех приложений». Сам по себе DEP несильно осложняет жизнь хакерам и легко обходится атаками типа return-to-libc (подробно описанными в моей статье «Судьба shell-кода на системах с неисполняемым стеком, или атака на DEP», которую можно скачать с ftp://nezumi.org.ru). Однако в комбинации с другими защитными механизмами DEP превращается в мощную броню, существование которой приходится принимать в расчет, как и тот факт, что эта броня прожигается кумулятивными снарядами, продвигаемыми на рынок самой же Microsoft под видом платформы .NET, базирующейся на интерпретируемом языке С#. Несмотря на то что C# намного меньше подвержен ошибкам переполнения, чем Cи, защитные свойства DEP'а на него не распространяются, поскольку интерпретируемый код с точки зрения процессора представляет данные, которые не нуждаются в атрибуте PAGE_EXECUTABLE. На самом деле, C# не совсем интерпретируемый, а компилируемый в память, причем откомпилированный код помещается в область памяти, доступную как для записи, так и для исполнения. Так что внедрение процессоров с поддержкой аппаратного DEP'а компенсируется победоносным шествием .NET'а, на котором удобно писать интерфейс, но реализовывать приложение целиком - нет уж, увольте. Во-первых, C# стоит намного ближе к Visual Basic'у, чем к Си, а какая у Basic'а производительность? Во-вторых, на Си/Си++ написано огромное количество библиотек, которые никто переписывать на .NET не собирается, и ближайшие 3-5 лет большинство программ продолжат стоиться по гибридному принципу — Си/Си++ плюс C#, что позволит эксплуатировать ошибки переполнения, характерные для Си/Си++, через C#! Если хакерская активность и снизится, то несильно.