751585 - XPCOM component loading is rejected because of either advapi32 or shlwapi in Windows XP dont have ASLR set

Status: RESOLVED FIXED

(Core :: Security, defect)

Description

[moz]

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

Comment 1

[(no longer active)]

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?

Comment 2

[u279076]

To the uninitiated, how does one check if ASLR is enabled on system DLLs?

Comment 3

[u279076]

Adding dependency bug 728429.

Comment 4

[Ian Melven :imelven]

(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

Comment 5

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Process Explorer is the easiest way for someone without a debugging environment.

http://blog.didierstevens.com/2011/01/18/quickpost-checking-aslr/

Comment 6

[Ian Melven :imelven]

(In reply to Kyle Huey [:khuey] ([e-mail]) 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 !

Comment 7

[u279076]

(In reply to Kyle Huey [:khuey] ([e-mail]) 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

Comment 8

[[Baboo]]

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.

Comment 9

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Attachment: Patch

ZeroMemory is a macro, and GetVersionEx is in kernel32, so this is safe to do in LdrLoadDll.

Comment 10

[Benjamin Smedberg]

Comment on attachment 621690 [details] [diff] [review]
Patch

Ehsan should approve this also.

Comment 11

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Comment on attachment 621690 [details] [diff] [review]
Patch

Let's sneak this into b3 so that addon devs can test properly.

Comment 12

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

http://hg.mozilla.org/mozilla-central/rev/c24b721ca5c9

Comment 13

[Ryan VanderMeulen [:RyanVM]]

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

Comment 14

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 621690 [details] [diff] [review]
Patch

Approval for landing, let's get this in today for beta 3 go to build

Comment 15

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/3005a05986d9
https://hg.mozilla.org/releases/mozilla-beta/rev/aa323b98df36

Comment 16

[u279076]

(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?

Comment 17

[u279076]

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

Comment 18

[Virgil Dicu [:virgil] [QA]]

In order to verify, we would need a XPCOM component which would load the 2 system files (as in comment 0).

Comment 19

[u279076]

(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

[Jorge Villalobos [:jorgev] (he/him)]

I don't know of any cases, and I think the Add-ons MXR wouldn't help for this.

Comment 21

[Ian Melven :imelven]

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

[u279076]

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.

Comment 23

[moz]

Works with Firefox 13b6 (XP SP3, Win7 SP1). Thanks guys.