Date: Thu, 24 Jul 2014 09:52:00 -0400 From: Shawn Webb <lattera@gmail.com> To: Robert Watson <rwatson@FreeBSD.org> Cc: Tim Kientzle <tim@kientzle.com>, Bryan Drewery <bdrewery@freebsd.org>, Pedro Giffuni <pfg@freebsd.org>, freebsd-arch@freebsd.org, PaX Team <pageexec@freemail.hu>, Oliver Pinter <oliver.pntr@gmail.com> Subject: Re: [RFC] ASLR Whitepaper and Candidate Final Patch Message-ID: <20140724135200.GR29618@pwnie.vrt.sourcefire.com> In-Reply-To: <alpine.BSF.2.11.1407241035550.116@fledge.watson.org> References: <96C72773-3239-427E-A90B-D05FF0F5B782@freebsd.org> <20140720201858.GB29618@pwnie.vrt.sourcefire.com> <alpine.BSF.2.11.1407230017490.88645@fledge.watson.org> <20140723004543.GH29618@pwnie.vrt.sourcefire.com> <D7CEDB47-2818-461A-BB70-479BEBDCEEE9@freebsd.org> <796EDB88-3768-48AA-B909-8A7FFBED0C1E@kientzle.com> <alpine.BSF.2.11.1407241035550.116@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--CPn8Wy5ME997YUMW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Jul 24, 2014 10:43 AM +0100, Robert Watson wrote: > On Wed, 23 Jul 2014, Tim Kientzle wrote: >=20 > >>> I'll take a look at ElectricFence this weekend. Additionally, I have = a=20 > >>> netbook somewhere. Once I find it and its power cord, I'll install=20 > >>> FreeBSD/x86 and re-run the same tests on that. > >> > >> Somewhat related to ElectricFence? will ASLR have an adverse effect on= =20 > >> 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=20 > > 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 breakp= oint=20 > > will have the same meaning between runs. >=20 > Non-determism in debugging is a big issue with=20 > diversification/randomisation-based mitigation techniques. There are a n= umber=20 > of aspects to the problem, but the most clear implication is that it shou= ld be=20 > possible to create deterministic and reproducible debugging environments = in=20 > the local development context. This means, I think, being able to create= a=20 > hierarchy of processes in which the randomisation features are by policy= =20 > turned off. The contexts in which that property is set are interesting -= - do=20 > you want a "no randomisation subshell" in which every program you run has= ASLR=20 > turned off? Or do you just want gdb to turn it off? What if, this time= =20 > around, you want gdb to have it turned on? And how do you deal with=20 > setuid/setgid/transitioning binaries -- we don't want a regular user to s= ay=20 > "turn off ASLR for this process subtree" and have it prevent ASLR from=20 > 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. >=20 > I think the natural conclusion is that you need multiple means to disable= ASLR=20 > that operate at different granularities, and that have different control= =20 > mechanisms. Off-hand, I see a few: >=20 > (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. >=20 > (2) A new inherited process property, or perhaps credential property, ena= bling > ASLR. This can be changed to 'disabled' using a system call -- perh= aps > 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 t= he > global default. It would be easy to imagine this being CR_ASLR on t= he > 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. >=20 > (3) As suggested by Kostik, an ELF note on binaries indicating that the b= inary > is not ASLR-compatible, which would override (I guess) the global po= licy > flag and process/credential flag. We could then set this with > NO_ASLR=3Dtrue 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. >=20 > (4) It sounds like a jail-scope policy would also be useful -- I guess th= is > 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. >=20 > I'm not opposed to MAC policy modules being able to manipulate ASLR behav= iour,=20 > but I think I'd prefer that the core policy controls (e.g., the above) be= =20 > MAC-independent. Part of the reason is that you may want ASLR on very lo= w-end=20 > 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. >=20 > How does this interact with features like the Linuxulator? Do we also wa= nt=20 > ABI emulations to be able to disable ASLR as ABIs might not support it [w= ell]? Oliver has done testing on the linuxulator and has found it to be stable. He can share more info about this. Thanks, Shawn --CPn8Wy5ME997YUMW Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT0Q9/AAoJEGqEZY9SRW7uwNQP/ieOC7enFVBkD0V5LgXn3Txi xF2MZQM3JMPIpwv6+J7fhnKezt2YSC2lrpuqWBNwD3XOTXXV0aAA9JwsB5bjTLYo /4H+2db28XhYA48oNZ3LVODDHiF4gEc3xOh026j/wqvtvsSYavbS9c9ete5CvWqn Y2cFhUSMeVwNprqanRZ07yCdPCYPbgdU3loNwgEYVJYhXyozapq3U7+Y4fQJrYDd 8O8v0LfODkJeTVYdE2qJFAnYd3UEm6gEKHLnP1dJfxzBQ0FUXmJqly+zOsC8rljE ibxaZQjceBtKSlSKsoftymN1hN/FmDEH+ldSL3CKRnJ+NMgKQpiL71r8E3cON4R3 XUpivGUbAQ7kS57IXTXjjJI/ikyawDUacBctSzfFNaFth6RfB7c0bcCj7mlr22pA ig7uOr8qsjVuXZovBphGkcu2BLNKs1C7MO7nmZjDQ47VnrkzE7TERzN0tMxOdT4Z ZcX1y/Z5NN/FjxYs4xXAKVQz+frl866GcTTVo44ex24LH21uwREgRYpU3mxFSHJi a8SHmHvnxwRP+Md2qXpeA7QL1h274Lytdnshytv89nrvZ2AJQOd7I2GE0LTcjQEc Fp9L9IXKv6dXxMn/M4iw5ZK+y9x2MNMSQP3oAQehK7NJUZ8ZxcDeHzfAs4cwLvH0 4vB84c7u71GUWPFqBs88 =+6yX -----END PGP SIGNATURE----- --CPn8Wy5ME997YUMW--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140724135200.GR29618>