Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Войти
 
Страницы: 1 2 След.
RSS
Анализ встроенных механизмов защиты от переполнения кучи в Windows ...
 
Обсуждение статьи Анализ встроенных механизмов защиты от переполнения кучи в Windows XP SP2.
 
А Microsoft-таки отреагировала?
 
Я так и не понял, это работает на новых процессорах с hardware NX flag, или только на старых ?
 
Цитата
Я так и не понял, это работает на новых процессорах с
hardware NX flag, или только на старых ?
На AMD64 с включенным DEP - второй PoC работает. только
что проверил
 
Windows XP SP2 требуется хирургическое вмешательство и при чем не слабое и чего это народ вздумал ее лечить ее просто надо похоронить.Ставить надо систему более надежную SP1 еще так сяк.Видно когда мелкомягкие ваяли SP2 они были сильно простужены на голову. [IMG]http://www.securitylab.ru/forum/smileys/smiley19.gif[/IMG]
Будем ждать..............

Всего хорошего
 
rsp
А ты в курсе, что уязвимости найденные в защите SP2, отсутсвуют в "надежной" SP1 только потому, что SP1, как и в SP0 вообще нет защиты DEP? В SP1 вообще не нужно пытаться обходить эту защиту, ибо ее там еще не было, а в SP2 есть, но дырявая )))
Да и вообще, посчитай количество баг в SP1 и в SP2. Сколько видел последние адвайзори "SP2: not affected".
 
r00t[/B]
Для тех кто денно и ночно сидит в инете
может и актуально, но не для работяг,
которые крапают проги.Приходится обходить
все эти запреты. Тем более когда о них сообщают
с задержкой. Типа, мы установили такой-то регистр
проца в 1 извините это для вашей безопасности.Когда
начинаешь отлаживать прогу,а она не идет, вот тогда
это уже не смешно.
 
r00t
Будет время попробуй запусти Syser Kernel Debugger в SP2
прогу можно взять на WASM-е, если все удачно сложится
отпиши.
 
Цитата
rsp пишет:
Для тех кто денно и ночно сидит в инете
может и актуально, но не для работяг,
которые крапают проги
Ну не только для тех кто денно и ночно сидит в инете, это актуально для всех, кто ходит в инет, а таких много, для всех кто подключен в сети - домашние, офисные, в игровых клубах, да и вообще безопасность лишней не бывает, вобщем для основной массы стандартных вин. люзеров. Я люзерам ставлю SP2 и пока еще о проблемах ни с игрушками, вордами, ёкселями, операми, батами, vmware-мя, commview-ами, ollydbg-ми, справочниками и много чем еще от них не слышал, да и сам не сталкивался.

Цитата
rsp пишет:
Будет время попробуй запусти Syser Kernel Debugger в SP2
Угу, давай будем судить о стабильности новой винды или SP по кривым хакирским приблудам, писанным на коленке, да еще системного уровня, у которых при смене обстановки вылазят глюки. Это проблема софтины а не винды!! Ну меня в SP2 лично не устраивает то, что в частности, raw sockets кастрировали без спросу, мне вообще не нравится что кто-то решает чему быть, а что выкинуть лишнее на его взгляд, поэтому я и использую Linux, но из-за этого не опускаю SP2 - чертой винды всегда было то, что за юзера все решают.
Кстати, чем дебаггер уровня ядра SoftICE или как он теперь называется - DriverStudio, не угодил? Его то люди посерьезнее писали, чем Syser какой-то, под SP2 имхо работать должен...
Насчет Syser ok, буду в венде, погляжу на приблуду.
 
r00t
C SIce тоже не все в порядке скажем прямо у них
видимо рассогласование.Тестил последний релиз,который
DriverStudio так вот загрузчик у них который SymbolLoader
почти никакой, так пока надежней v4.05 под NT.Драйвера
писал когда-нибудь, это я к тому,что отлаживать их надо
на уровне близком к ядру или почти там, так что без "хакерского софта" и разных там дебагеров не обойтись.

Всего
 
Цитата
Необходимое условие для удачной эксплуатации - это наличие свободного блока из ассоциативного списка, который находится по соседству с переполняемым буфером.
Сразу же возникает вопрос - сколь велика вероятность наличия такого блока. В статье приводится ответ на этот вопрос:
Цитата
Вероятность попадания свободного блока (до 1016 байт) в lookaside список довольно большая - 97% (в приложениях, которые сильно нагружают кучу).
К сожалению не приведено никакой аргументации указанного значения. Можно попросить авторов привести обоснование или указать источник этой информации?
 
