Re: Patch 4/6 randomize the stack pointer

From: John Richard Moser
Date: Thu Jan 27 2005 - 12:47:36 EST


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Arjan van de Ven wrote:
>
> The patch below replaces the existing 8Kb randomisation of the userspace
> stack pointer (which is currently only done for Hyperthreaded P-IVs) with a
> more general randomisation over a 64Kb range.
>

64k of stack randomization is trivial to evade. Know the alignment, and
stick branch instructions (or a stream of no-ops if they align)
periodically so that....

[ ]|STACK---STACK---NONONOSHELLCODE
STACK---STACK---NONONOSHELLCODE
- ----------------------^
|
- -- You jump here in any case.

Now, in PaX, there's a randomization over something like a 256M range
for the stack IIRC. Who does a 256M stack overflow? It's several gigs
on 64 bit archs I think. I think it's 16 bits with 4k (12 bit) pages,
so.... 28 bits... 268435456.... 256M, yes. I'm pretty sure this is 24 +
12 on amd64 for example, so 64 gigs.

If your stack base is within 256M of ESP, you're safe. It's also fairly
implausible--definitely non-trivial--to do a 256M stack buffer overflow.
Programmatically it's no different; but in real life, that's 256M that
has to be in a corrupted jpeg, mp3 file, or network transmission.
Somebody's gonna notice. 64 gig doesn't happen.

Your patch 5/6 for mmap rand is also small. 1M is trivial, though I'd
imagine mmap() rand would pose a bit more confusion in some cases at
least, even for small ranges.

Still, this is a joke, like OpenBSD's stackgap.

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB+ScghDd4aOud5P8RAk3zAJ9u3eav0l/Uhd3tQJ7uhDch+bepmACfeuYT
bQH8NCKkDXpmOPsXjVZ9cw4=
=e6OC
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/