Closed
Bug 751585
Opened 13 years ago
Closed 13 years ago
XPCOM component loading is rejected because of either advapi32 or shlwapi in Windows XP dont have ASLR set
Categories
(Core :: Security, defect)
Tracking
()
RESOLVED
FIXED
mozilla15
Tracking | Status | |
---|---|---|
firefox12 | --- | unaffected |
firefox13 | + | verified |
firefox14 | + | fixed |
firefox15 | --- | fixed |
firefox-esr10 | --- | unaffected |
People
(Reporter: moz, Assigned: khuey)
References
Details
(Whiteboard: [qa-])
Attachments
(1 file)
(deleted),
patch
|
benjamin
:
review+
ehsan.akhgari
:
review+
lsblakk
:
approval-mozilla-aurora+
lsblakk
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0 Build ID: 20120425123149 Steps to reproduce: Loading an XPCOM component importing advapi32.dll and shlwapi.dll under Windows XP On Nightly 13.0 2012-05-02-mozilla-beta Does not happen with 12.0 release Actual results: Firefox refuses to load the XPCOM component even with ASLR enabled (/dynamicbase) Only on Windows XP SP3, same works fine on Win 7 (said dlls dont have ASLR enabled in WinXP) LdrLoadDll: Blocking load of 'advapi32.dll'. XPCOM components must support ASLR. or LdrLoadDll: Blocking load of 'shlwapi.dll'. XPCOM components must support ASLR. DllMain() of the XPCOM component is never called Expected results: The component should be loaded. Can't do anything about the windows DLLs
Assignee | ||
Updated•13 years ago
|
Component: Untriaged → Security
Product: Firefox → Core
QA Contact: untriaged → toolkit
Comment 1•13 years ago
|
||
OMG!!! perhaps we should disable this check on XP? Can someone from QA please verify which versions of XP (SP2 and above, x86 and x64) has ASLR enabled on the system DLLs?
Keywords: qawanted
To the uninitiated, how does one check if ASLR is enabled on system DLLs?
Comment 4•13 years ago
|
||
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #2) > To the uninitiated, how does one check if ASLR is enabled on system DLLs? If you have dumpbin (comes with Visual Studio and possible Debugging Tools for Windows) or a similar tool, you can check the PE headers of a DLL (with dumpbin it's dumpbin /HEADERS <dll>) the DYNAMICBASE flag is the one that opts in a DLL to ASLR
Assignee | ||
Comment 5•13 years ago
|
||
Process Explorer is the easiest way for someone without a debugging environment. http://blog.didierstevens.com/2011/01/18/quickpost-checking-aslr/
Comment 6•13 years ago
|
||
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #5) > Process Explorer is the easiest way for someone without a debugging > environment. > > http://blog.didierstevens.com/2011/01/18/quickpost-checking-aslr/ oh awesome - thanks Kyle. I was just looking at Process Explorer and found I could see if ASLR was enabled for a process but not for DLLs - i wouldn't have thought of adding the ASLR column !
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #5) > Process Explorer is the easiest way for someone without a debugging > environment. > > http://blog.didierstevens.com/2011/01/18/quickpost-checking-aslr/ I can't seem to enable the ASLR column, it's greyed out. http://i49.tinypic.com/lv9c1.png
You could also use CFF Explorer from http://www.ntcore.com/exsuite.php Under "Optional Header" click on "Click here" of the "DllCharacteristics" entry and see whether "DLL can move" is checked.
Updated•13 years ago
|
status-firefox13:
--- → affected
tracking-firefox13:
--- → ?
Assignee | ||
Comment 9•13 years ago
|
||
ZeroMemory is a macro, and GetVersionEx is in kernel32, so this is safe to do in LdrLoadDll.
Assignee: nobody → khuey
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #621690 -
Flags: review?(benjamin)
Comment 10•13 years ago
|
||
Comment on attachment 621690 [details] [diff] [review] Patch Ehsan should approve this also.
Attachment #621690 -
Flags: review?(ehsan)
Attachment #621690 -
Flags: review?(benjamin)
Attachment #621690 -
Flags: review+
Updated•13 years ago
|
Attachment #621690 -
Flags: review?(ehsan) → review+
Assignee | ||
Comment 11•13 years ago
|
||
Comment on attachment 621690 [details] [diff] [review] Patch Let's sneak this into b3 so that addon devs can test properly.
Attachment #621690 -
Flags: approval-mozilla-beta?
Attachment #621690 -
Flags: approval-mozilla-aurora?
Assignee | ||
Comment 12•13 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/c24b721ca5c9
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
status-firefox12:
--- → unaffected
status-firefox14:
--- → affected
status-firefox15:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla15
Updated•13 years ago
|
Updated•13 years ago
|
tracking-firefox14:
--- → +
Comment 13•13 years ago
|
||
Kyle had to land a couple follow-ups to fix xpcshell orange. https://hg.mozilla.org/mozilla-central/rev/3e3e37d05c59 https://hg.mozilla.org/mozilla-central/rev/4ea766f922ab
Flags: in-testsuite+
Comment 14•13 years ago
|
||
Comment on attachment 621690 [details] [diff] [review] Patch Approval for landing, let's get this in today for beta 3 go to build
Attachment #621690 -
Flags: approval-mozilla-beta?
Attachment #621690 -
Flags: approval-mozilla-beta+
Attachment #621690 -
Flags: approval-mozilla-aurora?
Attachment #621690 -
Flags: approval-mozilla-aurora+
Assignee | ||
Comment 15•13 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/3005a05986d9 https://hg.mozilla.org/releases/mozilla-beta/rev/aa323b98df36
Comment 16•13 years ago
|
||
(In reply to [Baboo] from comment #8) > You could also use CFF Explorer from http://www.ntcore.com/exsuite.php > Under "Optional Header" click on "Click here" of the "DllCharacteristics" > entry and see whether "DLL can move" is checked. firefox.exe for Firefox 13.0b2 is "DLL can move" CHECKED shlwapi.dll is "DLL can move" UNCHECKED Is this correct? Should I be looking for something else?
Updated•13 years ago
|
Assignee: khuey → nobody
Updated•13 years ago
|
Assignee: nobody → khuey
Comment 17•13 years ago
|
||
Removing qawanted as this now falls into our regular verification work. Can someone please respond to comment 16 and clarify the testcase for our contractors verifying this fix? Thanks
Keywords: qawanted
Comment 18•13 years ago
|
||
In order to verify, we would need a XPCOM component which would load the 2 system files (as in comment 0).
Comment 19•13 years ago
|
||
(In reply to Virgil Dicu [:virgil] [QA] from comment #18) > In order to verify, we would need a XPCOM component which would load the 2 > system files (as in comment 0). Do we know of any add-ons which do this?
Comment 20•13 years ago
|
||
I don't know of any cases, and I think the Add-ons MXR wouldn't help for this.
Comment 21•13 years ago
|
||
in a Windows build, there's objdir-dbg\_tests\xpcshell\xpcom\tests\unit\testcomponent.dll - testcomponent.manifest is in the same dir - but this doesn't use those libraries - it could be modified to load them perhaps ?
Comment 22•12 years ago
|
||
Can the reporter of this bug please help out with the verification? Assuming you can reproduce this bug since you filed it. I think this is beyond what QA can verify in time for release. Thanks a lot.
Whiteboard: [qa+] → [qa-]
Updated•12 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•