вероятно они 100 раз протестировали систему и
в трех она переполнение проглатывала за "милую душу".
8)))
 
А все-таки что в Microsoft ответили?
 
Спасибо!
lookaside актуально.
 
nmalykh:
Цитата

К сожалению не приведено никакой аргументации указанного значения. Можно попросить авторов привести обоснование или указать источник этой информации?

Для каждого ассоциативного (lookaside) списка создается внутренняя структура данных, в которой помимо указателя на начало списка еще находятся следующие счетчики:

TotalAllocates - общее количество попыток выделения;
AllocateMisses - количество неудачных попыток;
TotalFrees - общее количество попыток записи блока памяти в lookaside лист;
FreeMisses - количество неудачных попыток записи блока в lookaside лист;

Depth, MaximumDepth, LastTotalAllocates и LastAllocateMisses.


Зная значения счетчиков TotalFrees и FreeMisses не трудно вычислить % значение попадания блока в ассоциативный список.

Например, у многих приложений всегда %100 попадание блока в lookaside лист.

P.S. Могу подробнее привести пример, как определить значения этих счетчиков в реальных приложениях.

Цитата
S пишет:
вероятно они 100 раз протестировали систему и
в трех она переполнение проглатывала за "милую душу".
8)))

Примеры (PoC) приведенные в статье будут работать всегда.
(Используйте компилятор MSVC 6.0)
 
Цитата
Александр А. пишет:

TotalAllocates - общее количество попыток выделения;
AllocateMisses - количество неудачных попыток;
TotalFrees - общее количество попыток записи блока памяти в lookaside лист;
FreeMisses - количество неудачных попыток записи блока в lookaside лист;

Depth, MaximumDepth, LastTotalAllocates и LastAllocateMisses.

Зная значения счетчиков TotalFrees и FreeMisses не трудно вычислить % значение попадания блока в ассоциативный список.
Зная значения TotalFrees и FreeMisses можно определить вероятность успеха при попытке включения блока в ассоциативный список. Может быть я неправ, но мне представляется, что это значение слабо коррелирует с вероятностью присутствия в ассоциативном списке блока, соседствующего с перезаписываемым (наличие которого требуется для использования уязвимости).
 
Цитата

Зная значения TotalFrees и FreeMisses можно определить вероятность успеха при попытке включения блока в ассоциативный список. Может быть я неправ, но мне представляется, что это значение слабо коррелирует с вероятностью присутствия в ассоциативном списке блока, соседствующего с перезаписываемым (наличие которого требуется для использования уязвимости).

Вы правы, на вероятность присутствия в ассоциативном списке блока, соседствующего с перезаписываемым, помимо этого влияет также размер переполняемого буфера и размер блоков с которым работает приложение.
Например, если приложение, как правило, выделяет память небольших размеров, то вероятность очень большая.

На практике, прежде чем переполнять буфер, можно специальным образом "подготовить" кучу. Например, посылать FTP серверу некоторое количество запросов (команд) размер которых меньше 1016 байт и тогда при следующем выделении - блок памяти (переполняемый буфер) будет точно находится рядом с блоком из ассоциативного списка.
 
Цитата
Александр Анисимов пишет:

Вы правы, на вероятность присутствия в ассоциативном списке блока, соседствующего с перезаписываемым, помимо этого влияет также размер переполняемого буфера и размер блоков с которым работает приложение.
Например, если приложение, как правило, выделяет память небольших размеров, то вероятность очень большая.
Александр, я правильно понял, что посчитать вероятность достаточно сложно, но качественно ее можно оценить как достаточно высокую и, более того, на нее можно влиять из пользовательских (хакерских) приложений?
 
Цитата
nmalykh пишет:
 
Цитата
Александр Анисимов пишет:

Вы правы, на вероятность присутствия в ассоциативном списке блока, соседствующего с перезаписываемым, помимо этого влияет также размер переполняемого буфера и размер блоков с которым работает приложение.
Например, если приложение, как правило, выделяет память небольших размеров, то вероятность очень большая.
Александр, я правильно понял, что посчитать вероятность достаточно сложно, но качественно ее можно оценить как достаточно высокую и, более того, на нее можно влиять из пользовательских (хакерских) приложений?

Да, Вы правильно поняли.
 
так все-таки что ответили в Microsoft? Вы пишете, что ответ получили, но какой? Может кто-нибудь мне ответить?
Страницы: 1 2 След.
Читают тему