Exploits review (выпуск 2)

Автор: (c)Крис Касперски ака мыщъх

NT: удаленная дыра в DCHP-сервисе

brief

11 июля 2006 Mariano Nuñez Di Croce, сотрудник копании CYBSEC S. A. (cybsec.com), опубликовал сообщение о переполнении буфера в Microsoft Windows DCHP-клиенте (технически реализованном как сервис), приводящем к возможности удаленного выполнения кода с привилегиями SYSTEM (что повыше администратора будет!), при условии, что атакующий и жертва находятся в одной подсети: cybsec.com/vuln/CYBSEC-Security_Pre-Advisory_Microsoft_Windows_DHCP_Client_Service_Remote_Buffer_Overflow.pdf. Сообщение тут же подхватила Microsoft, выпустив оперативную заплатку вместе с описанием проблемы на TechNet: microsoft.com/technet/security/Bulletin/MS06-036.mspx, где уязвимости был присвоен критический уровень опасности. Аналогичную оценку выставила и французская компания FrSIRT: frsirt.com/english/advisories/2006/2754;

targets

Уязвимости подвержены следующие системы: Windows 2000 Professional/Standard Server/Datacenter Server/Advanced Server; XP Tablet PC/Media Center/Home/Professional/Professional x64/Datacenter Server/Advanced Server; Server 2003 Standard/Standard x64/Web/Enterprise/Enterprise x64/Datacenter/Datacenter x64 со всеми установленными Service Pack'ми. На NT и 9x эта угроза не распространяется;

exploits

Компания Cybsec S. A. будет удерживать все технические детали атаки (и сам exploit) в течении 30 дней, после чего выложит их в публичный доступ;

solution

а) Установить заплатку от Microsoft, которую можно скачать с update.microsoft.com,
б) Отключить DHCP-клиента через Панель Управления -> Администрирование -> Службы -> DHCP-клиент -> Свойства -> Тип запуска -> Вручную; Свойства -> Стоп; или из командной строки "sc stop DHCP & sc config DHCP start=disabled", при этом перезагружаться совершенно необязательно. После останова DHCP-сервиса все IP-адреса локальной сети придется присваивать вручную (что легко осуществить дома, но намного сложнее в корпоративной сети). На выделение динамических IP-адресов по Dial-Up'у остановка DCHP-сервиса никак не скажется (подробнее о DCHP можно прочитать в IETF RFC 2131 - rfc.net/rfc2131.html);

Отключение DHCP-клиента

Рисунок 1. Отключение DHCP-клиента для предотвращения атаки через системную консоль.

MS Office: множественные переполнения буфера

brief

В июне-июле 2006 года сразу несколько независимых исследователей обнаружили множество ошибок переполнения в Microsoft Word/Excel и других приложениях, обрабатывающих документы MS Office, самая коварная из которых была замечена 10 июля 2006 года хакером по прозвищу naveed (naveedafzal@gmail.com) и относится к функции LsCreateLine, экспортируемой библиотекой mso.dll (или в более старых версиях офиса - mso9.dll). Специальным образом созданный doc-файл вызывает обрушение Word'а с ошибкой доступа, но также может перезаписывать произвольное двойное слово в памяти, позволяя осуществлять передачу управления на shell-код: securityfocus.com/archive/1/439649. Сообщение быстро расползлось по Сети: security.nnov.ru/Gnews345.html; securityfocus.com/bid/18905, но Microsoft оказалась с ним категорически не согласна, опубликовав на своем Security Response Center Blog'е опровержение, что, мол, падать-то Word падает (и уже не первый год!), а вот возможность передачи управления на shell-код весьма сомнительна: blogs.technet.com/msrc/archive/2006/07/10/441006.aspx; лично мыщъх после отладки и дизассемблирования придерживается мнения naveed'а.

Также была обнаружена кривизна в реализации указателей на объекты, приводящая к возможности выполнения shell-кода (securityfocus.com/bid/18037), и уже появилась пара вирусов-червей (!!!), распространяющихся через эту дыру: Backdoor.Ginwui (symantec.com/avcenter/venc/data/backdoor.ginwui.html) и Trojan.Mdropper.H, (securityresponse.symantec.com/avcenter/venc/data/trojan.mdropper.h.html).

Имеются ошибки и в обработке графических файлов форматов GIF и PNG, опять-таки приводящие к возможности выполнения shell-кода: (securityfocus.com/bid/18913 и securityfocus.com/bid/18915).

