>Рендеринг шрифтов как раз не "DLL ПОЛЬЗОВАТЕЛЬСКОГО РЕЖИМА" режима делает. Об этом
>собственно и речь. Да что Вы говорите... Я Вам повторно рекомендую прочитать о тех уязвимостях, что Вы же мне и привели. Если с английским все-таки проблемы, я могу помочь:
A heap overflow vulnerability exists in T2EMBED.DLL, which Internet Explorer invokes to process EOT fonts. The data within an EOT file is compressed in Agfa MicroType Express format, which hosts an LZ-compressed stream that includes a 24-bit allocation size. This size + 1C00h is allocated within the function MTX_LZCOMP_UnPackMemory, but the resulting allocation size is not validated before data is copied into the block, allowing a malformed EOT file to cause an essentially arbitrary-length heap buffer overflow with binary data.
Суть уязвимости такова: имеются так называемые встраиваемые шрифты, файлы с расширением .eot, имеется T2EMBED.DLL, DLL ПОЛЬЗОВАТЕЛЬСКОГО РЕЖИМА, которая занимается их декомпресией. В одной из функций этой DLL имеется бага, конкретно- heap buffer overflow, позволяющая злоумышленнику выполнить на атакуемой машине вредоносный код. Например во время чтения html-письмеца в Outlook или прогулки в Internet Explorer.
Я уже писал выше, что проблема эта - никак не связана именно с графической подсистемой Windows, которая представлена драйвером win32k.sys. Проблема именно в ВЫСОКОУРОВНЕВОЙ библиотеке ПОЛЬЗОВАТЕЛЬСКОГО режима, и Ваш пример с MS06-002 здесь _совершенно_ ни к месту.
Для желающих ознакомиться со статьей в оригинале: http://research.eeye.com/html/advisories/published/AD2006011...
>При чем тут ДРАЙВЕР win32k.sys?
Да, хороший вопрос. К тем биллютеням, что Вы мне привели якобы в пример, он действительно отношения не имеет. А вообще-то должен был иметь. Я Вам уже сказал, что примеры Вы не по теме привели.
>Бажный код - причина всех зол, несомненно. Но подумайте о последствиях. Если
>в итоге злоумышленник получает возможность выполнения своего кода на уровне ring0
Читайте Выше... Ни о каком выполнении кода в ring0 даже не идет речи
>Этой возможности не было в ранних версиях.
В ранних версиях NT графика находилась в процессе Win32-подсистемы, файлик называется csrss.exe. Файлик этот хоть и пользовательского режима, но все же не совсем обычный- любая ошибка в нем приводит к краху системы, точно так же, как если бы начал чудить драйвер режима ядра. Поэтому в отношении графики, перенос этого функционала в ядро, ничуть не сделал систему менее стабильной. Даже в WinNT 3.51 любая ошибка csrss.exe систему Crashила.
Нет, я конечно же согласен с тем, что с кернел-моде кодом нужно быть предельно осторожным, лично я обоими руками за то, чтобы все драйверы перетащить в юзерспейс, как только получится. Но покуда большинство их работает в режиме ядра, нечего лицемерить и обвинять винду, что она такая вся бажная из-за несчастной графической подсистемы в ядре.
