Судя по всему, в новости и всякого рода инфолисты по безопасности попадают дыры ОС, представляющие собой явную угрозу, грубо говоря, возможность записать и исполнить собственный код, либо прочитать конфиденциальные сведения. А мне очень нужна ошибочка с переполнением чтения в win32k.sys, просто возможность прочитать то, что лежит на стеке. Судя по общей организации драйвера, такие ошибки там быть обязаны. Есть ли где-нибудь список подобных недоуязвимостей? И подскажите плз чайнику хорошие сайты с технической информацией по теме.
ormoulu Таких источников много, но они сильной информативностью не отличаются. Ресурсы типа http://www.securitylab.ru, http://www.securityfocus.com/, и куча таких... но они в основном друг у друга информацию переопубликовывают. В открытых источниках такая информация редко проскальзывает (хорошее описание уязвимости или эксплоит). Эксплуатировать можно все! (ведь BSOD это тоже атака!))))
Можно пример переполнения чтения оттуда? Может, я плохо ищу? BSOD мне не нужен. Мне нужно содержимое стека. В принципе, у меня уже наметился алгоритм по его вытаскиванию, но чужими знаниями пользоваться легче и приятнее
Этот тип уязвимостей называется "Information Disclosure", "Memory Leak" и т.д. искать также можно тут: http://secunia.com/advisories/historic/ вот тебе отличный пример Information Disclosure уязвимости в win32k.sys: http://j00ru.vexillium.org/?p=762
Можно вызвать теневой сервис с индексом за пределами сст. При этом можно прочитать часть секции данных ядра. Но подобное изврат. Элементарный аттач к необходимой сессии из ядра и напрямую чтение памяти это естественное решение.
ormoulu Сразу я подумал что вы хотите использовать стек для эскалации - тред вводится в ожидание на обьекте(аля NtWaitForSingleObject etc). Определяется дно стека и баланс стека до адреса возврата в нём. Далее по этому адресу загружается ссылка на стаб, который будет вызван при возврате в менеджер сисколов. При этом T-фрейм сформирован и !IRQL. После данной манипуляции поток выводится из ожидания и выполняется наш код с !CPL. Так как вы сказали про шадов, то логично предположить что необходимо читать его память, а это сессионное ап - для доступа к определённой сессии нужен аттач к ней(MmAttachSession()). Далее память ядра доступна непосредственно для процессора.
Да не, у меня задача гораздо проще - достать кое-какие параметры и переменные. Мне подошла бы возможность прочитать стек, либо пару байт по определенному адресу в ядре, либо записать свои пару байт по определенному адресу в ядре. Пока ни одной подходящей баги не нашлось
NTarakanov Какраз таки уязвимостей в нтос и шадове мало. Ядро уже слишком хорошо вылезано. Я уверен что вам ни одна нульдейная уязвимость не известна.
ormoulu Вы эксплуатируете Stack Overflow, и хотите затереть canary word правильным значением? На паблике поки/сплоиты есть в основном для никсов. У j00ru есть ещё некоторый материал, который Вам сможет помочь: http://j00ru.vexillium.org/?p=769 klzlk С этим можно поспорить: шадов, или win32k.sys(возьмём только 2010-2011 года): ms10-032 - 3 LPE MS10-048 - 4 LPE, 1 local DoS MS10-073 - 3 LPE ms10-098 - 6 LPE ms11-012 - 5 LPE MS11-034 - 2 LPE(но подвержены все GDI объекты, и векторов эксплутации много - поэтому выделили много номеров CVE) MS11-041 - 1 LPE И сюда ещё не включена ядерная часть по обработке шрифтов(atmfd.dll) - в которой было обнаружено тоже немало уязвимостей. К примеру, есть несколько уязвимостей, которые связаны с функцией CreateWindow тянутся от 90-х годов, до наших дней(причём весь ряд XP-7). И это не говоря уже о самой реализации(вызовы из ядра usermode ф-ий и т.д.)... В самом ядре(ntosrknl и остальные 3 версии) - то в нём устранялось меньше уязвимостей, но не стоит забывать, что в r0 присутствуют и другие компоненты, которые можно использовать для повышения првилегий. Это Ваше право!
klzlk Я привёл статистику исправленных уязвимостей, чтобы показать, что win32k.sys - это та ещё дыра в r0.Если вы просмотрите патчи, то в основном подвержена вся линейка винды, что говорит о том, что SDL на win32k.sys как-то не очень влияет Сама архитектура - оставляет желать лучшего в плане безопасноcти, почитайте отличную статью на этот счёт: http://www.uninformed.org/?v=10&a=2&t=txt
омг, какой SDL? код граф. подсистемы не менялся со времен когда его перенесли из юзермода в ядро. Про баги - любая сложная система содержит баги, старые фиксяться, новые вносяться. Эскалацию привелегий конечно найти легче в win32k.sys, чем в ядре.