Свойства объектов (property) и разборка (parsing) строк не отстают от своих товарищей и выполняют shell-код не хуже остальных (securityfocus.com/bid/18911 и securityfocus.com/bid/18912).

Не остается без внимания и Excel - в обработке стилей и выделении записей обнаружены дефекты, приводящие к возможности... выполнения shell-кода: securityfocus.com/bid/18872, securityfocus.com/bid/18422 и securityfocus.com/bid/18885;

Плеяду ошибок завершает дыра в библиотеке hlink.dll, отвечающая за обработку стилей разных типов записей и при определенных обстоятельствах допускающая передачу управления на зловредный код: security.nnov.ru/Gnews270.html;

target

Вся линейка продуктов MS Office различных версий;

exploits

securityfocus.com/data/vulnerabilities/exploits/MSOffice_mosdll_poc.c;

downloads.securityfocus.com/vulnerabilities/exploits/excel-rce-nsrocket.txt;

securityfocus.com/data/vulnerabilities/exploits/Nanika.xls;

bsdpakistan.org/downloads/wordPOC.c;

solution

Некоторые из вышеперечисленных дыр успешно подтверждены Microsoft и для них выпущены заплатки, некоторые все еще остаются незалатанными, поэтому не отрывайте документы, полученные из ненадежных источников!

Исследование упавшего Word'а

Рисунок 2. Исследование упавшего Word'а под отладчиком OllyDbg.

WinAmp: переполнение буфера в midi

brief

19 апреля 2006 года в популярнейшем mp3-проигрывателеле WinAmp от Null-soft был обнаружен дефект в библиотеке in_midi.dll, отвечающей за проигрывание midi-файлов и некорректно проверяющей правильность заполнения некоторых полей, в результате чего у атакующего появилась возможность "уронить" WinAmp (который при этом настойчиво предлагает перезапустить систему, хотя ее можно и не перезапускать) или передать управление на shell-код. Следующий 34-байтовый midi-файл основательно сносит WinAmp'у крышу:

0000000000: 4D 54 68 64 00 00 00 06 | 00 00 00 01 00 60 4D 54
0000000010: 72 6B 00 00 00 FF FF FF | FF FF FF FF FF FF FF FF
0000000020: FF 00                   |

Листинг 1. Дамп midi-файла, вызывающего обрушение WinAmp'а.

Поскольку WinAmp может быть настроен так, чтобы проигрывать midi-содержимое Web-страничек вместо основного системного проигрывателя (многие пользователи именно так его и настраивают), угроза очередной вирусной эпидемии принимает довольно масштабный характер, особенно учитывая тот факт, что WinAmp (в отличие от системы) практически никто не обновляет. К тому же, исходное сообщение о дыре осталось незамеченным даже когда оно было опубликовано вторично: 29 мая 2006 года, то есть ровно через месяц спустя: (fortinet.com/FortiGuardCenter/advisory/FG-2006-16.html). На SecurityFocus оно попало с огромным (и нехарактерным для него опозданием) - 19 июня 2006 года: securityfocus.com/bid/18507;

targets

Все версии WinAmp'а вплоть до 5.21 включительно;

exploit

securityfocus.com/data/vulnerabilities/exploits/winamp_midi_bof.c;

solution

а) Обновите свою версию WinAmp'а до 5.22 (или выше), если, кончено, вам нужны все эти навороты, несовместимость с ранними plug-in'ми и тормоза на слабых машинах;
б) Не используйте WinAmp для проигрывания midi-файлов, сбросив соответствующую галочку в файловых ассоциациях, а для большей надежности еще и удалите файл in_midi.dll из каталога Plugins.

Обрушение WinAmp'а

Рисунок 3. Обрушение WinAmp'а c ZDL-ANALOG-STUDIO-5 скином.

Full disclose: NT - удаленная дыра в TCP/IP-драйвере

brief

13 июня 2006 на Microsoft TechNet появилось сообщение о переполнении буфера в TCP/IP-драйвере, позволяющее "уронить" систему в голубой экран смерти и даже передать управление на shell-код, выполняющийся с привилегиями SYSTEM: microsoft.com/technet/security/Bulletin/MS06-032.mspx; опасности был присвоен important-статус (значительная) и через несколько часов она перекочевала на www.securityfocus.com и другие хакерские сайты.

