Re: Patch 4/6 randomize the stack pointer

[Ingo Molnar <mingo@elte.hu>]

* Paulo Marques <pmarques@grupopie.com> wrote:

> I really shouldn't feed the trolls, but this must be the most silly
> piece of code I saw on this mailing list in a very long time (and
> there have been some good examples over time).

yeah.

> The stack randomization doesn't prevent some sort of attacks (like
> return into libc, etc.) and given a small randomization it might be
> possible to write an exploit with a long sequence of NOP's and a
> return address somewhere in there (the attacker wouldn't know exactly
> where, but it wouldn't matter anyway). If we are able to write 'N'
> NOP's then we get a 'N'/64k chance that the exploit works.

yeah. NOP techniques can always be used to 'chop off bits' from any
randomization, in case the address of the payload is not known. Both
instruction NOPs for shellcode and 'parameter NOPs' ("././././" strings
or "/bin/sh\0/bin/sh\0" strings) can be used.

but there is no fundamental theoretical difference between a 256 MB
randomization (as PaX uses) and a 2 MB randomization (Fedora) in terms
of characteristics: what is brute-force in one is brute-force in the
other as well, with a factor of overhead difference of 128. (which makes
the attack 128 times longer, but has no real difference to security.)

so the attempt of our beloved troll to paint 2 MB of randomization as
'weak' and 256 MB randomization as 'strong' is i believe misguided: both
are 'weak' in most of the threat models! (and even for threat types
where they might be considered 'strong' (e.g. whether a hole is suitable
to feed a destructive worm), they'll both be considered 'strong'.)

(obligatory note: the randomization we can get on 64-bit VMs is
different and probably completely adequate against all currently
existing remote threats, and maybe even against most of the practical
local threats.)

	Ingo