ASLR and PIE disabled by default

[Carsten Mattner]

On Mon, Apr 3, 2017 at 6:36 PM, Matthew Dillon <dillon at backplane.com> wrote:
> 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.

Maybe port Capsicum and relentlessly apply it to the base programs
is a good start? The work in FreeBSD can be reused and dports could
make changes to ports which then land in FreeBSD and cross-pollinate
back and forth. It's a shame Linux has NIH more often than not and
following FreeBSD's lead in Capsicum application would decrease the
effort and improve the resiliency of both BSD systems.

I would, naturally, suggest to focus on capsicum'izing web browsers
as the most bang for buck item and continue down the stack from there.

> 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.

I agree those mechanisms are defeated without too much effort these days
which is why grsecurity advertises their anti-ROP feature.

Whether it's better to not implement/use those mechanisms is an interesting
question I've been pondering inconclusively but my gut tells me it increases
the effort of an exploit and is worth it in general.

Matthew, have you considered implementing a capability model for the
components of DragonflyBSD? This has usually been tied to a microkernel
design but since SSI has been one of the goals and the concurrency
approach is unconventional for a UNix, maybe it crossed your mind?