[RFC] ASLR Whitepaper and Candidate Final Patch

[Robert N. M. Watson]

On 24 Jul 2014, at 14:52, Shawn Webb <lattera at gmail.com> wrote:

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

Could you say a bit more about the ugidfw use case: is it common to want to not use ASLR for particular users or groups, rather than it being focused on applications or installed system instances?

One question I have is whether it is sometimes the case that code in libraries is ASLR-unfriendly, as opposed to code in applications? Tagging binaries is easy, but as run-time linking of some specific library within a process might happen after quite a few layout choices have been influenced by ASLR. Or is it really just applications that have problems?

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

The main use case I have in mind for this is repeatable application development: I'm running test suites against one or more in-development programs and would like to get deterministic test-suite runs. This might well not be under the debugger, so automatic disabling under the debugger doesn't help, but it is a debugger-like environment in which determinism is important.

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

I'm not imagining that the ELF note is something you change frequently or dynamically: rather, that it's effectively a part of application linking by the system build or packaging system. That means that the ELF note will be in place before any IDS tools generate initial signatures, etc. E.g., NO_ASLR in a base-system Makefile would cause us to always generate the binary with a suitable ELF note in place. Similarly, as part of the port definition, we might identify that some or all binaries generated by the port require the ELF note. This will be much more robust than using techniques like ugidfw or extended attributes, where changes in file ownership, storing on filesystems without extended attributes, etc, will prove extremely fragile.

With that in mind: is there a use case in which you see binaries being distributed by the FreeBSD Project that an end user will want to always run without ASLR despite the fact that we believe the program to be ASLR-friendly? Other than debugging environments, where tools such as gdb can dynamically disable ASLR for specific processes, or we're not in a 'debug shell' per above?

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

Depends a lot on the system and configuration. The MAC Framework has certain baseline costs when enabled but inactive -- which we have attempted to minimise to the greatest extent possible. These are typically masked pretty well on cache-centred, superscalar architectures, but may be more visible on systems with less ILP and slower clock rates (e.g., our FPGA-based BERI processors). Turning the MAC Framework on, however, introduces additional costs -- I've not benchmarked ugidfw lately, but my guess would be that it has a >0% and <5% overhead on cached filesystem operations -- something to confirm if we anticipate it entering universal use rather than being selectively configured as part of a local tradeoff.

I have other concerns about ugidfw as well: we don't have a useful scheme to 'merge' different sets of ugidfw rule sets -- e.g., ones provided by the vendor (make the pgsql user always turn off ASLR) vs the end administrator, as it's intended to be an administrator-facing tool rather than a vendor-facing tool. More generally, I'd like to learn more about use cases in which users and groups, rather than application installs or virtual-system instances, become a desirable granularity for ASLR policy.

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

The question I had in mind was: are their ABIs that we emulate in which introducing ASLR might violate assumptions of the ABI, or disrupt more subtle functions of the emulator? For example, Kostik has pointed out that mechanisms such as FreeBSD's ps_strings (part of our ABI) are sensitive to randomised layout of the initial process stack, and changes could cause certain ps(1) and procstat(1) functions to fail (e.g., ps -e, procstat -x). A careful analysis of each ABI would be required to convince ourselves that this isn't a problem. With ASLR use on many other systems, it could well be that only the FreeBSD ABI remains sensitive to surprising randomness, but that's not an assumption I would reach naturally as well-known addresses have long been part of ABIs.

Robert