Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | |
Afaik x86 не поддерживает exec/nonexec страниц 09.10.02 18:31 Число просмотров: 1193
Автор: XR <eXtremal Research> Статус: The Elderman
|
> И, если я не ошибаюсь, эти *nix работают не на Intel x86.
Не ошибаешся - SPARC это умеет напрямую x86 НЕ УМЕЕТ
ставить на страницу памяти атрибут nonexec - это обходится весьма
нетривиальными способами
Как:
cм PaX (не OWL !) patch для Linux (есть аналогичная коммерческая реалиизация для NT)
|
|
<programming>
|
переполнения буферов - меня терзают смутные сомения. 08.10.02 10:54
Автор: PS <PS> Статус: Elderman
|
Давно мучает вопрос: как народ организует исполнение кода при переполнении буфера.
По идеи данные должны лежать в сегменте данных, а код в сегменте кода. Каждый сегмент можно организовать на своей странице. У страниц имеются свойства: на запись, на чтение, на исполнение.
Пусть даже мы вылезем за границу нашего буфера, но во первых это будет в сегменте данных, а не кода, а во вторых исполнить данные мы все равно не сможем.
|
|
переполнения буферов - меня терзают смутные сомения. 08.10.02 11:32
Автор: dl <Dmitry Leonov>
Отредактировано 08.10.02 11:37 Количество правок: 1
|
Обычно все-таки подразумевается, что буфер лежит в стеке. В случае, если он в сегменте данных, появляются другие интересные, но не особо стандартные варианты.
Технология переполнения буфера
|
| |
сомнений тут быть не может 08.10.02 13:46
Автор: vp016 Статус: Незарегистрированный пользователь
|
> Обычно все-таки подразумевается, что буфер лежит в стеке. В
> случае, если он в сегменте данных, появляются другие
> интересные, но не особо стандартные варианты.
Собственно так.
1) Со стеком случай тривиальный.
2) На запись закрыт только сегмент данных в котором константы, все остальные открыты
на запись.
3)Код может быть выполнен не только со стека но и с сегмента данных (перезапись секции
.dtors, gcc).
4) Закрытие сегметов содержащих стек или данные на выполнение напоминает политику страуса при приближении опасности - засунуть голову в песок и выставить задницу.
5) Полно способов произвести какие-либо действия не выполняя код. NOexec exploites
можно сделать под что угодно, причем гораздо проще чем exec....
|
| | |
С этого места пожалуста подробней 08.10.02 14:49
Автор: PS <PS> Статус: Elderman
|
> 4) Закрытие сегметов содержащих стек или данные на
> выполнение напоминает политику страуса при приближении
> опасности - засунуть голову в песок и выставить задницу.
Это еще почему ? По моему самым лучший метод. То куда можно писать - не исполняется. Исполняется лишь то куда писать нельзя.
> 5) Полно способов произвести какие-либо действия не
> выполняя код. NOexec exploites
> можно сделать под что угодно, причем гораздо проще чем
> exec....
Например ?
То на что хватает моей фантазии - это сделать code dump, но это не интересно ( я его и так по нескольку раз на дню получаю ;) )
Как можно произвести действия не выполняя код ?
|
| | | |
Что такое шитий код и noexec exploit... 09.10.02 14:50
Автор: vp016 Статус: Незарегистрированный пользователь
|
При желании можно взять книгу по Forth. Там подробно расписано, что есть шитый код.
Более просто - все данные хранятся в стеке, код представляет собой последовательность вызовов процедур.
> > 4) Закрытие сегметов содержащих стек или данные на
> > выполнение напоминает политику страуса при приближении
> > опасности - засунуть голову в песок и выставить
> задницу.
>
> Это еще почему ? По моему самым лучший метод. То куда можно
> писать - не исполняется. Исполняется лишь то куда писать
> нельзя.
Вместо адреса возврата можно поставить возврат на какую-то другую процедуру. т.е.
тоже самое только вид сбоку... Например в случае ошибок формата именно так и получается... С переполнением буферов, в простейшем случае (unix) адрес возврата system,
параметр - адрес - "/bin/sh"
>
> > 5) Полно способов произвести какие-либо действия не
> > выполняя код. NOexec exploites
> > можно сделать под что угодно, причем гораздо проще чем
> > exec....
>
> Например ?
> То на что хватает моей фантазии - это сделать code dump, но
> это не интересно ( я его и так по нескольку раз на дню
> получаю ;) )
> Как можно произвести действия не выполняя код ?
Вот так и можно.
|
| | | |
С этого места пожалуста подробней 08.10.02 14:54
Автор: dl <Dmitry Leonov>
|
> > 5) Полно способов произвести какие-либо действия не
> > выполняя код. NOexec exploites
> > можно сделать под что угодно, причем гораздо проще чем
> > exec....
>
> Например ?
> То на что хватает моей фантазии - это сделать code dump, но
> это не интересно ( я его и так по нескольку раз на дню
> получаю ;) )
> Как можно произвести действия не выполняя код ?
Например, поменяв значения критичных глобальных переменных, лежащих по соседству. Но тут уже индивидуальный подход нужен, в отличии от срыва стека, где все практически стандартно.
|
|
что я читал об этом 08.10.02 11:24
Автор: Chingachguk <Chingachguk> Статус: Member
Отредактировано 08.10.02 11:25 Количество правок: 1
|
> Давно мучает вопрос: как народ организует исполнение кода
> при переполнении буфера.
>
> По идеи данные должны лежать в сегменте данных, а код в
> сегменте кода. Каждый сегмент можно организовать на своей
> странице. У страниц имеются свойства: на запись, на чтение,
> на исполнение.
> Пусть даже мы вылезем за границу нашего буфера, но во
> первых это будет в сегменте данных, а не кода, а во вторых
> исполнить данные мы все равно не сможем.
Ну не в сегменте данных, а, как правило, в стеке.
Только некоторые виды unix поддерживают запрет на исполнение кода в стеке.
Не всегда нужно выполнять код, перполнивший буфер, иногда хватит изменить адрес возврата.
(читал в книге К.Касперски)
|
| |
что я читал об этом 08.10.02 17:07
Автор: :-) <:-)> Статус: Elderman
|
> > Давно мучает вопрос: как народ организует исполнение
> кода
> > при переполнении буфера.
> >
> > По идеи данные должны лежать в сегменте данных, а код
> в
> > сегменте кода. Каждый сегмент можно организовать на
> своей
> > странице. У страниц имеются свойства: на запись, на
> чтение,
> > на исполнение.
> > Пусть даже мы вылезем за границу нашего буфера, но во
> > первых это будет в сегменте данных, а не кода, а во
> вторых
> > исполнить данные мы все равно не сможем.
>
> Ну не в сегменте данных, а, как правило, в стеке.
> Только некоторые виды unix поддерживают запрет на
> исполнение кода в стеке.
И, если я не ошибаюсь, эти *nix работают не на Intel x86.
В x86 право читать сегмент дает также право исполнять код в нем. Раньше тут z0 постил исходник (функция в области данных).
|
| | |
Afaik x86 не поддерживает exec/nonexec страниц 09.10.02 18:31
Автор: XR <eXtremal Research> Статус: The Elderman
|
> И, если я не ошибаюсь, эти *nix работают не на Intel x86.
Не ошибаешся - SPARC это умеет напрямую x86 НЕ УМЕЕТ
ставить на страницу памяти атрибут nonexec - это обходится весьма
нетривиальными способами
Как:
cм PaX (не OWL !) patch для Linux (есть аналогичная коммерческая реалиизация для NT)
|
| | | |
Это Flat-модель памяти - не поддерживает, а 10.10.02 03:02
Автор: Zef <Alloo Zef> Статус: Elderman
|
|
segmented - очень даже поддерживает. И 4 уровня привилегий, включая запрет на чтение исполняемого кода в R0. Просто, возиться с сегментами никто не хочет - геморрой это, вроде, как и быстродействие снижается (2 дополнительных преобразования линейного адреса добавляются), зато Array out of range в нем не возможен, даже теоретически... Вот, Nowell построил свою систему на сегментной модели, и сервера по пол-года без перезагрузки работают...
|
| | | | |
Это Flat-модель памяти - не поддерживает, а 10.10.02 22:09
Автор: :-) <:-)> Статус: Elderman
|
> segmented - очень даже поддерживает. И 4 уровня привилегий,
> включая запрет на чтение исполняемого кода в R0.
Да, точно.
The CS register can be loaded only with a selector of an executable segment.
Selectors of executable segments that are not readable cannot be loaded into data-segment registers.
> возиться с сегментами никто не хочет - геморрой это, вроде,
:(( Жаль, хотя imho не такой уж и геморрой - предусмотреть отдельные сегменты для кода, данных и стека...
> Вот, Nowell построил свою систему на сегментной модели, и
> сервера по пол-года без перезагрузки работают...
И Netware тоже юзает flat-модель. Более того, до версии 5.x ее ядро вообще не было защищено!!. Любой .nlm загружался в единое OS ADDRESS SPACE (прямо как в ДОС), и мог похерить всю систему.
В версии 5.x командой load protected можно загрузить .nlm в отдельное USER ADDRESS SPACE. Но это опционально, и если это и делают, то для левых, не-Novell-овских .nlm
|
| | | | | |
Тада, это на совести тех, кто меня учил: 11.10.02 05:46
Автор: Zef <Alloo Zef> Статус: Elderman
|
так нам говорили (о 4.10), который я админил до 99 года. Разобраться самому мне тогда еще ума не хваталою. А сейчас, мне и без Новела дел хватает... В прочем, он все равно, весьма надежен. (Наверное, потому, что никто не знает, как самому NLM-ки писать). Новелл и правда у меня пол-года работал (пока вентилляторы пыль не забила). Линуксовый сервак, вот валится сейчас стабильно раз в сутки (правда, похоже у него винт сыпется).
Кстати, кто знает, сколько способен продержаться Мастдайский файл-сервер, если его не ломать и не лезть в него руками? Лично я еще ни одного Мастдая не видел, чтобы на нем никакой посторонней дряни не запускали.
|
| | | | | | |
Тада, это на совести тех, кто меня учил: 11.10.02 13:58
Автор: :-) <:-)> Статус: Elderman
|
> так нам говорили (о 4.10), который я админил до 99 года.
> Разобраться самому мне тогда еще ума не хваталою. А сейчас,
> мне и без Новела дел хватает... В прочем, он все равно,
> весьма надежен. (Наверное, потому, что никто не знает, как
> самому NLM-ки писать).
Я писАл... Собственно и на Си перешел из-за того, что для Netware не было Паскаль-компилятора, а с Ассемблером трахаться не очень хотелось. До этого под ДОС мне хватало Паскаль+Асм. А потом, после NLM, привык к Си :)
|
| | | | | | |
Тада, это на совести тех, кто меня учил: 11.10.02 10:48
Автор: ZloyShaman <ZloyShaman> Статус: Elderman
|
> Кстати, кто знает, сколько способен продержаться
> Мастдайский файл-сервер, если его не ломать и не лезть в
> него руками?
Этого, видимо, никто не знает, т.к. очень часто приходится устанавливать различные обновления :))
|
| |
что я читал об этом 08.10.02 11:35
Автор: dl <Dmitry Leonov>
Отредактировано 08.10.02 11:37 Количество правок: 1
|
> Ну не в сегменте данных, а, как правило, в стеке.
> Только некоторые виды unix поддерживают запрет на
> исполнение кода в стеке.
> Не всегда нужно выполнять код, перполнивший буфер, иногда
> хватит изменить адрес возврата.
> (читал в книге К.Касперски)
Я бы сказал, что как правило меняют адрес возврата - в сочетании с передачей кода, на который этот адрес начинает указывать. Идеальный вариант, если и код удается разместить в этой же строке.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
