Легенда:
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | | | | |
Тада, это на совести тех, кто меня учил: 11.10.02 10:48 Число просмотров: 1116
Автор: ZloyShaman <ZloyShaman> Статус: Elderman
|
> Кстати, кто знает, сколько способен продержаться > Мастдайский файл-сервер, если его не ломать и не лезть в > него руками? Этого, видимо, никто не знает, т.к. очень часто приходится устанавливать различные обновления :))
|
<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 поддерживают запрет на > исполнение кода в стеке. > Не всегда нужно выполнять код, перполнивший буфер, иногда > хватит изменить адрес возврата. > (читал в книге К.Касперски)
Я бы сказал, что как правило меняют адрес возврата - в сочетании с передачей кода, на который этот адрес начинает указывать. Идеальный вариант, если и код удается разместить в этой же строке.
|
|
|