targets

Уязвимости подвержены следующие системы: NT Workstation/Standard Server/ Terminal Server/Enterprise Server; W2K Professional/Standard Server/Datacenter Server/Advanced Server; XP Tablet PC/Media Center/Home/Professional/Professional x64/Datacenter Server/Advanced Server; Server 2003 Standard/Standard x64/Web/Enterprise/Enterprise x64/Datacenter/Datacenter x64 со всеми установленными Service Pack'ми. Другими словами, уязвима вся линейка NT-подобных систем, на 9x эта угроза не распространяется;

exploits

securityfocus.com/data/vulnerabilities/exploits/18374-DoS-PoC.c;

securityfocus.com/data/vulnerabilities/exploits/18374-DoS-PoC.txt;

solution

а) Установить заплатку от Microsoft, которую можно скачать с update.microsoft.com,
б) Отключить IP Source Routing (IP-маршрутизацию от источника) путем создания параметра DisableIPSourceRouting типа DWORD со значением 2 в следующем ключе: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters и перезагрузив компьютер, причем на "нормальную" маршрутизацию пакетов это никак не повиляет; в) Заблокировать на брандмауэре IP-пакеты с опциями 131 (LSRR: Loose Source-n-Record Route - свободная маршрутизация от источника с записью маршрута) и 137 (SSRR: Strict Source-n-Record Route - жесткая маршрутизация от источника с записью маршрута). Не путайте их с портами - это не порты, а именно опции IP-пакетов, но к сожалению, далеко не все персональные брандмауэры позволяют осуществлять столь гибкую фильтрацию.

details

Дыру в TCP/IP обнаружил наш соотечественник Андрей Минаев (angel3000@hotbox.ru), обративший внимание на странное поведение системы при обработке IP-пакетов с взведенной опцией свободной/жесткой маршрутизации и промежуточным адресом, равным 0.0.0.0, что трактуется как "адрес данного узла". Если на целевой системе работал NAT-сервер (Network Address Translation - Сервер Трансляции Сетевых Адресов), встроенный, в частности, в Windows 2000, то система выпадала в BSOD с ошибкой в TCPIP.SYS, NTOSKRNL.EXE или начинала вести себя нестабильно, что вполне типично для ошибок переполнения с "ударом по памяти".

Пара хакеров, называющих себя Jimmy и ByteCoder+ тут же написала exploit, представляющий собой простейший командный файл, запускаемый из под Windows 9x или NT-подобных систем и устраивающий уделенному узлу настоящее харакири, причем атакующий может находится как внутри локальной сети, так и вне ее:

REM задаем IP-адрес (или доменное имя)
REM узла-жертвы, которую мы будем валить
SET targetip=192.168.0.6

:rool
REM посылаем IP-пакеты с взведенной опцией
REM "Loose Source-n-Record Route" в цикле,
REM указав в списке маршрутов адрес 0.0.0.0
REM
REM ===========  ВНИМАНИЕ!!!!  =============
REM под LINIX утилита traceroute вызывается
REM со следующими ключами командной строки:
REM #targetip=192.168.0.6
REM #traceroute -m 1  -g 0.0.0.0 ${targetip}
REM ========================================
tracert -h 1 -j 0.0.0.0 %targetip%
tracert -h 1 -j 0.0.0.0 %targetip%
tracert -h 1 -j 0.0.0.0 %targetip%

REM посылаем серверу эхо-пакет, чтобы выяснить,
REM жив ли он еще или уже упал смертью храбрых
ping %targetip% -n 1 || goto end

REM если мы здесь - переход на end не сработал:
REM сервер шлет нам привет, ну а мы продолжаем
REM слать ему IP-пакеты, надеясь, что когда-нибудь
REM он все-таки упадет
goto rool

REM сюда мы переходим, когда посланный серверу
REM эхо-пакет уже не возвращается к нам назад.
REM сервер упал?! сервер упал!!! может быть...
:end
@cls
@Echo Server is crash
@pause
exit

Листинг 2. Простейший exploit, атакующий сервер путем посылки пакетов со взведенной опцией Loose Source-n-Record Route.

Для эстетов хакер по кличке Preddy из RootShell Security Group создал Си-версию exploit'а, работающую как под NT/9x, так и под Linux: securityfocus.com/data/vulnerabilities/exploits/18374-DoS-PoC.c;

