ASLR and PIE disabled by default

[Matthew Dillon]

I've debated turning on some of these features by default but I find it to
be a bit of a hard sell because these mechanisms just don't protect well
against modern attacks.  The randomization is not sufficient, but making it
large enough to be sufficient also creates a massive fragmentation problem
for any program that mmap()'s and munmap()'s a ton of stuff.

Actually, the one I'd really like to implement is support for the
execute-disable bit on the stack.  No point turning on ASLR or PIE without
that.  It would be a minor project for someone.  We already support the
pmap bit, but the protection map doesn't map VM_PROT_EXECUTE and the ELF
loader's mappings might be a bit off, too.

Unfortunately, none of these mechanisms (not even the ED bit) really
mitigate exploits, which should be obvious simply by observing the insane
number of machines out in the wild that have viruses.  The only real
protection is to reduce the network-facing attack surface as much as
possible and to segregate clients.  That's 99% of security.  1% of it is
something like ASLR or PIE or ED.  In some respects, these mitigations are
their own worse enemy because they create a false sense of security.

The biggest looming problem we have can't be protected by ED, ASLR, PIE, or
any other OS-supported mechanism.   The biggest looming problem are attacks
against interpreters and scripting languages, and side-band attacks against
dynamic ram and cpu caches.  Not just SQL injection or java byte code
attacks, but so many programs these days integrate interpreters of one sort
or another into their operation that attacking the interpreter is becoming
easier and easier.  Side-band attacks are even more dangerous as those can
be used to suss-out encryption keys and (for the DRAM attack) to directly
bypass all known protective mechanisms.

-Matt
​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20170403/126b2f0f/attachment-0002.html>