Deal with ASLR on Mac OS

[ramosian-glider]

Originally reported on Google Code with ID 29

ASLR is bound to MH_PIE bit in the Mach-O header.
If a binary is built with --no_pie, ASLR is off and there's nothing to worry about.

For a program with MH_PIE bit set ASLR can be disabled at runtime:
 -- on Snow Leopard -- by setting DYLD_NO_PIE=1
 -- on Lion -- by passing the _POSIX_SPAWN_DISABLE_ASLR flag to posix_spawnattr_setflags
(see http://reverse.put.as/2011/08/11/how-gdb-disables-aslr-in-mac-os-x-lion/)

So there are several ways of dealing with ASLR:
 1. Always build with --no_pie if -faddress-sanitizer is on.
 2. At runtime check that the code segments do not interleave with the shadow and:
   2.1 Print an error message that tells to set DYLD_NO_PIE=1 on 10.6 or build with
--no_pie on 10.7
   2.2 Do fork+exec to start a new process with ASLR disabled

Reported by ramosian.glider on 2012-01-18 13:21:21

[ramosian-glider]

Does this mean that on 10.7 the only two choices are --no_pie and fork+exec? 

Reported by konstantin.s.serebryany on 2012-01-18 17:45:25

[ramosian-glider]

Exactly.

Reported by ramosian.glider on 2012-01-19 08:06:07

[ramosian-glider]

I completely forgot about another method suggested by Mark Mentovai that works reliably
on all OS X versions. One can unset the MH_PIE bit in an already linked executable,
using e.g. this script: http://src.chromium.org/viewvc/chrome/trunk/src/build/mac/change_mach_o_flags.py?view=markup

This method is less convenient to integrate with every build process. To do that we'll
need to make Clang run this script after every ld invocation, which is in fact similar
to adding the --no_pie flag.

Reported by ramosian.glider on 2012-01-19 08:32:13

[ramosian-glider]

I'm now considering the following roadmap:

1. Introduce the disable_aslr runtime flag that will tell ASan to do fork+exec. Set
disable_aslr=0 on Snow Leopard and disable_aslr=1 on Lion by default.
2. If MH_PIE bit is set and any of the current mappings is going to intersect with
the shadow, do the following:
 -- if disable_aslr is 0, print a warning and die;
 -- if disable_aslr is 1, fix ASLR by doing fork+exec
3. Make sure Clang doesn't set MH_PIE for executables built with -faddress-sanitizer.

Step 1 is mainly needed to start running Chrome on Lion without additional GYP hackery.
We can also skip Step 2 and pass to Step 3 if we finally want to get rid of disable_aslr.

Reported by ramosian.glider on 2012-02-01 10:57:21

• Labels added: OpSys-OSX

[ramosian-glider]

I've spent some time playing with ASLR on Lion and here are two conclusions:
 -- doing posix_spawn with POSIX_SPAWN_SETEXEC and _POSIX_SPAWN_DISABLE_ASLR is equal
to exec() without fork() and should disable ASLR as well;
 -- I haven't managed to trigger any ASLR problems on Lion for the binaries built with
-fpie. This is probably because ASLR is much smarter on Lion.

Attached is the patch that disables ASLR on Lion, but I'm not going to commit it until
I notice any problems with ASLR on Lion.

Reported by ramosian.glider on 2012-02-01 14:21:21

---

- _Attachment: [asan_mac_aslr.patch](https://storage.googleapis.com/google-code-attachments/address-sanitizer/issue-29/comment-5/asan_mac_aslr.patch)_

[ramosian-glider]

As Snow Leopard will be obsolete soon, the issue becomes less (if at all) important.
The reliable workaround is to set DYLD_NO_PIE=1.

Reported by ramosian.glider on 2012-10-29 11:11:41

• Labels added: Priority-Low
• Labels removed: Priority-Medium

[ramosian-glider]

Do we still need to support 10.6? 
Can we close this bug? 

Reported by konstantin.s.serebryany on 2013-02-18 07:15:45

[ramosian-glider]

We still need to support 10.6 for some time, yet we don't want to fix ASLR on 10.6.
Will reopen if we ever have problems with newer OS X versions.

Reported by ramosian.glider on 2013-02-18 11:13:42

• Status changed: WontFix

[ramosian-glider]

Adding Project:AddressSanitizer as part of GitHub migration.

Reported by ramosian.glider on 2015-07-30 09:12:58

• Labels added: ProjectAddressSanitizer