Чтобы понять, как работает exploit, необходимо рассмотреть заголовок IP-пакета, представленный на рис 4.

Формат IP-заголовка

Рисунок 4. Формат IP-заголовка.

Поле options служит для задания дополнительных опций, расширяющих возможности протокола IP. В частности, интересующие нас опции 131 (Loose Source-n-Record Route) и 137 (Strict Source-n-Record Route), описаны в RFC-791 (rfc.net/rfc791.html), а также во множестве независимых источников, например, энциклопедии "аппаратных средств локальных сетей" Михаила Гука (shop.piter.com/chapt.phtml?id=978580460113) или в "Протоколе IP": ariu.berdyansk.net/~andy/telecom_technology/1522-4.html#2.4.4.

Формат поля опций IP-пакета

Рисунок 5. Формат поля опций IP-пакета при свободной/жесткой маршрутизации от источника.

Обе опции действуют практически одинаково и позволяют отправителю пакета самостоятельно выбирать маршрут следования. Разница между свободной и строгой маршрутизацией заключается лишь в том, что при свободной маршрутизации очередной узел навязанного маршрута может быть достигнут за любое количество переходов (также называемых хопами), а при жесткой - очередной узел должен быть достигнут за 1 переход, а если это невозможно, пакет уничтожается с генерацией ICMP-сообщения о невозможности доставки.

Список узлов, через которые должен пройти пакет, содержится в поле данных, которое вмещает до 9 IP-адресов, перечисляемых в порядке следования. Поле ptr указывает на текущий номер обрабатываемого узла и каждый раз увеличивается на 4 (длина IP-адреса в сокетах), причем номер первого адреса равен 4.

Рассмотрим пакет, направляющийся из узла X в узел Y и проходящий через маршрутизаторы M1 и M2. На выходе из узла X в поле "Destination Address" (адрес назначения) IP-пакета содержится адрес M1, а в списке "навязанных" адресов (в поле options) - M2 и Y, при этом ptr равен 4, т.е. указывает на M2. По прибытии пакета на M1 из поля "навязанных" адресов извлекается адрес, определяемый указателем ptr (в данном случае это M2) и копируется в поле "Destination Address", ptr увеличивается на 4, а поверх адреса M2 записывается адрес того интерфейса маршрутизатора M1, через которой пакет будет направлен на M2 (это и называется "записью маршрута"). По прибытии на M2 вся процедура повторяется и пакет передается конечному получателю Y, а в поле опций оказывается записанным маршрут пересылки. Когда узел Y получает пакет с опцией Loose Source/Strict Source, он должен использовать записанный маршрут для обратной отправки отклика.

Опции Loose/Strict Source Routing могут быть использованы для несанкционированного проникновения через неправильно настроенный брандмауэр: в поле destination address устанавливается разрешенный адрес и пакет благополучно пропускается брандмауэром, далее из поля опций извлекается запрещенный адрес (который забывает проверить брандмауэр) и пакет перенаправляется по навязанному маршруту прямиком к атакуемому узлу, но к описываемой дыре в TCP/IP-протоколе эта особенность никак не относится.

Теперь, учитывая все вышесказанное, попробуем разобраться с exploit'ми. Ключ командной строки -j Windows-утилиты tracert (соответствующий ключу -g Linux-утилиты traceroute) задает свободный выбор маршрута по списку узлов, среди которых присутствует только один узел - 0.0.0.0. Это специальный IP-адрес, буквально обозначающий "данный узел". Ключ -h утилиты tracert (соответствующий ключу -m утилиты traceroute) ограничивает максимальное число переходов при поиске следующего назначенного узла, равное в данном случае 1, то есть, мы как бы имитируем "Strict Source Routing" (на который tracere/traceroute не способны) на основе опции "Loose Source Routing", поддерживаемой утилитами трассировки. Что же получается в итоге?

А вот ни хрена не получается! Мыщъх'у, несмотря на все усилия, так и не удалось завалить ни одну систему из списка уязвимых - ни в локальной сети, ни через Интернет, ни из-под Windows, ни из-под Linux. Прежде всего, в Си-версии exploit'а допущена грубая ошибка, ограничивающая предельную длину IP-адреса всего 9 знаками, то есть при попытке атаковать, например, "192.168.7.2" IP-адрес усекается и атакуется несуществующий узел "192.168.7" Замена всех strncat(x,y,9) на strncat(x,y,15) решает проблему (естественно, размеры буферов необходимо увеличить тоже), но атакуемые узлы упорно падать не хотят. Почему?!

