|
Authored by: Anonymous on Friday, January 25 2013 @ 11:11 PM EST |
It's easy to fix. The problem is in the implementation of
malloc or the equivalent. If malloc uses an sbrk/rbrk
style, then this attack will work. If malloc uses mmap,
then the chunks of memory allocated and freed should be
randomized and this attack will not work. Most programs on
windows are dynamically linked, so this should be an easy
update for Microsoft.
Of course, most programs that run on windows are written
about as well as windows itself. So I'd be willing to bet
that many, many programs will break if the behavior of
malloc changes. In that case MS will have to decide on
backwards compatibility vs security.
A work around could also be implemented in the kernel. The
kernel could refuse to load a dll unless there is sufficient
free address space to allow enough randomness. That might
not be a bad idea for other reasons, but is a complete
kludge as a fix to this problem.
64 bit systems should also be safe since it will be
virtually impossible to exhaust their address space.
[ Reply to This | Parent | # ]
|
|
|
|
|