Вот знаю, что в никсах, ценятся такие очень не плохо. А что насчёт винды. Кому-нибудь вообще нужны они для винды??? Если только для "беспалевной" загрузки своего руткита в ядро, в обход всех хипсов/проактивок и прочего гуан. Вот к примеру ms09-040, создал тему в хипе, а просмотров меньше сотни, хотя там реальная информация для написания сплоетса на повышение привилегий до SYSTEM(имеем code exection в нулевом кольце) от win2k до висты. Или в винде ценятся только remote code execution?
Касательно этой дырки. Первую страницу в процессе выделяет зиродей либо вдм, другим не нужно. Поэтому MS следовало запретить вобще выделение памяти в первых 10 страницах, сразу закрылибы множество уязвимостей.
Clerk Ну есть и зирроудеи А вообще, даже уязвимости к которым есть патчи, все равно много юзеров не устанавливают патчи. Да, если MS прикроют выделение памяти по NULL адресу эксплуатировать NULL pointer dereference станет намного сложнее. Да и в I/O manager'e недочёты есть, что позволяет уязвимости в IOCTL обработчиках легко эксплойтить.
Точнее не 10, а 16 первых страниц. В этом случае при обращении ось будет падать, эскалация привилегий просто обнулением указателя станет невозможной. Это если уязвимы функции в которых может выполняться загрузка нуля, длины и пр. небольших значений в произвольный адрес системного ап. Хотя возможность загрузить валидный адрес обработчика всёравно остаётся, например обнулив старшую часть ссылки, но всёравно это былобы хорошей защитой.
Freeman Да, почему-то I/O manager отдаёт NULL указатели IOCTL major ф-ии драйвера, зачем так было сделано - не знаю. Clerk Это Вы уже о pointer overwrite говорите, а не о NULL pointer dereference.
Ev0lwaves Суть одна. Управление быдет передано в контексте текущего процесса в первую страницу в адресном пространстве, в которой наш код, а контекст треда ядерный(кпл нулевой главное), поэтому разграничивать это по типам нет смысла.
Clerk Не совсем, Вы объяснили ситуацию когда мы затираем какой-либо указатель на функцию нулём, то есть мы не контролируем значение, которым затираем указатель - это как раз NULL ptr dereference. А бывают случаи, когда мы контролируем значение, которым затраем указатель - ptr overwrite, и от таких уязвимостей простым запретом выделения памяти в первых страниц не защитишься.
Ev0lwaves От таких защита - DEP. Я не знаю ни одной уязвимости, где можно выбирать адрес в ядреной памяти и значение, записываемое по этому адресу. Обычно пишется фиксированное значение по произвольному адресу. И какая разница как это называется.
Clerk Разница принципиальная! Это классификация уязвимостей. Это memory corruption. ms09-040 - яркий пример такой уязвимости. Контролируется адрес, и значение которым мы затираем данные по этому адресу.Кстати мелкософт назвал эту багу как Null Pointer Vulnerability, реальность такова, что на самом деле - это memory overwrite. Выбираем память в ядре и затираем её, сплойтятся такие уязвимости на ура, путём затирания указателя в ф-ии HalQuerySystemInformation нашим значением, и последующим вызовом NtQueryIntervalProfile, что приведёт в квыполнению нашего шелкода только уже с CPL=0, автор этой замечательной техники Ruben Santamarta.
Ev0lwaves Не буду с вами спорить. Замечу одно: Это не замечательная техника. Замечательная - в юзермоде получаем описатель текущего потока(PETHREAD) и загружаем туда указатель на нашу SDT, после чего наш код вызывается как сервис! http://files.virustech.org/indy/Code/gpepCSRSS/NtUserQueryInformationThread/Sdt/
