From 84cc9e82dbff1d02ccc029e16253e7f61567e07f Mon Sep 17 00:00:00 2001 From: Dru Lavigne Date: Fri, 8 Jul 2016 17:13:40 +0000 Subject: [PATCH] Add ASLR report from kib@FreeBSD.org. Approved by: wblock Sponsored by: iXsystems --- .../news/status/report-2016-04-2016-06.xml | 144 ++++++++++++++++++ 1 file changed, 144 insertions(+) diff --git a/en_US.ISO8859-1/htdocs/news/status/report-2016-04-2016-06.xml b/en_US.ISO8859-1/htdocs/news/status/report-2016-04-2016-06.xml index 1ee826b342..ed1a5d928f 100644 --- a/en_US.ISO8859-1/htdocs/news/status/report-2016-04-2016-06.xml +++ b/en_US.ISO8859-1/htdocs/news/status/report-2016-04-2016-06.xml @@ -887,4 +887,148 @@ the update progress.

+ + + ASLR Interim State + + + + + Konstantin + Belousov + + kib@FreeBSD.org + + + + + Patch home + + + +

This is an interim report on the technical state of the ASLR + patch.

+ +

The proccontrol(1) utility was written to manage and + query ASLR enforcement on a per-process basis. It is required + for analyzing ASLR failures in specific programs. This + utility leverages the procctl(2) interface which was + added to the previous version of the patch, with some bug + fixes.

+ +

With r300792, ASLR settings are reset to system-wide defaults + whenever a setuid binary is executed.

+ +

The command's syntax is:

+ +

proccontrol -m (trace|aslr) [-q] [-s (enable|disable)] + [-p pid | command]

+ +

-m (specifies trace mode to control debugger + attachments)

+ +

-q (queries the state of the specified mode for the + process with the PID specified by -p option)

+ +

-e (toggles the feature on or off for the given + process or itself)

+ +

If the command is specified, it inherits the applied + settings from proccontrol. For instance, to start a + build of a program with ASLR disabled, use + proccontrol -m aslr -s disable make.

+ +

The ports exp run was done with ASLR tuned up to the most + aggressive settings. The results can be found in PR 208580.

+ +

SBCL is an interesting case which illustrates several points. + It is much smaller than JDK, and its build system is easier to + work with. The code provides a very non C-ish language + runtime which utilizes a lot of corner cases and non-standard + uses of VM, at least from the point of view of a typical C + programmer.

+ +

SBCL compiles Lisp forms into the machine native code and + manages its own arena for objects. The precompiled Lisp + runtime is mapped from the core file. SBCL relies on + the operating system's C runtime for the initial load of Lisp, + and needs a functional libc to issue many system + calls, including syscalls, as well as the dynamic loader. The + end result is that there are unfixed mmap(2) calls + during both startup and runtime, interfering with the + MAP_FIXED mmaps. The core file loading and arenas + are hard-coded to exist at fixed addresses.

+ +

This happens to work on the default address map, which is not + changed often, so the SBCL choices of the base addresses + evolved to work. But any significant distortion of the + standard map results in SBCL mmap(MAP_FIXED) requests + to override memory from other allocators.

+ +

&os; uses the MAP_EXCL flag to mmap(2), + which must be used in MAP_FIXED|MAP_EXCL form to + cause mmap(2) failure if the requested range is + already used. I tried to force MAP_FIXED requests + from SBCL to implicitely set MAP_EXCL, but this did + not go well since SBCL sometimes pre-allocates regions for + later use with MAP_FIXED. So, MAP_EXCL + mappings failed, dumping the process into ldb.

+ +

On Linux, if a kernel is detected in AS-randomization mode, + the initial SBCL runtime sets personality to non-random and + re-execs. This might be a solution for &os; as well, after + the ASLR patch is committed, so that the procctl(2) + knob is officially available.

+ +

SBCL still has issues on Linux, even with re-exec, when + more aggressive randomization from PaX patch is applied, as + seen in bug + 1523213.

+ +

The Emacs build procedure involves loading the + temacs image with the compiled Emacs Lisp files and + then dumping the memory to recreate the image with the + preloaded content, in order to shrink the start time.

+ +

Recent Emacs sources seem to generally avoid + MAP_FIXED, except in some situations. When Emacs + does use the flag, it carefully checks that the selected + region is not busy. In fact, Emacs would benefit from + MAP_EXCL.

+ +

I tried several runs of building Emacs and running the dumped + binary, but was not able to reproduce the issue. It seems + that the code improved enough to tolerate ASLR both in Linux + and NetBSD without turning it off.

+ +

In my opinion, it is not reasonable to fight the issues in + the kernel as most of it is not fixable from the kernel side. + The procctl(2) interface and proccontrol(1) + utilities provide the override when needed, but are not + automated.

+ +

The set of ports which cannot be built with ASLR turned on + should be limited but fluid. However, exp-runs may not + reliably uncover all problems due to randomization, as seen in + the Emacs example. In the route to enable ASLR by default in + non-aggressive settings, the ports framework should provide an + option like ASLR_UNSAFE=yes which spawns + proccontrol -m aslr -s disable make for the build + stages of the unsafe port. Users would still need to be aware + of proccontrol(1) in order to run the resulting + binary.

+ +

A recommended approach is a flag in the ELF binary to mark + it as not compatible with non-standard AS layouts. This frees + users from having to use proccontrol(1), but still + requires patching and upstreaming. This approach is also + useful outside the context of ASLR. However, the + mechanism is not yet ready, and developing it is a larger work + than ASLR itself.

+ + + The FreeBSD Foundation +