Closed Bug 811557 Opened 12 years ago Closed 11 years ago

DLL Hijacking - Firefox Stub installer

Categories

(Firefox :: Installer, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla24
Tracking Status
firefox16 - wontfix
firefox17 --- wontfix
firefox18 --- wontfix
firefox19 --- wontfix
firefox20 + wontfix
firefox21 + wontfix
firefox22 + verified
firefox23 + verified
firefox24 + verified
firefox-esr10 --- unaffected
firefox-esr17 --- unaffected
b2g18 --- unaffected

People

(Reporter: bbondy, Assigned: robert.strong.bugs)

References

Details

(Keywords: csectype-priv-escalation, sec-high, verifyme, Whiteboard: [stub?][adv-main22-])

Attachments

(2 files, 1 obsolete file)

+++ This bug was initially created as a clone of Bug #792106 +++

This bug is to fix the stub installer.  
A problem with this is that the below DLLs are loaded before the NSIS .onInit is called.

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #141)
> Some results from testing last week. The following DLLs were found to have
> launched cmd.exe processes and are not listed as Known DLLs using the WinObj
> tool.
> 
> Win32 Stub Installer
>  * cabinet.dll: Windows 7 64-bit, Windows 7 32-bit, Windows Vista 32-bit
>  * credssp.dll: Windows Vista 32-bit
>  * cryptbase.dll: Windows 7 32-bit
>  * cryptnet.dll: Windows 7 32-bit, Windows 7 64-bit
>  * cryptsp.dll: Windows 7 32-bit, Windows 7 64-bit, Windows Vista 32-bit
>  * devrtl.dll: Windows 7 32-bit, Windows 7 64-bit
>  * dnsapi.dll: Windows 7 32-bit, Windows 7 64-bit, Windows Vista 32-bit
>  * dwmapi.dll: Windows 7 64-bit
>  * gpapi.dll: Windows 7 32-bit, Windows 7 64-bit, Windows Vista 32-bit
>  * IPHLPAPI.dll: Windows 7 32-bit, Windows 7 64-bit, Windows Vista 32-bit
>  * linkinfo.dll: Windows Vista 32-bit
>  * ncrypt.dll: Windows 7 32-bit, Windows 7 64-bit, Windows Vista 32-bit
>  * netapi32.dll: Windows Vista 32-bit
>  * ntmarta.dll: Windows 7 64-bit, Windows Vista 32-bit
>  * ntshrui.dll: Windows Vista 32-bit
>  * profapi.dll: Windows 7 32-bit, Windows 7 64-bit
>  * propsys.dll: Windows Vista 32-bit
>  * rasadhlp.dll: Windows 7 32-bit, Windows 7 64-bit, Windows Vista 32-bit
>  * rasapi32.dll: Windows 7 64-bit, Windows Vista 32-bit
>  * riched20.dll: Windows 7 32-bit, Windows 7 64-bit, Windows Vista 32-bit
>  * RpcRtRemote.dll: Windows 7 64-bit, Windows Vista 32-bit
>  * rtutils.dll: Windows 7 32-bit, Windows 7 64-bit
>  * secur32.dll: Windows 7 32-bit, Windows 7 64-bit, Windows Vista 32-bit
>  * SensApi.dll: Windows 7 32-bit, Windows 7 64-bit, Windows Vista 32-bit
>  * shfolder.dll: Windows 7 64-bit, Windows Vista 32-bit
>  * SLC.dll: Windows Vista 32-bit
>  * userenv.dll: Windows 7 32-bit, Windows 7 64-bit
>  * uxtheme.dll: Windows Vista 32-bit
> 
> Keep in mind that we are only a third of the way through testing. Though I
> suspect we've caught the lion's share of DLLs already (at least one would
> hope).
> 
> Full results are being added here as we test:
> https://intranet.mozilla.org/User:Ahughes@mozilla.com/DLL_Hijacking
So I think either a patch to makensis itself or add code to:
toolkit/mozapps/installer/windows/nsis/makensis.mk
which wraps the stub in a 7zip self extracting archive and then put extra fixes into the 7zip Main.
Patch NSIS and upstream.
We'll have to update all of our talos builders, is that OK?  Or maybe we could just add makensis itself as a binary to the tree?
It is ok to update our build system as we did when we had to for NSIS 2.46. Let's talk about adding makensis to the tree though I must say that I am not leaning in that direction atm. If we were to add it then I would also say that we should add many other build tools that are currently in MozillaBuild.
OK so we can build 2.46 with scons and VS2005. Should we track the source code in mozilla-build? Or only upstream the patch and use our own build?  Maybe just zip up the changed source code to this ticket after?
Tracking for FF18, in case we actually hit this release with the stub installer.
It is extremely unlikely we are going to have this fixed for 18 or 19 due to other work. If this is considered a high priority please let me know and we'll evaluate this work with other work in progress.
I believe QA has done all the testing required for the time being so I'm removing the qawanted/verifyme keywords. Please re-add if/when there is more needed from us.
Keywords: qawanted, verifyme
Has QA verified that the problems are fixed on the mentioned branches? It would be good to go over the affected DLLs only, not on every affected platform, but just one platform per affected DLL where the issue could be reproduced before.
I don't see that this has been fixed anywhere yet. Please let me know where this has been fixed so I can test those installers.
My bad I thought this was the original installer bug.
(In reply to Alex Keybl [:akeybl] from comment #6)
> Tracking for FF18, in case we actually hit this release with the stub
> installer.

We'll leave this on the tracking FF18 list as a reminder in case we do end up shipping the stub installer in the FF18 timeframe. We could always just re-spin the stub installer if necessary.
(In reply to Brian R. Bondy [:bbondy] from comment #11)
> My bad I thought this was the original installer bug.

Any updates here? It doesn't look like we'll have a stub in time for FF19, but it's possible that we'll want to push it out while FF19 is on release (needinfo:rstrong to confirm timelines). If so, we should get a fix on all branches soon.
Flags: needinfo?(robert.bugzilla)
No updates at this time. We could possibly wrap the stub inside of a 7-zip self-extracting archive to get a temporary fix with the real fix being what is noted in comment #2 through comment #4 though there is other work that would not get done if we do fix this. I think it would be a good thing to evaluate that fact along with the fact that there have been a ton of NSIS installers out in the world for many years that all have this potential vulnerability without it being exploited.
Flags: needinfo?(robert.bugzilla)
quick update: I'm working on this again but am having trouble getting NSIS to build. The problem is because SCONS is picking up newer MSVC versions I have installed as well. I tried configuring it but without success. I'm setting up a new WinXP VM now in which I'll re-install only the tools for NSIS and I expect that will compile fine.
bbondy and I discussed bug 744669 yesterday and concluded that to properly fix bug 744669 the need for the 7-Zip self extracting archive should be removed and the files should be packaged in the installer itself. If this was done then this would reintroduce the dll hijacking bug to the regular installer. So, this bug will need to be fixed to fix bug 744669 by patching NSIS which will fix dll hijacking for both the complete and the stub installers.
I built nsis-u successfully by modifying some of the scripts to force include, lib and rc directories.

But I'm getting some strange side effects after I build the installer with the new makensis and run the installer.

After zip extracts the exe it gives a infinite loop of:
Copying 1 file from nsa440B.tmp to 7zSD6a.tmp
The destination already has a file named "System.dll"
()Replace the file in the destination
()Skip this file
() Compare info for both files

I'll play around with it more to try to build with different include/lib directories but just wanted to provide an interim update.
Summary so far:

So the 2005 toolchain is for the official NSIS version here:
http://nsis.sourceforge.net/
To build this you can't have 2008 toolchain installed or else the old scons that it requires will fail.

Later I found out what I really need is here:
http://www.scratchpaper.com/
To build this you have to use 2008 or later. 
I built makensis successfully with 2008, 2010, and 2012 toolsets.
Each one produces a Firefox installer and looks correct but they fail with either a crash when you start the installer or else the issue mentioned in Comment 17.

I need to investigate why it's crashing or getting the above error more still.
Whiteboard: [leave open] → [leave open][stub?]
Not currently working on this one and I have some other security ones I'll be doing before this.  Last time I worked on this I successfully built NSIS as per Comment 18 toolsets.  But the produced installers crashed on startup.  In hindsight it was probably due to a loaded plugin on startup.  I didn't have time to investigate the crash at all.
Assignee: netzen → nobody
Taking a look to see if I have any better luck
QA Contact: robert.bugzilla
Assignee: nobody → robert.bugzilla
QA Contact: robert.bugzilla
Attached file Stub for testing —
:ashughes, could you run the attached "Stub for testing" through the test suite?
https://intranet.mozilla.org/User:Ahughes@mozilla.com/DLL_Hijacking#Firefox_19.0a1_win32_Stub_Installer

This passed on Win7 but I wouldn't be surprised if there are some one-offs that still fail. Thanks!
Flags: needinfo?(anthony.s.hughes)
(In reply to Robert Strong [:rstrong] (do not email) from comment #22)
> :ashughes, could you run the attached "Stub for testing" through the test
> suite?
> https://intranet.mozilla.org/User:Ahughes@mozilla.com/
> DLL_Hijacking#Firefox_19.0a1_win32_Stub_Installer
> 
> This passed on Win7 but I wouldn't be surprised if there are some one-offs
> that still fail. Thanks!

I won't have time to look at this for at least a couple of weeks. Matt can you please handle Robert's request? I think Kamil could probably assist.
Flags: needinfo?(anthony.s.hughes) → needinfo?(mwobensmith)
Robert did you want me to review the code change first? I know it's not part of Mozilla code but it may be useful to have a second set of eyes on the change anyway.  Testing this takes a non trivial amount of time.
(In reply to Brian R. Bondy [:bbondy] from comment #24)
> Robert did you want me to review the code change first? I know it's not part
> of Mozilla code but it may be useful to have a second set of eyes on the
> change anyway.  Testing this takes a non trivial amount of time.
No, I took a different approach that preloads the dlls that NSIS loads early (only 3 so far vs. the 20) and preloads the others in .oninit in the hope that I can get this upstreamed easily. I need to know if others are needed for other Windows versions besides Windows 7 and the testing will provide that info.
I have Win7 and Vista systems so I can check those (already did a brief check of Win7) fairly easily.
Hey Robert, Kamil was going to start on this, but before he does I just wanted to see if you wanted to wait for the 7zip stub implementation we discussed instead?
Hey Brian, I would still like to know if it fixes it for those Windows versions since it might be a good idea to get a fix upstreamed for NSIS as well.
nightly stub installer sizes
631 KB - current local build
665 KB - wrapped in 7zip stub with NSIS compression (34 KB more)
656 KB - wrapped in 7zip stub without NSIS compression (25 KB more)
656 KB - wrapped in 7zip stub without NSIS compression and bmps inside of 7zip
         stub instead of the stub installer (25 KB more)

The reason for the last test is that we have been asked to include the artwork outside of the installer for distributions.

Note: I would still like the info requested in comment #22... if this is important to us it should be important to others and it is a good thing to give back to the project that has been providing to us.
Attached patch patch rev1 (obsolete) — — Splinter Review
Brian, I'd like to run this by you first. Thanks!
Attachment #757779 - Flags: review?(netzen)
(In reply to Robert Strong [:rstrong] (do not email) from comment #30)
> Created attachment 757779 [details] [diff] [review]
> patch rev1
> 
> Brian, I'd like to run this by you first. Thanks!
I am going to refactor the toolkit nsis make code a little and I mainly want your r+ for the browser nsis code.
Comment on attachment 757779 [details] [diff] [review]
patch rev1

Review of attachment 757779 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good but I'll leave it to your discretion whether or not you want someone from build config to also take a look.
Attachment #757779 - Flags: review?(netzen) → review+
Attached patch patch rev2 — — Splinter Review
Brian, since glandium is high latency atm could you review the changes to the build process. I was able to take a much cleaner and safer approach.
Attachment #757779 - Attachment is obsolete: true
Attachment #758155 - Flags: review?(netzen)
Attachment #758155 - Flags: review?(netzen) → review+
Comment on attachment 758155 [details] [diff] [review]
patch rev2

[Security approval request comment]
How easily could an exploit be constructed based on the patch? Not easily and less easily from code inspection from the landing of bug 792106.

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem? No

Which older supported branches are affected by this flaw? This affects all NSIS installers. This mitigates this bug by wrapping the stub installer in our custom 7-Zip stub which also had the same flaw and has been patched.

If not all supported branches, which bug introduced the flaw? bug 322206

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be? This is easily backported.

How likely is this patch to cause regressions; how much testing does it need? Unlikely since we have been doing the same thing with the full installer.
Attachment #758155 - Flags: sec-approval?
Comment on attachment 758155 [details] [diff] [review]
patch rev2

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 322206
User impact if declined: potential security exploit
Testing completed (on m-c, etc.): We use this same method with the full installer and I have tested locally
Risk to taking this patch (and alternatives if risky): minimal
String or IDL/UUID changes made by this patch: none
Attachment #758155 - Flags: approval-mozilla-beta?
Attachment #758155 - Flags: approval-mozilla-aurora?
Comment on attachment 758155 [details] [diff] [review]
patch rev2

sec-approval+ for trunk. Please nominate for branches once it is in.
Attachment #758155 - Flags: sec-approval? → sec-approval+
https://hg.mozilla.org/mozilla-central/rev/642a020ef752
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
Whiteboard: [leave open][stub?] → [stub?]
No longer blocks: 804979, 803515, 805032, 811227
The current nightly has the stub installer wrapped by the 7-Zip stub just like the full installer so this can be verified.
Keywords: verifyme
I also checked that everything is signed correctly for en-US and de so l10n appears to be building correctly.
Attachment #758155 - Flags: approval-mozilla-beta?
Attachment #758155 - Flags: approval-mozilla-beta+
Attachment #758155 - Flags: approval-mozilla-aurora?
Attachment #758155 - Flags: approval-mozilla-aurora+
Firefox 24 Testing/Verification Results:

Steps Used:

- Downloaded the latest stub executable & renamed it to stub.exe
- Configured procmon as follows:

Process Name is stub.exe
Path contains .dll
Operation is Load Image

Matched the listed DLL's in procmon against the KnownDlls32 list under Winobj. Listed the unknown DLL's below.

Reproduced original issue using the stub executable from the following build:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/11/2012-11-07-04-58-42-mozilla-central/

Tested the issue using the stub executable from the following build:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-06-13-03-12-37-mozilla-central/

Windows 8 x64:

C:\Windows\System32\wow64.dll -> Passed (cmd.exe was not executed)
C:\Windows\System32\wow64win.dll -> Passed (cmd.exe was not executed)
C:\Windows\System32\wow64cpu.dll -> Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\dwmapi.dll -> Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\SHCore.dll -> Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\uxtheme.dll -> Passed (cmd.exe was not executed)
C:\Program Files (x86)\Common Files\Microsoft Shared\Ink\tiptsf.dll -> Passed (cmd.exe was not executed)
C:\Program Files\ThinkPad\Bluetooth Software\syswow64\BtMmHook.dll -> Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\oleacc.dll -> cmd.exe was launched in MEDIUM integrity
C:\Windows\SysWOW64\apphelp.dll -> Passed (cmd.exe was not executed)

Windows 7 Home Premium SP1 x64:

C:\Windows\System32\wow64.dll <- Passed (cmd.exe was not executed)
C:\Windows\System32\wow64win.dll <- Passed (cmd.exe was not executed)
C:\Windows\System32\wow64cpu.dll <- Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\dwmapi.dll <- Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\uxtheme.dll <- Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\apphelp.dll <- Passed (cmd.exe was not executed)

Windows Vista Ultimate SP2 x64:

C:\Windows\System32\ntdll.dll <- Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\ntdll.dll <- Passed (cmd.exe was not executed)
C:\Windows\System32\wow64.dll <- Passed (cmd.exe was not executed)
C:\Windows\System32\wow64win.dll <- Passed (cmd.exe was not executed)
C:\Windows\System32\wow64cpu.dll <- Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\dwmapi.dll <- Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\uxtheme.dll <- Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\apphelp.dll <- Passed (cmd.exe was not executed)

Windows XP Pro SP2 x64:

C:\WINDOWS\system32\wow64.dll <- Passed (cmd.exe was not executed)
C:\WINDOWS\system32\wow64win.dll <- Passed (cmd.exe was not executed)
C:\WINDOWS\system32\wow64cpu.dll <- Passed (cmd.exe was not executed)
C:\WINDOWS\SysWOW64\imm32.dll <- Passed (cmd.exe was not executed)
C:\WINDOWS\SysWOW64\uxtheme.dll <- Passed (cmd.exe was not executed)
C:\WINDOWS\SysWOW64\msctf.dll <- Passed (cmd.exe was not executed)
C:\WINDOWS\SysWOW64\apphelp.dll <- Several CMD.EXE where launched (not sure what integrity level)

Possible Issues:

Windows 8 x64:
C:\Windows\SysWOW64\oleacc.dll -> cmd.exe was launched in MEDIUM integrity

Windows XP Pro SP2 x64:
C:\WINDOWS\SysWOW64\apphelp.dll <- Several CMD.EXE where launched (not sure what integrity level)

Before verifying Firefox 24, could someone please double check and see if the two DLL's listed above are possible issues.
Firefox 23 Testing/Verification Results:

Steps Used:

- Downloaded the latest stub executable & renamed it to stub.exe
- Configured procmon as follows:

Process Name is stub.exe
Path contains .dll
Operation is Load Image

Matched the listed DLL's in procmon against the KnownDlls32 list under Winobj. Listed the unknown DLL's below

Tested the issue using the stub executable from the following build:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-06-13-00-40-19-mozilla-aurora/

Windows 8 x64:

C:\Windows\System32\wow64.dll <- Passed (cmd.exe was not executed)
C:\Windows\System32\wow64win.dll <- Passed (cmd.exe was not executed)
C:\Windows\System32\wow64cpu.dll <- Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\apphelp.dll <- Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\dwmapi.dll <- Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\SHCore.dll <- Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\uxtheme.dll <- Passed (cmd.exe was not executed)
C:\Program Files (x86)\Common Files\Microsoft Shared\Ink\tiptsf.dll <- Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\oleacc.dll <- CMD.EXE was launched in MEDIUM integrity

Windows 7 Home Premium SP1 x64:

C:\Windows\System32\wow64.dll <- Passed (cmd.exe was not executed)
C:\Windows\System32\wow64win.dll <- Passed (cmd.exe was not executed)
C:\Windows\System32\wow64cpu.dll <- Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\dwmapi.dll <- Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\uxtheme.dll <- Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\apphelp.dll <- Passed (cmd.exe was not executed)

Windows Vista Ultimate SP2 x64:

C:\Windows\System32\ntdll.dll <- Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\ntdll.dll <- Passed (cmd.exe was not executed)
C:\Windows\System32\wow64.dll <- Passed (cmd.exe was not executed)
C:\Windows\System32\wow64win.dll <- Passed (cmd.exe was not executed)
C:\Windows\System32\wow64cpu.dll <- Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\dwmapi.dll <- Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\uxtheme.dll <- Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\apphelp.dll <- Passed (cmd.exe was not executed)

Windows XP Pro SP2 x64:

C:\WINDOWS\system32\wow64.dll <- Passed (cmd.exe was not executed)
C:\WINDOWS\system32\wow64win.dll <- Passed (cmd.exe was not executed)
C:\WINDOWS\system32\wow64cpu.dll <- Passed (cmd.exe was not executed)
C:\WINDOWS\SysWOW64\imm32.dll <- Passed (cmd.exe was not executed)
C:\WINDOWS\SysWOW64\uxtheme.dll <- Passed (cmd.exe was not executed)
C:\WINDOWS\SysWOW64\msctf.dll <- Passed (cmd.exe was not executed)
C:\WINDOWS\SysWOW64\apphelp.dll <- Several CMD.EXE where launched (not sure what integrity level)

Possible Issues:

Windows 8 x64:
C:\Windows\SysWOW64\oleacc.dll <- CMD.EXE was launched in MEDIUM integrity

Windows XP Pro SP2 x64:
C:\WINDOWS\SysWOW64\apphelp.dll <- Several CMD.EXE where launched (not sure what integrity level)

Before verifying Firefox 23, could someone please double check and see if the two DLL's listed above are possible issues.
I won't be able to check due to only having Win Vista and Win 7 at this time.

Brian, could you check the above two dll's?
Flags: needinfo?(netzen)
Firefox 22 Testing/Verification Results:

Steps Used:

- Downloaded the latest stub executable & renamed it to stub.exe
- Configured procmon as follows:

Process Name is stub.exe
Path contains .dll
Operation is Load Image

Matched the listed DLL's in procmon against the KnownDlls32 list under Winobj. Listed the unknown DLL's below

Tested the issue using the stub executable from the following build:
http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/22.0b5/win32/en-US/

Windows 8 x64:

C:\Windows\System32\wow64.dll <- Passed (cmd.exe was not executed)
C:\Windows\System32\wow64win.dll <- Passed (cmd.exe was not executed)
C:\Windows\System32\wow64cpu.dll <- Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\apphelp.dll <- Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\dwmapi.dll <- Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\SHCore.dll <- Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\uxtheme.dll <- Passed (cmd.exe was not executed)
C:\Program Files (x86)\Common Files\Microsoft Shared\Ink\tiptsf.dll <- Passed (cmd.exe was not executed)
C:\Program Files\ThinkPad\Bluetooth Software\syswow64\BtMmHook.dll <- Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\oleacc.dll <- CMD.EXE was launched in MEDIUM integrity

Windows 7 Home Premium SP1 x64:

C:\Windows\System32\wow64.dll <- Passed (cmd.exe was not executed)
C:\Windows\System32\wow64win.dll <- Passed (cmd.exe was not executed)
C:\Windows\System32\wow64cpu.dll <- Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\dwmapi.dll <- Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\uxtheme.dll <- Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\apphelp.dll <- Passed (cmd.exe was not executed)

Windows Vista Ultimate SP2 x64:

C:\Windows\System32\ntdll.dll <- Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\ntdll.dll <- Passed (cmd.exe was not executed)
C:\Windows\System32\wow64.dll <- Passed (cmd.exe was not executed)
C:\Windows\System32\wow64win.dll <- Passed (cmd.exe was not executed)
C:\Windows\System32\wow64cpu.dll <- Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\dwmapi.dll <- Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\uxtheme.dll <- Passed (cmd.exe was not executed)
C:\Windows\SysWOW64\apphelp.dll <- Passed (cmd.exe was not executed)


Windows XP Pro SP2 x64:

C:\Windows\System32\wow64.dll <- Passed (cmd.exe was not executed)
C:\Windows\System32\wow64win.dll <- Passed (cmd.exe was not executed)
C:\Windows\System32\wow64cpu.dll <- Passed (cmd.exe was not executed)
C:\WINDOWS\SysWOW64\imm32.dll <- Passed (cmd.exe was not executed)
C:\WINDOWS\SysWOW64\uxtheme.dll <- Passed (cmd.exe was not executed)
C:\WINDOWS\SysWOW64\msctf.dll <- Passed (cmd.exe was not executed)
C:\WINDOWS\SysWOW64\apphelp.dll <- Several CMD.EXE where launched (not sure what integrity level)

Possible Issues:

Windows 8 x64:
C:\Windows\SysWOW64\oleacc.dll <- CMD.EXE was launched in MEDIUM integrity

Windows XP Pro SP2 x64:
C:\WINDOWS\SysWOW64\apphelp.dll <- Several CMD.EXE where launched (not sure what integrity level)

Before verifying Firefox 22, could someone please double check and see if the two DLL's listed above are possible issues.
(In reply to Robert Strong [:rstrong] (do not email) from comment #44)
> I won't be able to check due to only having Win Vista and Win 7 at this time.
> 
> Brian, could you check the above two dll's?

I reproduced medium integrity level with oleacc.dll on win8x64. This is not an easy to exploit escalation of privs problem, but we should still fix for these 2 cases:
i) User downloads a bad dll into their downloads directory, and then downloads the stub, then executes the stub.  The dll can then run on the machine with medium integrity. Which isn't as bad as high, but is at least something.
ii) The user downloads the stub and right clicks it and runs it as admin, or runs it from an elevated cmd.  The dll then gets high integirty.

The same logic applies to apphelp.dll, although I didn't verify this one because I don't have WinXPx64 locally here. There's no per-user integrity level on XP like there is on Vista+ so I trust this result. 

I think both should be fixed in the delayDLLs array of the  AutoLoadSystemDependencies struct in this file:
other-licenses/7zstub/src/7zip/Bundles/SFXSetup-moz/Main.cpp

---

After this fix, Kamil you can only retest the affected platforms and DLLs, you don't need to retry everything. Thanks for the huge amount of work by the way!
Flags: needinfo?(netzen)
See bug 792106 for a similar fix.
no problem Brian! Robert, just needinfo me when its ready to go again and I will test the two DLL's on the affected platforms.
Brian, do those dll's also affect the full installer? I would suspect so.
Flags: needinfo?(netzen)
The win8 one is yup, the x64xp one I don't have it locally to try but I'm sure it's the same too.

I think originally we were just fixing the high integrity processes but then we learnt that it can be a security risk if a user downloads a dll off the internet and then downloads an installer and executes it. I personally don't think sec-high but worth fixing.
Flags: needinfo?(netzen)
Thanks Brian! With this affecting both the full installer and the stub installer I'd like to do those in a separate bug.

Thanks Kamil! I know the test matrix to verify this is a pain and your efforts are much appreciated.
Followup for the dll pre-loading from a known path sounds right to me.
This is as fixed as much as bug 792106 is fixed per the checks Kamil performed so changing to verified based on comment #42, comment #43, and comment #45. Bug 883165 will handle the medium integrity dll's.
Blocks: 883322
Whiteboard: [stub?] → [stub?][adv-main22-]
Hey Kamil, comment 46 and comment 48 - can you do a quick verify?
Flags: needinfo?(mwobensmith) → needinfo?(kamiljoz)
Matt, the medium integrity case referenced in comment #46 and comment #48 was moved to bug 883165.
Flags: needinfo?(kamiljoz)
Indeed, thanks Robert, and sorry for spacing that. Too much info spread across too many DLL bugs. :(
Group: core-security
Component: NSIS Installer → Installer
Product: Toolkit → Firefox
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: