_ RU.LINUX (2:5077/15.22) ___________________________________________ RU.LINUX _
From : Solar Designer 2:5020/400 07 Nov 98 06:40:06
Subj : Multi-stack allocator.
________________________________________________________________________________
From: Solar Designer <solar@cannabis.dataforce.net>
Serge Orlov <sorlov@con.mcst.ru> wrote:
> У меня с ним работает пол-REdHat'а 5.1. До второй половины руки не
Дома? Интересно все-таки насколько больше требует памяти -- в BugTraq я
так понял были числа "на машину", но без указания кол-ва процессов.
Я правильно понимаю, что он требует лишние в среднем примерно пол страницы
(2 Kb) на локальный массив?
Еще вопрос: что у тебя происходит в такой ситуации:
ptr = buf;
ptr += snprintf(...);
ptr += snprintf(...);
при версии snprintf(), возвращающей -1 при переполнении (такая была до
какого-то момента в glibc, и еще иногда встречается не на Linux'ах)?
Это вовсе _не_ частый случай, просто мне действительно интересно понять
на таком примере.
(Конечно, я должен уже взять и проверить сам, чем и займусь как разберусь
с другими начатыми вещами, но, думаю, здесь народ все равно спросит.;-)
> С SuperProbe тоже прокол вышел, там нет массива в структуре:
Я знаю откуда этот прокол вышел: там в exploit'е мне пришлось затереть
указатель на структуру. ;-)
> Более того, это пример где ни неисполняемый стек, ни StackGuard не
> помогут, а Multi-stack защитит.
По-существу -- да -- остальные обходятся.
Что касается существующего exploit'а -- он не работает при моем патче
с выключенной поддержкой trampolines, но работает под StackGuard. ;-)
Так случайно (exploit был до всех трех) получилось. Был пример наехать
на StackGuard. ;-)
>> А так - все это вещи из одной оперы, как и соларолвский патч. Полезно,
>> но не панацея.
>
> Это верно.
Agreed.
Может, пора уже в наши FAQ какое-то сравнение вставить? Hапример:
Multi-stack StackGuard Secure Linux
Re-build at installation:
kernel no no yes
everything to be secured yes yes no
Overhead:
CPU almost none yes no
memory yes a bit no
Events covered:
overflow on stack, typical yes on return no
overflow on stack, generic usually no no
non-stack overflows no no no
non-overflow return spoofing no sometimes no
branch to stack (except call) no no yes
call to stack no no optional
return into shared libraries no no ASCIIZ only
other nasty branches no no no
Attacks covered:
typical Phrack 49 exploits yes yes yes
return-into-.bss/.text some some no
return-into-libc some some yes
shellcode-on-stack some some yes
Vova
