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 nweaverat_private
This archive was generated by hypermail 2b30 : Wed Feb 05 2003 - 13:05:22 PST