exploits-review-0x002

exploits review II

крискасперскиакамыщъх, no-email

brief:11 июля 2006 MarianoNuñezDiCroce, сотрудник копании CYBSEC S. A. (cybsec.com), опубликовал сообщение о переполнении буфера в MicrosoftWindowsDCHP-клиенте (технически реализованном как сервис), приводящем к возможности удаленного выполнения кода с привилегиями 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:компания CybsecS. A. будет удерживать все технические детали атаки (и сам exploit) в течении 30 дней, после чего выложит их в публичный доступ (как раз к выходу журнала из печати);

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

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

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 оказалась с ним категорически не согласна, опубликовав на своем SecurityResponseCenterBlog'е опровержение, что, мол, падать-то 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 и для них выпущены заплатки, некоторые все еще остаются не залатанными, поэтому не отрывайте документов, полученных из ненадежных источников!

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

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). На Security-Focus оно попало с огромным (и нехарактерным для него опознанием) — 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.

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

brief:13 июня 2006 на MicrosoftTechNet появилось сообщение о переполнении буфера в 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 SourceRouting (IP маршрутизацию от источника), путем создания параметра DisableIPSourceRouting типа DWORD со значением 2 в следующем ключе: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters и перезагрузив компьютер, причем на «нормальную» маршрутизацию пакетов это _никак_ не повиляет; в) заблокировать на брандмауэре IP-пакеты с опциями 131 (LSRR: LooseSource-n-RecordRoute — свободная маршрутизация от источника с записью маршрута) и 137 (SSRR: StrictSource-n-RecordRoute — жесткая маршрутизация от источника с записью маршрута). не путайте их с _портами_ – это не порты, а именно _опции_ IP‑пакетов, но к сожалению, далеко не все персональные брандмауэры позволяют осуществлять столь гибкую фильтрацию.

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

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

REM задаем IP-адрес (или доменное имя)

REM узла-жертвы, которую мы будем валить

SETtargetip=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 будь он все-таки упадет

gotorool

REM сюда мы переходим, когда посланный серверу

REM эхо-пакет уже не возвращается к нам назад.

REM сервер упал?! сервер упал!!! может быть…

:end

@cls

@Echo Server is crash

@pause

exit

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

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

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

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

Поле options служит для задания дополнительных опций, расширяющих возможности протокола IP. В частности, интересующая нас опция 131 (LooseSource-n-RecordRoute) и 137 (StrictSource-n-RecordRoute), описаны в 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.

exploits-review-0x002_image_4.jpg

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

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

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

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

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

Теперь, учитывая все вышесказанное, попробуем разобраться с exploit'ми. Ключ командной строки -jWindow-утилиты tracert (соответствующий ключу -gLinux-утилиты traceroute) задает свободный выбор маршрута по списку узлов, среди которых присутствует только один узел — 0.0.0.0. Это специальный IP-адрес, буквально обозначающий «данный узел». Ключ -h утилиты tracert (соответствующий ключу -m утилиты traceroute) ограничивает максимальное число переходов при поиске следующего назначенного узла, равное в данном случае 1, то есть, мы как бы имитируем «StrictSourceRouting» (на который 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) решает проблему (естественно, размеры буферов необходимо увеличить тоже), но атакуемые узлы упорно падать не хотят. Почему?!

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

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

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

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

Рисунок 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 из комплекта поставки MicrosoftVisualStudio, запустив его с ключом /DISASM.

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

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

* new.lst

00104B6pushdword ptr [eax]

00104B8callsub_2C1EB

00104BDmovedi, eax

* old.lst

00104B6pushdword ptr [eax]

00104B8callsub_2C10D

00104BDmovedi, eax

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

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

* new.lst

016C91movedx, ecx

016C93shreax, 10h

016C96shledx, 10h

016C99oreax, edx

* old.lst

016C91movedx, ecx

016C93shleax, 10h

016C96shredx, 10h

016C99oreax, edx

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

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

* new.lst

01381Bxorecx, ecx

01381Dmovch, al

01381Fmovcl, ah

013821mov[esi+0Eh], cx

* old.lst

01381Bxorecx, ecx

01381Dmovcl, ah

01381Fmovch, al

013821mov[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

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

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

01DF18mov d,[esi+20h], 1988Bhmov d,[esi+20h], 1988Bh

01DF1Fcall PsGetCurrentProcessIdcall PsGetCurrentProcessId

01DF24mov [esi+28h], eaxmov [esi+28h], eax

call PsGetCurrentProcessId

mov [esi+2Ch], eax

01DF27cmp [ebp+NewIrql], 2cmp [ebp+NewIrql], 2

01DF2Bmov [edi+8], esimov [edi+8], esi

01DF2Ejbe short loc_1DF40jbe short loc_1DF48

01DF30push asc_1DE7C; «Lock problems!!\n»push asc_1DE7C;«Lock problems!!\n»

01DF35call DbgPrintcall DbgPrint

01DF3Apop ecxpop ecx

01DF3Bcall DbgBreakPointcall DbgBreakPoint

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

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

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

Также рекомендуется прочитать руководство «Howto: HardentheTCP/IPStack»: 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.