Status

defect
RESOLVED INVALID
5 years ago
8 months ago

People

(Reporter: tom, Unassigned)

Tracking

({sec-want})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(6 attachments)

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.
Status: UNCONFIRMED → NEW
Component: Security → Build Config
Ever confirmed: true
Keywords: sec-want
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.
(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.
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.
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.
Posted file 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.
Flags: needinfo?(tom)
Posted file nightly2.txt
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/mh@glandium.org-20b9fded3a90/ in about an hour.
I ran the .dmg from the ftp site, buildconfig says https://hg.mozilla.org/try/rev/20b9fded3a90

Still no change though.  =/
Summary: ASLR on OSX is weak (useless) because of 10.6 SDK → ASLR on OSX is weak (useless)
So, it may well be something we can't do anything about. Can you check with DYLD_IGNORE_PREBINDING=all?
Also, check other apps using the same system libraries
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.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID
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!
See Also: → 620058
Component: Build Config → General
Product: Firefox → Firefox Build System
You need to log in before you can comment on or make changes to this bug.