Узел 192.168.7.2

Рисунок 6. Узел 192.168.7.2 (работающий под управлением W2K) благополучно переживает атаку и не падает.

Запускаем sniffer, смотрим на содержимое отправляемых пакетов (см. рис. 7) и видим, что адрес 0.0.0.0 вообще не попадает в "навязанный" список узлов и вместо него там оказывается destination-адрес, продублированный в соответствующем поле IP-заголовка. Не исключено, что в какой-то конфигурации, которую мыщъх'у так и не удалось воспроизвести, это вызывает помешательство NT и она начинает посылать пакеты сама себе, проваливаясь в бесконечный цикл, завершающийся переполнением стека или поля опций IP-пакета, но... как бы там ни было, Microsoft все-таки выпустила patch и представляет большой интерес распотрошить его и посмотреть - что же все-таки изменилось?

Исследование IP-пакетов

Рисунок 7. Исследование IP-пакетов, отправляемых exploit'ом.

Сейчас мыщъх продемонстрирует интересную технику поиска различий, которая неоднократно пригодится нам, хакерам, в будущем. Берем в руки файл Windows2000-KB917953-x86-RUS.EXE (для XP он будет слегка иным, но общий принцип действий останется неизменным), загружаем его в hiew и ищем строку "MSCF" (Microsoft Cab-File), следующую за длинной последовательностью "PADDINGXXX". Перемещаем курсор на первый символ "MSCF" и нажимаем <*> (начало выделения блока), а затем топчем <CTRL-END> для перемещения в конец файла. Нажимаем <*> еще раз и записываем блок в файл клавишей <F2>. Называем его, ну, скажем, TCP.CAB и открываем любым подходящим архиватором, например, RAR'ом.

Выдирание cab-архива

Рисунок 8. Выдирание cab-архива из exe-файла в hiew'е.

Там среди прочего потребительского барахла, присутствующего во всех обновлениях, мы обнаружим TCPIP.SYS - то, что нужно! Вытаскиваем его из архива и сравниваем с имеющейся у нас версией.

Истинное содержимое файла

Рисунок 9. Истинное содержимое файла Windows2000-KB917953-x86-RUS.EXE.

Сразу же бросается в глаза, что длины файлов не совпадают - 320.176 байт старой версии против 320.336 байт у новой, поэтому прямое побайтовое сравнение невозможно! Очевидно, драйвер был перекомпилирован и необходимо прибегнуть к дизассемблированию, сравнивая версии на уровне мнемоник машинных команд (навряд ли весь исходный текст драйвера был изменен). Дизассемблируем оба драйвера с помощью IDA Pro и сохраняем полученные листинги в файлы old.lst и new.lst (от экспорта в аsm-формат лучше воздержаться, поскольку у него не лады с табуляцией и мы не сможем отрезать операнды машинных инструкций, когда нам это будет необходимо). При отсутствии IDA Pro можно воспользоваться утилитой DUMPBIN из комплекта поставки Microsoft Visual Studio, запустив ее с ключом /DISASM.

Сравнение разных версий

Рисунок 10. Сравнение разных версий файлов GUI-утилитой windiff.

Полученные листинги можно сравнить либо "продвинутой" графической утилитой windiff, также входящий в состав Microsoft Visual Studio или простой консольной fc.exe позаимствованной из штатной поставки Windows NT. Тут же обнаружится следующая пренеприятнейшая проблема: поскольку после рекомпиляции многие смещения изменились, то утилиты сравнения выдают ворох ложных срабатываний, в котором очень легко утонуть, так и не добравшись до истины – вот, например:

***** new.lst
00104B6        push   dword ptr [eax]
00104B8        call   sub_2C1EB
00104BD        mov    edi, eax
***** old.lst
00104B6        push   dword ptr [eax]
00104B8        call   sub_2C10D
00104BD        mov    edi, eax

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

Очевидно, что здесь вызывается одна и та же процедура (кто не верит, может посмотреть код самой процедуры), но... утилитам сравнения этого ведь не объяснишь. А свой собственный скрипт писать лень. К тому же обнаруживается довольно странное поведение компилятора, иногда меняющего порядок следования команд в новой версии драйвера:

***** new.lst
016C91        mov   edx, ecx
016C93        shr   eax, 10h
016C96        shl   edx, 10h
016C99        or    eax, edx
***** old.lst
016C91        mov   edx, ecx
016C93        shl   eax, 10h
016C96        shr   edx, 10h
016C99        or    eax, edx

Листинг 4. Странное изменение порядка следования команд в разных версиях файлов.

То же самое происходит и с регистрами:

***** new.lst
01381B        xor    ecx, ecx
01381D        mov    ch, al
01381F        mov    cl, ah
013821        mov    [esi+0Eh], cx
***** old.lst
01381B        xor    ecx, ecx
01381D        mov    cl, ah
01381F        mov    ch, al
013821        mov    [esi+0Eh], cx

Листинг 5. Странное изменение выбора регистров в разных версиях файлов.

Сдохнуть можно! А ведь это еще не самое страшное! Поскольку в начале каждой строки стоит ее адрес, то при "раздвижке" одной или нескольких функций оставшаяся часть файла трактуется как "измененная", хотя на самом деле изменились только адреса. Какой же выход? Копируем old.lst в old-1.lst, загружаем его в FAR по <F4> и, удерживая клавишу <ALT> (вместо <SHIFT>) вертикальными блоками отрезаем все операнды инструкций и адреса, стоящие в начале строки. Аналогичную операцию проделываем и над new.lst. В результате чего получаем два симпатичных файла вида:

push
mov
call

Листинг 6. "Обрезанный" листинг, содержащий только мнемоники команд.

Пропускаем их через FC с обязательным выводом номеров строк (за это отвечает ключ /N), иначе мы потом не найдем соответствующие им адреса в old.lst/new.lst файлах и... с замиранием сердца наблюдаем за процессом. Конечно, мы получим много ложных срабатываний, уже приведенных в листинге 4. Но их очень легко отсеять чисто визуально - меняется лишь порядок следования команд, но сам шаблон остается неизменным. А вот и первое действительное различие:

***** old1.lst
024127:        mov
024128:        cmp
***** new1.LST
024127:        mov
024128:        call
024129:        mov
024130:        cmp

Листинг 8. Реальное различие между старой и новой версией драйвера.

В прежней версии TCPIP.SYS никакого call'а не было!!! А ну-ка заглянем в дизассемблерный текст, открыв old.lst/new.lst файлы и перейдя к строке 24127.

01DF18    mov  d,[esi+20h], 1988Bh             mov  d,[esi+20h], 1988Bh
01DF1F    call PsGetCurrentProcessId           call PsGetCurrentProcessId
01DF24    mov  [esi+28h], eax                  mov  [esi+28h], eax
                                               call PsGetCurrentProcessId
                                               mov  [esi+2Ch], eax
01DF27    cmp  [ebp+NewIrql], 2                cmp  [ebp+NewIrql], 2
01DF2B    mov  [edi+8], esi                    mov  [edi+8], esi
01DF2E    jbe  short loc_1DF40                 jbe  short loc_1DF48
01DF30    push asc_1DE7C; "Lock problems!!\n"  push asc_1DE7C;"Lock problems!!\n"
01DF35    call DbgPrint                        call DbgPrint
01DF3A    pop  ecx                             pop  ecx
01DF3B    call DbgBreakPoint                   call DbgBreakPoint

Листинг 9. Сравнение дизассемблерных листингов двух версий TCPIP.SYS.

В старой версии драйвера был только один вызов PsGetCurrentProcessId и переменная [esi+2Ch] оставалась неинициализированной. Теперь это исправлено. Аналогичным путем находятся и другие различия. Признайтесь, разве это не интересно - узнать, что же реально исправила Microsoft и где находится источник проблемы? Проанализировав ситуацию, мы все-таки сможем исправить exploit, заставив его работать! (Копия экрана, подтверждающая это, приводится ниже, но по понятным соображениям исправленный exploit не распространяется, во всяком случае до тех пор, пока большинство пользователей не почешется обновить свою систему).

Доработанный мыщъх'ем exploit

Рисунок 11. Доработанный мыщъх'ем exploit валит систему с двух пакетов.

Также рекомендуется прочитать руководство "How to: Harden the TCP/IP Stack": msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/HTHardTCP.asp и ознакомиться с информацией о двух других дырах в TCP/IP-драйвере, допускающих выполнение shell-кода: securityfocus.com/bid/18325 и securityfocus.com/bid/18374.