[RFC] ASLR Whitepaper and Candidate Final Patch

[Shawn Webb]

On Jul 24, 2014 10:43 AM +0100, Robert Watson wrote:
> On Wed, 23 Jul 2014, Tim Kientzle wrote:
> 
> >>> I'll take a look at ElectricFence this weekend. Additionally, I have a 
> >>> netbook somewhere. Once I find it and its power cord, I'll install 
> >>> FreeBSD/x86 and re-run the same tests on that.
> >>
> >> Somewhat related to ElectricFence? will ASLR have an adverse effect on 
> >> debuggers?
> >>
> >> I googled around and got to this:
> >>
> >> http://www.outflux.net/blog/archives/2010/07/03/gdb-turns-off-aslr/
> >>
> >> So I guess we may have to patch gdb (and lldb)?
> >
> > I suspect the issue here is that debugging often requires multiple runs of a 
> > program with repeatable behavior between runs.
> >
> > Consider:
> >
> > * I run the program under GDB, it crashes at a certain PC address
> >
> > * I restart the program, set a breakpoint at that PC address
> >
> > I want to be confident that the PC address where I?m setting the breakpoint 
> > will have the same meaning between runs.
> 
> Non-determism in debugging is a big issue with 
> diversification/randomisation-based mitigation techniques.  There are a number 
> of aspects to the problem, but the most clear implication is that it should be 
> possible to create deterministic and reproducible debugging environments in 
> the local development context.  This means, I think, being able to create a 
> hierarchy of processes in which the randomisation features are by policy 
> turned off.  The contexts in which that property is set are interesting -- do 
> you want a "no randomisation subshell" in which every program you run has ASLR 
> turned off?  Or do you just want gdb to turn it off?  What if, this time 
> around, you want gdb to have it turned on?  And how do you deal with 
> setuid/setgid/transitioning binaries -- we don't want a regular user to say 
> "turn off ASLR for this process subtree" and have it prevent ASLR from 
> protecting a setuid binary from the user.

Great points. I agree completely. This is why I've added two facilities
for toggling ASLR. I modified mac_bsdextended(4)/ugidfw(8) to provide
toggling ASLR on a per-binary basis. I also made the sysctl tunables
settable per-jail. This allows one to place the executable in question
in a jail where ASLR is turned off just for that jail. I came across
this on Tuesday of this week when doing ClamAV development. Since I do
all my development in a jail, I came across a bug in ClamAV and I needed
deterministic behavior, so I turned off ASLR just for that jail and was
able to find the cause of the bug and fix it.

> 
> I think the natural conclusion is that you need multiple means to disable ASLR 
> that operate at different granularities, and that have different control 
> mechanisms.  Off-hand, I see a few:
> 
> (1) A global enable/disable flag that sets the default policy.

We have that via the sysctl security.pax.aslr.status, which is settable
at boot-time via /boot/loader.conf or at runtime if the kernel has been
compiled with PAX_SYSCTLS option.

> 
> (2) A new inherited process property, or perhaps credential property, enabling
>      ASLR.  This can be changed to 'disabled' using a system call -- perhaps
>      prctl() or similar.  If we hit a transitioning binary (e.g., setuid) then
>      in the same way that we manipulate other properties, we'd reset to the
>      global default.  It would be easy to imagine this being CR_ASLR on the
>      cr_flags field of the credential.  This could be set in various ways by
>      userspace applications -- by gdb, as a login-shell property, perhaps via
>     'su' or something simular?

This is interesting. I didn't think of using the prctl facility. I'll
look into that.

> 
> (3) As suggested by Kostik, an ELF note on binaries indicating that the binary
>      is not ASLR-compatible, which would override (I guess) the global policy
>      flag and process/credential flag.  We could then set this with
>      NO_ASLR=true in Makefiles, during package creation, etc.

I really don't like ELF flags. It's really heavy-handed. It can trip
file-based IDSs (the hash of the file changes when you change an ELF
flag). It requires that the user, sysadmin, or team of sysadmins keep a
database of binaries for which the ELF flag needs to be changed when the
binary gets updated or replaced (think: freebsd-update, pkgng/ports).
This is why I went with mac_bsdextended(4)/ugidfw(8). In the end, the
user is still maintaining a database (via ugidfw(8) rules). But the user
doesn't need to go back and modify anything if that binary were to ever
be modified.

With that said, we are planning on also adding FS extended attribute
support as well. Though I'm unsure if extended attributes work over
network-mounted filesystems like NFS.

> 
> (4) It sounds like a jail-scope policy would also be useful -- I guess this
>      might actually be the same as (1) in the sense that (1) could be
>      represented in terms of a jail-scope policy.

We have already implemented this as per-jail sysctl tunables.

> 
> I'm not opposed to MAC policy modules being able to manipulate ASLR behaviour, 
> but I think I'd prefer that the core policy controls (e.g., the above) be 
> MAC-independent.  Part of the reason is that you may want ASLR on very low-end 
> systems where the additional cost of MAC interposition is more measurable.

How much overhead does mac_bsdextended(4) have? I'm assuming a small
ruleset pertaining to ASLR.

> 
> How does this interact with features like the Linuxulator?  Do we also want 
> ABI emulations to be able to disable ASLR as ABIs might not support it [well]?

Oliver has done testing on the linuxulator and has found it to be
stable. He can share more info about this.

Thanks,

Shawn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20140724/d904d2eb/attachment.sig>