| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
Not the best solution
Not the best solution
Posted Mar 10, 2005 3:47 UTC (Thu) by Ross (subscriber, #4065)In reply to: Not the best solution by bronson
Parent article: Address space randomization in 2.6
(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.
(Log in to post comments)
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.