861012 - Firefox installer will pre-load DLLs in same directory

Status: RESOLVED DUPLICATE of bug 1361326

(Firefox :: Installer, defect)

Comment 1

[Al Billings [:abillings - ex-MoCo]]

Hmm... maybe the same as bug 811557?

Comment 2

[Brian R. Bondy [:bbondy]]

Sounds like this is the installer and not the stub installer. 
The installer was checked already but perhaps something was missed.

What he mentions above though is for "Query Information", which is not "Load Image". So this doesn't sound like an issue to me, but I haven't tried it.

Note that we have known dll issues with our stub installer. There's a bug still pending for stub installer but it requires a rebuild of NSIS and I had problems with the installers I produced with my build of makensis.

CCing Kamil, can you try with the installer and the dlls mentioned when you have time?

Comment 3

[Kamil Jozwiak [:kjozwiak]]

Brian, sure! I will take a look at it sometime this week

Comment 4

[Al Billings [:abillings - ex-MoCo]]

Adding the reporter to the bug.

Comment 5

[Daniel Veditz [:dveditz]]

I sort of confirmed this, but was using the stub installer that apparently we already knew was a problem. I thought the NSIS part was the same on both though.

Comment 6

[Kamil Jozwiak [:kjozwiak]]

Hi Haifei,

Couldn't reproduce the issue using the steps provided in Comment 0. Tried using several existing PoC that where created for similar issues but couldn't reproduce the original issue.

Haifei, would you be able to post a PoC (Proof of Concept) that can elevate calc.exe or cmd.exe using the method described in Comment 0?

Comment 7

[haifei.van]

