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 (at) cs.berkeley (dot) edu [email concealed]

[ reply ]