информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
За кого нас держат?Портрет посетителяСтрашный баг в Windows
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Блокировка российских аккаунтов... 
 Отзыв сертификатов ЦБ РФ, ПСБ,... 
 Памятка мирным людям во время информационной... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
что я читал об этом 08.10.02 11:35  Число просмотров: 1018
Автор: dl <Dmitry Leonov>
Отредактировано 08.10.02 11:37  Количество правок: 1
<"чистая" ссылка>
> Ну не в сегменте данных, а, как правило, в стеке.
> Только некоторые виды unix поддерживают запрет на
> исполнение кода в стеке.
> Не всегда нужно выполнять код, перполнивший буфер, иногда
> хватит изменить адрес возврата.
> (читал в книге К.Касперски)

Я бы сказал, что как правило меняют адрес возврата - в сочетании с передачей кода, на который этот адрес начинает указывать. Идеальный вариант, если и код удается разместить в этой же строке.
<programming>
переполнения буферов - меня терзают смутные сомения. 08.10.02 10:54  
Автор: PS <PS> Статус: Elderman
<"чистая" ссылка>
Давно мучает вопрос: как народ организует исполнение кода при переполнении буфера.

По идеи данные должны лежать в сегменте данных, а код в сегменте кода. Каждый сегмент можно организовать на своей странице. У страниц имеются свойства: на запись, на чтение, на исполнение.
Пусть даже мы вылезем за границу нашего буфера, но во первых это будет в сегменте данных, а не кода, а во вторых исполнить данные мы все равно не сможем.
[Win32] переполнения буферов - меня терзают смутные сомения. 09.10.02 14:19  
Автор: beetle <beetle> Статус: Member
<"чистая" ссылка>
вот тут я кое-что накрапал

Переполнения стека для начинающих - часть №1
Переполнения стека для начинающих - часть №2
переполнения буферов - меня терзают смутные сомения. 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 поддерживают запрет на
> исполнение кода в стеке.
> Не всегда нужно выполнять код, перполнивший буфер, иногда
> хватит изменить адрес возврата.
> (читал в книге К.Касперски)

Я бы сказал, что как правило меняют адрес возврата - в сочетании с передачей кода, на который этот адрес начинает указывать. Идеальный вариант, если и код удается разместить в этой же строке.
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2022 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach