1018210 - ASLR on OSX is weak (useless)

Status: RESOLVED INVALID

(Firefox Build System :: General, defect)

Description

[TomRitterOther (don't use this account, use :tjr)]

Attachment: vanilla-firefox-on-osx-aslr-run1.txt

If I run ./firefox from /Applications/Firefox.app/Contents/MacOS with export DYLD_PRINT_SEGMENTS=1 set in a terminal, twice, and diff the output, I should see different __TEXT addresses, because of ASLR.  Locating the libraries at a random location is important as it makes building a ROP chain (to defeat NX/DEP) more difficult.

However, only the libraries in the /Applications/Firefox.app/Contents/MacOS/ folder are located at different addresses.  The System libraries are at the same address.

I believe this is because OS.X prior to 10.7 had very weak ASLR[0] that did not randomize the System libraries.  This is improved in 10.7, but you guys build using the 10.6 SDK.  

I believe that upgrading to the 10.7 SDK would resolve this.  (But then you'd lose support for 10.6.)

If you then set MACOSX_DEPLOYMENT_TARGET back to 10.6, you could support them, but I'm not sure what that would do to ASLR.

Comment 1

[TomRitterOther (don't use this account, use :tjr)]

Attachment: vanilla-firefox-on-osx-aslr-run2.txt

Comment 2

[Mike Hommey [:glandium]]

The good news is that we have the 10.7 SDK on the build slaves, and we're just a mozconfig change away from being able to switch to it.

Comment 3

[Mike Hommey [:glandium]]

Testing this:
https://tbpl.mozilla.org/?tree=Try&rev=e98f4511c7c1

Comment 4

[Mike Hommey [:glandium]]

Tom, do you mind checking again with this build:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-e98f4511c7c1/try-macosx64/firefox-32.0a1.en-US.mac.dmg

Comment 5

[(not currently active) Ted Mielczarek]

(In reply to Tom Ritter from comment #0)
> I believe that upgrading to the 10.7 SDK would resolve this.  (But then
> you'd lose support for 10.6.)
> 
> If you then set MACOSX_DEPLOYMENT_TARGET back to 10.6, you could support
> them, but I'm not sure what that would do to ASLR.

This is the real question here. If we can use the 10.7 SDK to get the ASLR benefit but still support 10.6 then this is a fairly easy fix. If targeting 10.6 keeps this behavior then we can't get it until we agree to drop 10.6 support.

Comment 6

[Mike Hommey [:glandium]]

Note the symptom, though, being that all libraries but Firefox's are not ASLRed would suggest it's prebinding/prelinking doing that. I don't now if ASLR is supposed to override prebinding in 10.7+, but the thing I *do* know is that ASLR is essentially disabled by prebinding, except library load address is still randomized, but it's per machine, not per application. If that's supposed to have changed and OSX changes its behaviour depending on what was used to build the application, that sounds very dumb.

Comment 7

[Mike Hommey [:glandium]]

And from a cursory look at the dyld 195.6 source (that's the version in 10.7.5), it looks like the default for the linker is to use shared regions and prebinding, and there are two ways to have prebinding ignored: executable has the MH_FORCE_FLAT flag (which you get when building with -force_flat_namespace), or the DYLD_IGNORE_PREBINDING environment variable is set to app or all.

So, except if I missed something in the code, which I don't exclude considering I didn't really look deeply, I would expect the behaviour in comment 0 to be the expected (default) behaviour.

Comment 8

[TomRitterOther (don't use this account, use :tjr)]

Attachment: nightly1.txt

Mike: I don't believe that changed anything.  I attached two runs and they have the same addresses for System libraries, but different for the Firefox libraries.

Comment 9

[TomRitterOther (don't use this account, use :tjr)]

Attachment: nightly2.txt

Comment 10

[Mike Hommey [:glandium]]

So let's test your theory from comment 0 entirely:

https://tbpl.mozilla.org/?tree=Try&rev=20b9fded3a90

This will build for 10.7. The resulting binary will be in https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-20b9fded3a90/ in about an hour.

Comment 11

[TomRitterOther (don't use this account, use :tjr)]

Attachment: nightly-attempt2-1.txt

I ran the .dmg from the ftp site, buildconfig says https://hg.mozilla.org/try/rev/20b9fded3a90

Still no change though.  =/

Comment 12

[TomRitterOther (don't use this account, use :tjr)]

Attachment: nightly-attempt2-2.txt

Comment 13

[Mike Hommey [:glandium]]

So, it may well be something we can't do anything about. Can you check with DYLD_IGNORE_PREBINDING=all?

Comment 14

[Mike Hommey [:glandium]]

Also, check other apps using the same system libraries

Comment 15

[Mike Hommey [:glandium]]

Actually, I just went ahead rebooting my mac under OSX. DYLD_SHARED_REGION=avoid is what triggers complete ASLR for all libs. The default is DYLD_SHARED_REGION=use and that means all applications are using a shared cache of, aiui, prebound system libraries. The cache is in /var/db/dyld.

Comment 16

[TomRitterOther (don't use this account, use :tjr)]

Yea, after talking calling up a friend, I can confirm the system libraries' locations are randomized on boot and stay there consistently until reboot, and that this behavior is independent of the SDK used.  Sorry!