Bugtraq mailing list archives
Observation on randomization/rebiasing...
From: Nicholas Weaver <nweaver () CS berkeley edu>
Date: Wed, 5 Feb 2003 13:10:26 -0800
I've viewed this general thread with interest. A few comments: In general, I'm rather skeptical of randomization providing much prevention after code is injected. There already IS some randomization in Sapphire's host, and the Sapphire code goes through the routine to disambiguate things in order to get the function pointers it needs. Making it harder to get the API pointers, and the author will directly call the syscalls (or windows equivelent) needed to find the infomation it needs. So also the syscal inferface would need to be randomized. To prevent code injetion itself, noexec stack&heap works better and is simpler. True, x86 is horribly broken when it comes to this, but you can at least do a halfway decent noexec-stack. If one needs noexec-stack/heap now, you can either get a Sparc or wait for Hammer. Randomization, combined with code injection prevention, provides more protection than either alone. Good randomization can prevent forced-jumps to known code sections which serve an attacker's purpose, which noexec stack/heap can't. They really address different things, the Write ^ Exec prevents injection, while randomization prevents forced jumps. Randomization is best done with runtime (dynamic) linking. If it is compile-time, I can plausibly see attackers able to do Over/Under tests or other smarter searching to get the magic addresses needed, with the server crashing and restarting each time. Thus the O(2^n) difficulty/probability of disambiguating becomes O(lg(2^n))->O(n) if static randomization and the particular bug allows an attacker to tell if his guess of a magic number is high or low. Finally, it's been pointed out to me that implementing randomized dyamic linking, or even randomized static linking, will play havoc with debuggers and possibly introduce even more Heisenbugs. -- Nicholas C. Weaver nweaver () cs berkeley edu
Current thread:
- Re: Preventing exploitation with rebasing, (continued)
- Re: Preventing exploitation with rebasing David Litchfield (Feb 04)
- Re[2]: Preventing exploitation with rebasing dullien (Feb 04)
- RE: Preventing exploitation with rebasing Jason Coombs (Feb 04)
- Re: Preventing exploitation with rebasing Charlie Root (Feb 05)
- Re: Preventing exploitation with rebasing David Litchfield (Feb 05)
- Re: [VulnDiscuss] Re: Preventing exploitation with rebasing Halvar Flake (Feb 05)
- Re: Preventing exploitation with rebasing Brian Hatch (Feb 05)
- Re: Preventing exploitation with rebasing Alan DeKok (Feb 05)
- Re: Can't Preventing exploitation with rebasing bugtraq (Feb 05)
- Re[2]: Can't Preventing exploitation with rebasing dullien (Feb 05)
- Observation on randomization/rebiasing... Nicholas Weaver (Feb 05)
- RE: Observation on randomization/rebiasing... Jason Coombs (Feb 05)
- Re: Preventing exploitation with rebasing Crispin Cowan (Feb 05)
- Re: Preventing exploitation with rebasing David S Goldberg (Feb 05)
- Re: Preventing exploitation with rebasing Alun Jones (Feb 05)
- Re: Preventing exploitation with rebasing Deus, Attonbitus (Feb 06)
- Re: Preventing exploitation with rebasing Bugtraq User (Feb 05)
- Re: Preventing exploitation with rebasing D.C. van Moolenbroek (Feb 05)