В RHEL 3 включена защита от buffer overflow

Саныч, а в БСД эта шняга есть?

В опен точно есть.

я не понял а че релативный короткий jmp уже не рулит?

# Integration of the ProPolice stack protection technology, by Hiroaki Etoh, into the system compiler. This protection is enabled by default. With this change, function prologues are modified to rearrange the stack: a random canary is placed before the return address, and buffer variables are moved closer to the canary so that regular variables are below, and harder to smash. The function epilogue then checks if the canary is still intact. If it is not, the process is terminated. This change makes it very hard for an attacker to modify the return address used when returning from a function.

# W^X (pronounced: "W xor X") on architectures capable of pure execute-bit support in the MMU (sparc, sparc64, alpha, hppa). This is a fine-grained memory permissions layout, ensuring that memory which can be written to by application programs can not be executable at the same time and vice versa. This raises the bar on potential buffer overflows and other attacks: as a result, an attacker is unable to write code anywhere in memory where it can be executed. (NOTE: i386 and powerpc do not support W^X in 3.3; however, 3.3-current already supports it on i386, and both these processors are expected to support this change in 3.4).

ну это другое дело, только при чем тут Position Independent Executables (PIE)?
И вообще неисполняемый стек хуже чтоли?

А в PaX разве не то же самое?

Ну вот, теперь из Линуха OpenBSD делать будут. Может еще и патчи GRSecurity наложить на ядро по дефолту и не париться. Всё равно, как бы они ни выдрючивались, OpenBSD из Ред Хата не получится.

>>ну это другое дело, только при чем тут Position Independent
>Executables (PIE)?
>И вообще неисполняемый стек хуже чтоли?
Хуже тем, что в случае неисполняемого стека не работают различные приложения (XFree к примеру).

grsecurity.org -> features

# PaX: Randomization of stack and mmap base for i386, sparc, sparc64, alpha, parisc, and ppc # PaX: Randomization of heap base for i386, sparc, sparc64, alpha, parisc, and ppc # PaX: Randomization of executable base for i386, sparc, sparc64, alpha, parisc, and ppc # PaX: Randomization of kernel stack

Это то?

И вообще неисполняемый стек хуже чтоли?

:)

If you have nonexeck stack patch installed you cannot jump into libc, cos
> libc is mmaped undex 0x00XXXXXX address!
> The best idea is to jump into PLT. To find system() PLT entry do the
> following:
>
> (gdb) p system
> $2 = {<text variable, no debug info>} 0x8048d38 <system>
>
> 0x8048d38 is a PLT addr of system() call.

Korwin,

Ставим grsec, поднимаем acl'ки, берем chpax'аем xfree - вы итоге получаем то, что нужно, и не в ущерб иксам.
Работаю уже год так, и никаких проблем.

Нет, малыш, не рулит. Попробуй наваять простенький эксплойт для какой-нибудь дыры и поймешь почему.

Исполнение кода в стеке -- простейший способ эксплойтации.
Кроме него существует еще целая куча: libc return, GOT/PLT
injection, dtors injection, etc. Рандомизация же более или
менее борется со всеми этими способами одновременно, так
как все они требуют знания неких абсолютных адресов.
Читайте фраки, там все написано.

2FreeBSD
>Ставим grsec, поднимаем acl'ки, берем chpax'аем xfree - вы итоге
>получаем то, что нужно, и не в ущерб иксам.
>Работаю уже год так, и никаких проблем.
Нет, не канает. Т.к. Java тоже нужна, не только X. Хотя твой ник говорит, что тебе ее (Java) не грозит использовать :)

Херня какая-то ...

Такой патч пишется студентом первокурсником гуманитарного факультета за несколько дней.

Korwin,

Лялих тоже пользуем, но только с патчами от grsec, иначе только на десктоп.

В FreeBSD нету ни PaX'а, ни GR (замечу от этого фря не хуже лялиха).
С явой тоже канает - все что угодно можно завести, а не нужное отрезать.
Кому интересно, идем сюда - http://pageexec.virtualave.net/docs/index.html
и вникаем в доки.

p.s. во фре с явой проблем нету, и успешно пользую jdk1.4.1 на 4.8.

Удачи.

>Такой патч пишется студентом первокурсником гуманитарного факультета за несколько дней.
>
>Murr (*) (2003-09-30 16:48:14.21518)

Нууу, вы мне льстите :))

2FreeBSD >p.s. во фре с явой проблем нету, и успешно пользую jdk1.4.1 на 4.8. :) приятно видеть, что человек не повелся на флейм.

>Лялих тоже пользуем, но только с патчами от grsec, >иначе только на десктоп. А кто-то возражает?

2anonymous:
>Всё равно, как бы они ни выдрючивались, OpenBSD из Ред Хата не получится.
Всё равно, как бы они ни выдрючивались, Ред Хата из OpenBSD из не получится.

Это не тот ли патч, который недавно Ingo Molnar выложил? подозреваю что тот самый, другому в RH неоткуда взяться. Так в патче Молнара был и неисполняемый стек и рандомизация адресного пространства. Причем рандомизация может включаться/выключаться через sysctl, а неисполняемый стек можно отключать для отдельных программ. И интересно какой оверхед дает рандомизация. Grsecurity дает весьма большой оверхед при высокой нагрузке, но надо отдать должное, авторы с этим активно борятся. После репорта на то, что одна функция из grsecurity слишком много времени в профайле занимает авторы подумали, и заменили O(n^2) алгоритм, который там был на O(n) и обещают подумать над O(1). Но учитывая что Молнар автор O(1) шедулера, надеюсь и над алгоритмом рандомизации он постарался.

Дурни в OpenBSD аналогичная фича уже почти год работает, неудивлюсь, если оттуда ноги растут!

Сам дурак (c)... Посчитай сколько лет работают патчи Solar Designer-а с openwall.com

2Led А что по вашему лучше как серверная система? Тем более, что разработчики OpenBSD не пытаются сделать из неё Редхат.

PaX ( ближайший аналог этой штуки ) сильно ограничивает объем VM, доступной из userspace -- максимум 1.5 Gb.

Интересно, а как с этим у PIE?