Not the best solution [LWN.net]

Not the best solution

Posted Feb 3, 2005 5:42 UTC (Thu) by Ross (subscriber, #4065)
Parent article: Address space randomization in 2.6

Stack protection and/or canaries are better solutions. They offer stronger
protection (canaries can be a full 32 bits, and stack protection can prevent
overflows no matter how many guesses an attacker gets). Randomization of
addresses are unfortunate because they make programs non-deterministic.
One of the nice things about a virtualized environment with address
separation is that running the same program will produce the same results
sans device I/O or wall-clock timings. That said it can be useful as an
additional layer... it just should not be something which we depend on for
security.

(Log in to post comments)

Not the best solution

Posted Feb 3, 2005 19:24 UTC (Thu) by bronson (subscriber, #4806) [Link]

Stack randomization makes BUGGY programs non-deterministic. But then, so does running the program on a different platform. I don't understand your complaint. If you're that worried, just turn randomization off on your development machine.

Aren't canaries a relatively large performance hit? I've written some inner loops that would definitely notice the time needed to generate the canary and check it every time you call a subroutine.

Not the best solution

Posted Mar 10, 2005 3:47 UTC (Thu) by Ross (subscriber, #4065) [Link]

(I know I'm following up very late so you are probably not going to see
this. But a newer article linked to this and I ran across your post.)

Not only buggy programs but any program that uses "%p" for example. And
the case I was thinking about was specifically dealing with buggy code:
it is nice to be able to reproduce crashes by providing the same inputs to
the program and re-running it if for no other reason that to verify the bug
before submitting a report.

Not the best solution

Posted Jun 25, 2006 0:53 UTC (Sun) by bluefoxicy (guest, #25366) [Link]

Dude, if you jump around bad in randomized code with addresses shifting about every time you start the program over again, you're going to have weird results-- mainly, the program hits bad instructions or unmapped areas and crashes. The more randomization, the more crashes you get.

When not randomizing, sometimes you'll run across something that screws with memory badly for a while; turns your window orange; halts it; produces strange noises; and crashes in some other object file entirely. For example a heap buffer overflow, that can get the heap manager (C library, libc) to try to alter "allocator information" in random memory addresses (hence, double-frees, heap overflows, etc as security attacks). This might not crash the program in certain cases; but if you randomize the address space, then those certain cases will certainly crash the program in one run or another.