Closed
Bug 677797
Opened 13 years ago
Closed 6 years ago
Mandatory ASLR on Windows
Categories
(Core :: Security: Process Sandboxing, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: jruderman, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(3 files, 1 obsolete file)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
text/plain
|
Details | |
(deleted),
text/plain
|
Details |
Whenever Firefox is about to load a DLL that has ASLR disabled, it should allocate a page at the DLL's imagebase, forcing the OS to relocate it. The appropriate hook is ntdll!LdrLoadDll, which we already hook in nsWindowsDllBlocklist.cpp. This would solve problems like http://www.scriptjunkie.us/2011/06/bypassing-dep-aslr-in-browser-exploits-with-mcafee-symantec/ without blocking the DLLs (which I had proposed in bug 642365). Suggested by @fjserna, who used this trick in Microsoft's Enhanced Mitigation Experience Toolkit (EMET).
Comment 1•13 years ago
|
||
So this just forces the OS to rebase every DLL? I've never understood why ASLR was opt-in when the OS is free to rebase your library at any time anyway... Are there reasons why third-party DLLs aren't ASLR-enabled, or is it just negligence?
Comment 2•13 years ago
|
||
Repeating caution from previous email threads: this is very likely to break tools which inject DLLs into Firefox, including many accessibility tools and drivers. Before we even consider turning this on by default we should do some telemetry and figure out what DLLs might be affected.
Component: XPCOM → Security
QA Contact: xpcom → toolkit
Comment 3•13 years ago
|
||
Bah, I misread the original. This is a good technique if we need it. It has the disadvantage of forcing many DLLs to no longer use shared memory for their code, which can be a significant performance penalty.
Comment 4•13 years ago
|
||
(In reply to Ted Mielczarek [:ted, :luser] from comment #1) > So this just forces the OS to rebase every DLL? I've never understood why > ASLR was opt-in when the OS is free to rebase your library at any time > anyway... > > Are there reasons why third-party DLLs aren't ASLR-enabled, or is it just > negligence? mostly negligence, at this point, IMO. one thing is that this could help us on older platforms that don't have ASLR built in (if we still support Windows versions earlier than Vista, which i think we do). this isn't really a like-for-like substitute for true ASLR, which is supposed to be cryptographically random - that's also the advantage true ASLR has over just rebasing (which can be pretty predictable and even essentially 'static' in practice ie the DLL loads at the same place every time even if it's not its preferred load address). in fact, we would probably want to do some experiments to see just how 'random' the final load address of a DLL who's preferred load address is, if this just forces the dll to load at a predictable address that's not its preferred address, it's not going to be a huge difference, i think. my 2 cents on this vs bug 642365 is that this approach will cause less breakage than blocking DLL load, while still somewhat improving resistance to attacks, also the perf hit for not being able to share dll's across process seems like a good tradeoff for making reliable exploitation quite a bit more difficult, given the caveat about seeing where the DLL actually ends up across multiple runs
Comment 5•13 years ago
|
||
Ok, did some experiments on how random this technique rebases DLL's. I used EMET, only turning on the mandatory ASLR mitigation for Firefox and using comodo firewall's guard32.dll as an example of a non-ASLR DLL that gets loaded into Firefox. (by default at 0x10000000) After 6 manual runs, here are the base addresses it got loaded up at: 0x00198000 0x00188000 0x00198000 0x00500000 0x00f20000 0x00160000 Since only one of those was repeated, I would never write an exploit that relied on predicting the address of that DLL. So as a Firefox user, I highly recommend the change, as it does seem to make a big difference. Also, it seems more thorough than managing a DLL black or white list.
Comment 6•13 years ago
|
||
Ehsan said he will work up a patch for this (not super-urgently, though), which we can then experiment with.
Assignee: nobody → ehsan
Reporter | ||
Updated•13 years ago
|
Blocks: exploit-mitigation
Reporter | ||
Comment 7•13 years ago
|
||
http://blog.didierstevens.com/2011/08/16/so-how-good-is-pseudo-aslr/
Reporter | ||
Comment 8•13 years ago
|
||
http://blog.didierstevens.com/2011/09/01/bottom-up-randomization-saves-mandatory-aslr/
Comment 9•13 years ago
|
||
This patch implements mandatory ASLR on Windows. The browser basically stands up with this patch. I tried going to youtube and playing a video, and it seems to work just fine. But I have no idea how to meaningfully test this patch. I have submitted a try server job with this patch (on top of the patch in bug 648581) in case QA folks and other people want to test this.
Attachment #560847 -
Flags: review?(benjamin)
Comment 10•13 years ago
|
||
Try run for 735d43088088 is complete. Detailed breakdown of the results available here: https://tbpl.mozilla.org/?tree=Try&rev=735d43088088 Results (out of 63 total builds): exception: 1 success: 60 warnings: 2 Builds available at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/eakhgari@mozilla.com-735d43088088
(In reply to Ehsan Akhgari [:ehsan] from comment #9) > But I have no idea how to meaningfully test this patch. Should probably test this with various a11y and A/V products.
Comment 12•13 years ago
|
||
Comment on attachment 560847 [details] [diff] [review] Patch (v1) > + void* page = ::VirtualAlloc((LPVOID)ntHeader->OptionalHeader.ImageBase, 1, > + MEM_COMMIT | MEM_RESERVE, PAGE_NOACCESS); Isn't it enough to reserve the memory? Is it also required to commit? > + // Note that we will leak this page, since there is no meaninful way > + // for us to free it when the DLL is unloaded. > + > + // We're done at this point! Why do you have to wait until the dll has been unloaded? Is it impossible to free after the original LdrLoadDll has been called? I thought LdrLoadDll was synchronous.
Comment 13•13 years ago
|
||
I am concerned that the naive implementation here will greatly affect startup performance of plugin/content processes: we very much need Windows and Mozilla DLLs to be mapped to the same locations in both processes... unless the patch as written only affect post-startup DLL mappings, in which case it might not matter so much.
Reporter | ||
Comment 14•13 years ago
|
||
// If we're dealing with a DLL which has code inside it, but does not have the // ASLR bit set, allocate a page at its base address. Windows and Mozilla DLLs have the ASLR bit set, so they shouldn't be affected.
Comment 15•13 years ago
|
||
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #11) > (In reply to Ehsan Akhgari [:ehsan] from comment #9) > > But I have no idea how to meaningfully test this patch. > > Should probably test this with various a11y and A/V products. David, Marco, you can grab try builds from comment 10.
Comment 16•13 years ago
|
||
(In reply to Masatoshi Kimura [:emk] from comment #12) > Comment on attachment 560847 [details] [diff] [review] > Patch (v1) > > > + void* page = ::VirtualAlloc((LPVOID)ntHeader->OptionalHeader.ImageBase, 1, > > + MEM_COMMIT | MEM_RESERVE, PAGE_NOACCESS); > Isn't it enough to reserve the memory? Is it also required to commit? Hmm, I don't see why only reserving might not be enough. Good catch. I will submit a new version of the patch which removes the commit flag if this passes the testing phase. > > + // Note that we will leak this page, since there is no meaninful way > > + // for us to free it when the DLL is unloaded. > > + > > + // We're done at this point! > Why do you have to wait until the dll has been unloaded? Is it impossible to > free after the original LdrLoadDll has been called? I thought LdrLoadDll was > synchronous. Once we have a good way to test this, we can experiment with freeing the page after LdrLoadDll. This is a good point, and I'm positive that we can free the page once LdrLoadDll is done...
Comment 17•13 years ago
|
||
(In reply to Benjamin Smedberg [:bsmedberg] from comment #13) > I am concerned that the naive implementation here will greatly affect > startup performance of plugin/content processes: we very much need Windows > and Mozilla DLLs to be mapped to the same locations in both processes... > unless the patch as written only affect post-startup DLL mappings, in which > case it might not matter so much. This will not affect the DLLs which we load statically, since the hook gets a chance to run once XPCOM initializes. And as Jesse points out, it will not affect the perf for DLLs which have ASLR enabled (except for mapping their headers into memory, that is). But I would feel a lot better if we can actually test that assertion. :-) Also, the general idea here might be used to fix bug 642243 (we can add some code to go through the list of loaded modules at startup when installing the hook in debug builds and abort if it finds non-ASLR modules or something, and we can do the same in this code as well.)
Blocks: 642243
Comment 18•13 years ago
|
||
We need some QA here. Basically we need to test the builds in comment 10 with as many Windows platforms as possible. It would be a good thing if those Windows systems have things like AV systems, accessibility clients, plugins, etc. installed.
Keywords: qawanted
Comment 19•13 years ago
|
||
(In reply to Ehsan Akhgari [:ehsan] from comment #17) > > Also, the general idea here might be used to fix bug 642243 (we can add some > code to go through the list of loaded modules at startup when installing the > hook in debug builds and abort if it finds non-ASLR modules or something, > and we can do the same in this code as well.) bug 642243 is a build time check to make sure that all DLL's included as part of the firefox windows build have ASLR and all the other Windows OS-level protections, not a runtime check. additionally, i don't think aborting on non ASLR libraries is feasible, as some AV and accessibility tools that inject DLL's into our process(es) won't have this turned on and we still want those people to be able to run the browser.
Comment 20•13 years ago
|
||
(In reply to Ian Melven :imelven from comment #19) > (In reply to Ehsan Akhgari [:ehsan] from comment #17) > > > > Also, the general idea here might be used to fix bug 642243 (we can add some > > code to go through the list of loaded modules at startup when installing the > > hook in debug builds and abort if it finds non-ASLR modules or something, > > and we can do the same in this code as well.) > > bug 642243 is a build time check to make sure that all DLL's included as > part of the firefox windows build have ASLR and all the other Windows > OS-level protections, not a runtime check. additionally, i don't think > aborting on non ASLR libraries is feasible, as some AV and accessibility > tools that inject DLL's into our process(es) won't have this turned on and > we still want those people to be able to run the browser. Right, maybe not an abort, but a TEST-UNEXPECTED-FAIL or something in debug builds which can be caught by our test infrastructure...
To be clear, it's not just a11y and A/V tools that don't do ASLR. On my machine (stock X220) the Intel gfx drivers don't do ASLR.
Comment 22•13 years ago
|
||
It is unclear to me what behavior we are trying test for once this patch is in place. Can someone elaborate some details on this.
Comment 23•13 years ago
|
||
(In reply to Matt Evans [:mevans] from comment #22) > It is unclear to me what behavior we are trying test for once this patch is > in place. Can someone elaborate some details on this. The testing involves two parts: 1. Make sure that all of the DLLs loaded by Firefox before this patch can be loaded by it after this patch too. 2. Make sure that this patch doesn't have a negative impact on startup time. (Maybe this falls outside of the focus of QA, but I'm not sure who else can test this...)
Comment 24•13 years ago
|
||
Comment on attachment 560847 [details] [diff] [review] Patch (v1) I don't think there's any point in freeing the page as long as we only reserve and never commit it. r=me with that change. Note that this should be tracking and we should watch for crazy fallout from this. I think you reinvented nsAutoArrayPtr, from IRC it seems we could just use that. r=me with those changes
Attachment #560847 -
Flags: review?(benjamin) → review+
Comment 25•13 years ago
|
||
(In reply to Ehsan Akhgari [:ehsan] from comment #18) > We need some QA here. Basically we need to test the builds in comment 10 > with as many Windows platforms as possible. It would be a good thing if > those Windows systems have things like AV systems, accessibility clients, > plugins, etc. installed. The link to the build with the fix in comment 10 is not working. But, when available, testing will start following the suggestions in comment 23; from this side, the following versions of windows are available for testing: Win7 x86, x64, XP x86, Vista x86, Win2000;
Comment 26•13 years ago
|
||
Marking this as tracking to make sure that people will keep an eye on it for regressions, etc. Also, this is something that the Performance Team should know about. CCing Taras.
tracking-firefox10:
--- → +
Comment 27•13 years ago
|
||
With comments addressed.
Attachment #560847 -
Attachment is obsolete: true
Comment 28•13 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/e54779beb706
Target Milestone: --- → mozilla10
Comment 29•13 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/e54779beb706
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Updated•13 years ago
|
Whiteboard: [sg:want P1] → [sg:want P1][qa+]
Comment 30•13 years ago
|
||
In case people didn't notice the dependent bug 694432 being added, it's suspected that this is the change that is causing nightlies not to start on Windows 8 preview.
Comment 31•13 years ago
|
||
(In reply to Ehsan Akhgari [:ehsan] from comment #23) > (In reply to Matt Evans [:mevans] from comment #22) > > It is unclear to me what behavior we are trying test for once this patch is > > in place. Can someone elaborate some details on this. > > The testing involves two parts: > > 1. Make sure that all of the DLLs loaded by Firefox before this patch can be > loaded by it after this patch too. > 2. Make sure that this patch doesn't have a negative impact on startup time. > (Maybe this falls outside of the focus of QA, but I'm not sure who else can > test this...) I tested the fix for this bug considering the above testing guidelines. The results of the testing are the following: -> Win 7x86: Verified Fixed on the latest Nightly Build identifier: Mozilla/5.0 (Windows NT 6.1; rv:10.0a1) Gecko/20111017 Firefox/10.0a1 -> Win 7x64: Verified Fixed on the latest Nightly Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111017 Firefox/10.0a1 -> Win XP: Verified Fixed on the latest Nightly In this case (win XP), ASLR is not enabled. In all testing cases, I used a Firefox Nightly build that did not have the patch/fix here landed i.e. (01 October build) to compare it with the Nightly build with this fix (17 October). I used the Process Explorer software to track and view the DLLs loaded by Firefox and performed the testing on a clean Firefox profile. If there are no objections and/or additions to the testing performed I will take the opportunity to set this bug on Verified Fixed. Thanks!
Comment 32•13 years ago
|
||
I backed it out to see whether it helps with the crashes seen in bug 694344. https://hg.mozilla.org/mozilla-central/rev/ddaf5686c70c
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 33•13 years ago
|
||
We should look at this carefully. Kinda the point of ASLR is that exploit code will tend to crash where otherwise it would execute successfully.
Comment 34•13 years ago
|
||
Look at what carefully? Bug 694344 is not exploit code, it is a invalid-parameter crash where a call to GetProcAddress is returning NULL unexpectedly. We don't know why.
Comment 35•13 years ago
|
||
Great, so then you're looking at it carefully, right? The point is we should try to find the root cause of each crash and mitigate it where appropriate, but in the long run we need ASLR to land and stick.
Comment 36•13 years ago
|
||
Who? Not me. I don't think we understand the crash, so I don't think there is a plan on how to proceed.
Comment 37•13 years ago
|
||
(In reply to Ehsan Akhgari [:ehsan] from comment #32) > I backed it out to see whether it helps with the crashes seen in bug 694344. > > https://hg.mozilla.org/mozilla-central/rev/ddaf5686c70c Alice reports that backing this out solved the crash seen in bug 696806.
Comment 38•13 years ago
|
||
Maybe this was caused by one of the dll's loaded there having a hardcoded location, so therefore to implement mandatory aslr we would need to blacklist one of those dlls.
Comment 39•13 years ago
|
||
This means we should be recommending binary add-on developers to enable ASLR in all of their DLLs to avoid a performance penalty, right?
Keywords: dev-doc-needed
Comment 40•13 years ago
|
||
All binary addon developers should be building with ASLR for security reasons anyway. Even one non-ASLR DLL can compromise Firefox security. I think non-NX/non-ASLR binary extensions shouldn't be allowed on to AMO.
Comment 41•13 years ago
|
||
(In reply to Siddharth Agarwal [:sid0] from comment #40) > All binary addon developers should be building with ASLR for security > reasons anyway. Even one non-ASLR DLL can compromise Firefox security. > > I think non-NX/non-ASLR binary extensions shouldn't be allowed on to AMO. Do you know of any tools that can help us recognize non-NX/non-ASLR binaries?
(In reply to Jorge Villalobos [:jorgev] from comment #41) > (In reply to Siddharth Agarwal [:sid0] from comment #40) > > All binary addon developers should be building with ASLR for security > > reasons anyway. Even one non-ASLR DLL can compromise Firefox security. > > > > I think non-NX/non-ASLR binary extensions shouldn't be allowed on to AMO. > > Do you know of any tools that can help us recognize non-NX/non-ASLR binaries? You should talk to imelven@, he's been working on integrating some binary checking tools into the Firefox build as regression tests that would do this and more.
Comment 43•13 years ago
|
||
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #42) > (In reply to Jorge Villalobos [:jorgev] from comment #41) > > (In reply to Siddharth Agarwal [:sid0] from comment #40) > > > All binary addon developers should be building with ASLR for security > > > reasons anyway. Even one non-ASLR DLL can compromise Firefox security. > > > > > > I think non-NX/non-ASLR binary extensions shouldn't be allowed on to AMO. > > > > Do you know of any tools that can help us recognize non-NX/non-ASLR binaries? > > You should talk to imelven@, he's been working on integrating some binary > checking tools into the Firefox build as regression tests that would do this > and more. Thanks khuey. Jorge, check out bug 642243 (for checking protections on Windows only). Feel free to ping me on irc or email if you want to discuss :)
Comment 44•13 years ago
|
||
I've tried to verify this based on comment 23, comparing the DLLs loaded by Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0a1) Gecko/20110915 Firefox/9.0a1 and Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111122 Firefox/11.0a1. I've attached the files with the DLLs from both versions of Firefox, before and after the patch. I used Process Explorer to list the DLLs and the compare tool from Total Commander to compare the files, and it seems to be a few differences between them. Is this wrong ? Any other suggestions on how to test this ?
Comment 45•13 years ago
|
||
Why would there be any differences relevant to this bug between those two builds? This patch was landed on October 11th, and backed out on October 25th.
Comment 47•13 years ago
|
||
Paul, I think I jumped the gun a bit in instructing SV to test this. I thought a fix for this was going back in this week. However, curious why there was a difference in your findings. However as khuey points out not relevant to this bug. Please hold off testing until the patch is reimplemented. Is there an ETA for re-adding the patch?
Comment 48•13 years ago
|
||
Is this still expected in Firefox 10? Its target milestone is 10 but it appears not to have been fixed yet, so that seems unlikely.
Comment 49•13 years ago
|
||
(In reply to Eric Shepherd [:sheppy] from comment #48) > Is this still expected in Firefox 10? Its target milestone is 10 but it > appears not to have been fixed yet, so that seems unlikely. No, it definitely won't be in 10.
tracking-firefox10:
+ → ---
Target Milestone: mozilla10 → ---
Comment 50•13 years ago
|
||
Have we tried to re-apply the patch since the backout in October? Did we find out why it was causing Firefox on Windows 8 to crash, or if it still is? Thanks!
Comment 51•13 years ago
|
||
(In reply to Tanvi Vyas from comment #50) > Have we tried to re-apply the patch since the backout in October? Did we > find out why it was causing Firefox on Windows 8 to crash, or if it still is? > > Thanks! I haven't tried, no.
Blocks: 728429
Comment 53•13 years ago
|
||
For Win7 and Win8 there is now a way to let the OS enforce this in a way: http://support.microsoft.com/kb/2639308
Comment 54•12 years ago
|
||
I am currently working on a library that can do this and related security features. I want to integrate parts of it into Firefox. (https://github.com/evilpie/harden)
Assignee: nobody → evilpies
Comment 55•12 years ago
|
||
Sorry, I haven't found time to actually figure out the failures yet, because the code we used actually looks fine. Feel free to steal this bug, when you need it.
Comment 57•11 years ago
|
||
Removing qawanted until this gets fixed.
Keywords: qawanted
Whiteboard: [sg:want P1][qa+] → [sg:want P1]
Comment 58•11 years ago
|
||
Windows 8 added a SetProcessMitigationPolicy() API to easily enable the "Force ASLR" feature mentioned in comment 53. With Force ASLR, all DLLs will be loaded using ASLR, even those not built with /DYNAMICBASE. http://blogs.technet.com/b/srd/archive/2013/12/11/software-defense-mitigating-common-exploitation-techniques.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/hh769088%28v=vs.85%29.aspx
I wonder how that works with things like graphics drivers.
Comment 60•11 years ago
|
||
Firefox 31 will be our next ESR and its Nightly release cycle starts next week. If we think this pseudo-ASLR patch can land and stick, Nightly 31 would be a good target release. Also, if we collect telemetry on non-ASLR DLLs seen in the wild, we can reach out to their authors and encourage them to use ASLR.
Comment 61•10 years ago
|
||
I don't think this should be landed for an ESR version but rather just after it (like 32 now) to ensure maximum testing time. Is this on anybody's radar?
Updated•10 years ago
|
![]() |
||
Comment 63•8 years ago
|
||
A note for future archaeology: we used to have the DLL blocklist do an ASLR check on binary XPCOM components. I removed that code in https://hg.mozilla.org/mozilla-central/rev/e46a1e9ecb7a since binary components are going away. Just wanted to leave a pointer here in case we decide to revive that code. (Though, if we do require ASLR one day, I expect that we'll use the process mitigation API via the sandbox, rather than write our own code.)
![]() |
||
Updated•6 years ago
|
Component: Security → Security: Process Sandboxing
Keywords: dev-doc-needed,
sec-want
Whiteboard: [sg:want P1]
![]() |
||
Updated•6 years ago
|
OS: Windows 7 → Windows
![]() |
||
Comment 64•6 years ago
|
||
https://docs.google.com/document/d/1XmPUBksi8xCh39HH7JrxNdh-v9hT1jFqNuGRyO56CLU/edit#heading=h.8drl5667nqgr
Status: NEW → RESOLVED
Closed: 13 years ago → 6 years ago
Resolution: --- → WORKSFORME
Comment 65•6 years ago
|
||
(In reply to Jim Mathies [:jimm] from comment #64) > https://docs.google.com/document/d/1XmPUBksi8xCh39HH7JrxNdh- > v9hT1jFqNuGRyO56CLU/edit#heading=h.8drl5667nqgr Note: This document is inaccessible.
Comment 66•6 years ago
|
||
tjr, can you clarify the resolution? (The document in comment #64 is private, so it doesn't help non-MoCo people understand what's going on. Also, from reading the document, it sounds like this is more WONTFIX than WORKSFORME, but maybe I'm misunderstanding.)
Flags: needinfo?(tom)
Comment 67•6 years ago
|
||
Yea; WONTFIX is more accurate. Currently; all of the dlls we load ourselves are ASLR-enabled. It's possible third party libraries (such as accessibility of GPU drivers) are not. Forcing ASLR (which now can be done with a configuration bit set rather than a patch to occupy the base address) on for these libraries is a compatibility risk. Today, we think the number of thing without ASLR is low, and the number of affected users is also low. So we don't want to risk the compatibility risk.
Flags: needinfo?(tom)
Resolution: WORKSFORME → WONTFIX
![]() |
||
Comment 68•6 years ago
|
||
I'll add that as a safety net we use the binscope tool in such a way that our builds will fail if we accidentally drop/forget the ASLR flag. https://searchfox.org/mozilla-central/rev/3564dfde3b125878dc5a04fe92629fc5195942df/build/win32/autobinscope.py#66 However the checking is currently limited to hand-selected files (https://searchfox.org/mozilla-central/source/build/win32/Makefile.in) -- bug 1412918 will make it apply to all binaries.
You need to log in
before you can comment on or make changes to this bug.
Description
•