(In reply to Kamil Jozwiak [:kjozwiak] from comment #6)
> Hi Haifei,
> 
> Couldn't reproduce the issue using the steps provided in Comment 0. Tried
> using several existing PoC that where created for similar issues but
> couldn't reproduce the original issue.
> 
> Haifei, would you be able to post a PoC (Proof of Concept) that can elevate
> calc.exe or cmd.exe using the method described in Comment 0?

Hi Kamil,

I just tested it again. I tested it successfully (by using the faked dll name "LPK.DLL") on a latest Windows XP SP3 but wasn't able to reproduce on a Win7. I guess there are some OS-based changes in Win7 but I don't have time to go deep and figure out why. That said, it's confirmed at least on Windows XP SP3.

Let me know if you have future questions.

Thanks,
Haifei

Comment 8

[haifei.van]

ATTENTION, please don't disclose the thread in the public when in future you want to, unless you remove my personal email address from the thread:) Thanks for the understanding.

Comment 9

[Kamil Jozwiak [:kjozwiak]]

Went through the following steps for each of the environments listed below:

Used the following build:

http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/20.0.1/win32/en-US/

- Downloaded Firefox Setup 20.0.1.exe and placed it into a folder named "firefoxtest" on the C:\
- Downloaded a POC from Bug 830134 and two other POC's from Bug 859072 (will launch calc.exe and cmd.exe in high integrity)
- Renamed each POC DLL to USP10.DLL & LPK.DLL and placed them into the "firefoxtest" folder along side "Firefox Setup 20.0.1.exe" (using each of the 3 POC's one by one)
- Launched the .EXE with Process Explorer running (ensuring nothing out of the ordinary is spawned including cmd.exe and calc.exe)

Environments Tested:

- Windows XP Pro SP3 x86 - Couldn't reproduce using all threePOC DLL's
- Windows XP Pro SP2 x64 - Couldn't reproduce using all three POC DLL's
- Windows Vista Ultimate SP2 x86 - Couldn't reproduce using all three POC DLL's
- Windows Vista Ultimate SP2 x64 - Couldn't reproduce using all three POC DLL's
- Windows 7 Home Premium x86 - Couldn't reproduce using all three POC DLL's
- Windows 7 Home Premium SP1 x64 - Couldn't reproduce using all three POC DLL's
- Windows 8 x86 - (launched OpenWith.exe but didn't spawn calc.exe or cmd.exe)
- Windows 8 x64 - (launched OpenWith.exe but didn't spawn calc.exe or cmd.exe)

Haifei,

Would you be able list the exact steps you are using to produce this issue? Are you creating a blank DLL and just renaming it or are you using a specific DLL?

Comment 10

[haifei.van]

(In reply to Kamil Jozwiak [:kjozwiak] from comment #9)
> Went through the following steps for each of the environments listed below:
> 
> Used the following build:
> 
> http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/20.0.1/win32/en-US/
> 
> - Downloaded Firefox Setup 20.0.1.exe and placed it into a folder named
> "firefoxtest" on the C:\
> - Downloaded a POC from Bug 830134 and two other POC's from Bug 859072 (will
> launch calc.exe and cmd.exe in high integrity)
> - Renamed each POC DLL to USP10.DLL & LPK.DLL and placed them into the
> "firefoxtest" folder along side "Firefox Setup 20.0.1.exe" (using each of
> the 3 POC's one by one)
> - Launched the .EXE with Process Explorer running (ensuring nothing out of
> the ordinary is spawned including cmd.exe and calc.exe)
> 
> Environments Tested:
> 
> - Windows XP Pro SP3 x86 - Couldn't reproduce using all threePOC DLL's
> - Windows XP Pro SP2 x64 - Couldn't reproduce using all three POC DLL's
> - Windows Vista Ultimate SP2 x86 - Couldn't reproduce using all three POC
> DLL's
> - Windows Vista Ultimate SP2 x64 - Couldn't reproduce using all three POC
> DLL's
> - Windows 7 Home Premium x86 - Couldn't reproduce using all three POC DLL's
> - Windows 7 Home Premium SP1 x64 - Couldn't reproduce using all three POC
> DLL's
> - Windows 8 x86 - (launched OpenWith.exe but didn't spawn calc.exe or
> cmd.exe)
> - Windows 8 x64 - (launched OpenWith.exe but didn't spawn calc.exe or
> cmd.exe)
> 
> Haifei,
> 
> Would you be able list the exact steps you are using to produce this issue?
> Are you creating a blank DLL and just renaming it or are you using a
> specific DLL?

Hi,

This is kinda strange.. Would you like to try a non-English version of Windows XP SP3 x86? Since I tried it successfully on a Chinese version, I'd guess the language is the cause. Unfortunately I don't have time to do it myself right now.

Let me know if you are still not able to reproduce it. Thanks.

Thanks,
Haifei

Comment 11

[Brian R. Bondy [:bbondy]]

Haifei could you describe the specific attack that you are exploiting? Are you launching your own code from DLL that's placed in the same directory?  In Comment 0 I see that it queried information on a DLL but I did not see any indication that it was actually loading that DLL.

It looks as though Kamil tried 8 different OS with several different DLL PoCs from diferent bugs, and couldn't reproduce.

Comment 12

[haifei.van]

(In reply to Brian R. Bondy [:bbondy] from comment #11)
> Haifei could you describe the specific attack that you are exploiting? Are
> you launching your own code from DLL that's placed in the same directory? 
> In Comment 0 I see that it queried information on a DLL but I did not see
> any indication that it was actually loading that DLL.
> 
> It looks as though Kamil tried 8 different OS with several different DLL
> PoCs from diferent bugs, and couldn't reproduce.

Yes, it's a simple dll-preloading condition. Maybe I'd better provide you the PoC files I used directly.

Please download the "Firefox Setup 20.0.1.exe" and the fake "LPK.DLL" binaries here https://dl.dropboxusercontent.com/u/14747595/firefox_dll_preloading.zip. Use the password "infected" for the zip.

If you can't reproduce it on English version Windows XP SP3 (full-update), please find a non-English version and try again.

Thanks,
Haifei

Comment 13

[Brian R. Bondy [:bbondy]]

does it allow a limited user account to get admin access?
In Vista and above I can see a low integrity process gaining access to high integrity, but I think in the XP case it just runs at the same level of any other process.

I.e. if there is malware on your system that can copy a dll, your system is already owned.

Comment 14

[haifei.van]

(In reply to Brian R. Bondy [:bbondy] from comment #13)
> does it allow a limited user account to get admin access?
> In Vista and above I can see a low integrity process gaining access to high
> integrity, but I think in the XP case it just runs at the same level of any
> other process.
> 
> I.e. if there is malware on your system that can copy a dll, your system is
> already owned.

I already discussed the question in my original report:

--
Considering this scenario, the "hacker" may put the "Firefox Steup" file and the malicious DLLs in the same directory and that will trigger the malicious code execution when the victim actually run the trustworthy "Firefox Setup 20.0.1.exe" which is released and signed by Mozilla. You trust Mozilla, but you also got pwned?
--

The question is that the bad guys can put a lot of files including a malicious "LPK.DLL" as well as an official "Firefox Setup 20.0.1.exe" in the same directory (they may pack them into a zip file and send it to the victim), usually ppl only check if the .EXE is signed or not. In this situation, the victim checks the "Firefox Setup 20.0.1.exe" and find it's an official release, so he/she trusts it and execute it, but he/she gets pwned.

The above attacking can be performed by sending the whole directory to the victim, or through a SMB share. Even, I guess it can also be performed via WEBDAV from remote server, however I didn't test.

Brian, the case is very similar as the well-known "file-opening-based" dll-preloading vulnerability class, try Google if you are not familar on this.

Thanks,
Haifei

Comment 15

[Brian R. Bondy [:bbondy]]

(In reply to haifei.van from comment #14)
> (In reply to Brian R. Bondy [:bbondy] from comment #13)
> I already discussed the question in my original report:
> 
> --
> Considering this scenario, the "hacker" may put the "Firefox Steup" file and
> the malicious DLLs in the same directory and that will trigger the malicious
> code execution when the victim actually run the trustworthy "Firefox Setup
> 20.0.1.exe" which is released and signed by Mozilla. You trust Mozilla, but
> you also got pwned?
> --
> ...

Sorry I'm still not personally certain this is an exploit.  If the process can put a DLL next to the installer on Windows XP, then it already can own the system including installing root fake cert authorities which they used to make their own duplicate Mozilla signed cert.  On Vista and above I can see this as being an issue because a low integrity process can gain high integrity through this same means. 

I may be missing the real threat here, and this is just my opinion, but I don't understand the threat given what I just explained.  I think this is a general problem with everything in Windows XP and I do believe this is one of the main reasons they introduced UAC.

Comment 16

[Al Billings [:abillings - ex-MoCo]]

This is an exploit. If a user downloads a .dll file into their downloads directory and then downloads and runs the installer from the same downloads directory, if we pull in dll files present, the user could get hit by this.

Comment 17

[Al Billings [:abillings - ex-MoCo]]

We've had a whole bunch of these related to the installer and updater in the last while that we've worked on. We should treat this as a serious threat. That's why Dan rated it sec-high.

Comment 18

[Brian R. Bondy [:bbondy]]

(In reply to Al Billings [:abillings] from comment #17)
> We've had a whole bunch of these related to the installer and updater in the
> last while that we've worked on. We should treat this as a serious threat.
> That's why Dan rated it sec-high.

Those ones have all been privilege escalation attacks. This one doesn't seem to be. With those ones a low integrity process could gain high integrity. With this one the only way to exploit t is to have someone manually download a DLL file and save it to their downloads directory and then after that download an installer and save it to the same directory, then execute it.  If an attacker was going to trick them into downloading something, it might as well be a virus directly. 

I'm not fighting fixing it given that, but I don't think it is as serious of a threat as the others given that it's not a privilege escalation attack.

(In reply to Al Billings [:abillings] from comment #17)
> We've had a whole bunch of these related to the installer and updater in the
> last while that we've worked on. We should treat this as a serious threat.
> That's why Dan rated it sec-high.

It was rated sec-high before we knew it was different from the other updater and installer threats. New information was presented since then (this being XP) and having a sound understanding of the problem at hand is what I'm uncovering.

Comment 19

[Brian R. Bondy [:bbondy]]

> That's why Dan rated it sec-high

And I don't think a rating should thwart any discussion or future re-evaluation about learning about the problem.

Comment 20

[Robert Strong (they/them - no direct email)]

(In reply to Al Billings [:abillings] from comment #17)
> We've had a whole bunch of these related to the installer and updater in the
> last while that we've worked on. We should treat this as a serious threat.
> That's why Dan rated it sec-high.
It is also important to note that:

(In reply to Al Billings [:abillings] from comment #0)
>...
> The issue exists in almost every applications around world, not only
> for your Firefox.
Should we try to get this fixed? Sure. Should we prioritize bugs like this above other work? That is by no means as clear of an answer as I see it in light of the current findings. I remember when security would prioritized bugs based on things such as the system has already been compromised and would then often wontfix'd them for the cases such as this bug. Nowadays it seems like bugs where the system has already been compromised are being given much higher priority and these bugs are preventing us from being able to work on other bugs.

Also, ++ to bbondy's comment

Comment 21

[Al Billings [:abillings - ex-MoCo]]

The lack of escalation is a good point.

The fact that they have to download it and comparing it to an exe is less so. A lot of people have been trained not to run strange exe's or to even check signatures. This bypasses this since most people are not aware (I wasn't before all of these bugs) that simply have a file with a .dll extension in the same directory of our signed exe validated to be from our site might still be enough to get malware run when you run our code.

Comment 22

[Matt Wobensmith [:mwobensmith][:matt:]]

We haven't moved on this bug in a while. It appears that there are three points being discussed above:

1. Does the problem occur on any platform?
2. If the problem occurs on WinXP only, how do we treat it?
3. If the problem occurs anywhere, is this an actual issue?

I've just tried this, using malicious DLLs (named LPK.DLL, USP10.DLL) with FF installers 20 and 26. I saw nothing on WinXP or Win7. The DLLs should spawn high-integrity processes for cmd.exe and calc.exe, but they did not.

If we cannot reproduce this on the latest installers, then we can't move any further. Haifei, I appreciate your patience, but I ask you to try it one more time. I don't think the language of the OS should matter at all - though if someone has an opinion, please weigh in.

Thank you.

Comment 25

[Benjamin Smedberg]

Discussed this in the install/update triage today. Our feeling is that while this is an attack vector, it is common to so many installers that it doesn't need to remain private. Our recommendation is that we make this bug public.

The engineering path forward is to modify NSIS itself, which is a large task that we aren't prepared to tackle this quarter, but we will mentor somebody who wants to try or consider making this an intern project next Summer.

Comment 29

[Ryan VanderMeulen [:RyanVM]]

Is this something updating to NSIS 3.0 would help with?

Comment 30

[Robert Strong (they/them - no direct email)]

I believe it is. I'm handing off the installer to mhowell so I'll let him answer this.

Comment 31

[Molly Howell (she/her) (mostly inactive)]

This attack is happening before NSIS even starts; this is the 7-zip extractor. If it were NSIS, the attack would be to drop the DLL in the temporary directory we run NSIS out of, not in the download directory.

I don't think we can do anything about this. We use the necessary controls on the DLL's that our code loads, but we can't control what *they* load. Every Windows installer and application has some form of this problem as far as I can tell; that includes Firefox itself.

Note that the issue *does* reproduce on current platforms with current installers, contrary to earlier comments. The problem was probably that the attempts which failed were trying to use DLL's that were not being loaded on those systems; on my current Win10 system, LPK.DLL never seems to get loaded at all, but WIN32U.DLL always does, so it could be used instead.