951804 - Load order vulnerability may case Firefox to load untrusted dlls

Status: NEW

(Firefox :: Security, defect)

Description

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

Date: Wed, 18 Dec 2013 11:30:01 +0530
Subject: Re: security bug bounty:Load Order vulnerability in firefox.exe
From: lucky babloo <[e-mail]>
-----//-----
Hello Curtis,

What POC do:

1.The POC copies the whole of mozilla installation to %temp%\Mozilla directory and replaced the nss3.dll in the temp directory nor the program files location. Thus for replacing the crafted dll we dont need administrative rights. Then runs the firefox.exe with elevation request. 
2. Firefox.exe  Adds Registry to HKLM by creating MozillaPoc Service.
3. For this as you mentioned UAC permission is required.
4. This permission is acquired using Mozilla certificate. 


I am sending you the POC source code.

It conatins:
1. Source of EXE file.
2. Source of DLL that is crafted.
password:mozilla

We are saying that if attacker gets access for running code in user level, it can be escalated to administrator using mozilla certificate by running firefox from temp location.

Regards,

Babloo Team.

Comment 1

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

Attachment: PoC Dll Source.cpp

Comment 2

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

Attachment: MO.def

Comment 3

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

Attachment: MozillaPOC.cpp

Comment 4

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

I've exchanged several emails with the authors of this report and from my perspective this attack requires the user to execute a file and then accept a UAC prompt before the actions can take place. There may be an issue with loadorder here but if administrative rights are needed to then foster the rest of the attack I believe this to be a low threat. If an attacker can achieve or has administrative rights there are far worse things they can do. That said I still wanted to have others weigh in with analysis here.

Comment 5

[Brian R. Bondy [:bbondy]]

I think the issue described happens with just about any application on Windows. It's generally a bad idea to execute an application as elevated which is located in a low integrity location.  

We install by default into program files. 

Whether we fix or not, I think someone who already has this malware on their computer would succeed eventually via someone's binary.  I don't think the reporter should get a bounty for this personally. I think it's more of a general Windows problem. They should provide extra warning to their users when executing something in a low integrity location.

Comment 6

[Babloo]

what does sec-moderate keyword mean by? I am new to mozilla bugs. Will it be accepted as a valid bug? Will it be fixed?

Comment 7

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

(In reply to Babloo from comment #6)
> what does sec-moderate keyword mean by? I am new to mozilla bugs. Will it be
> accepted as a valid bug? Will it be fixed?

It's a rating of security severity, these items for security sake are documented here: https://wiki.mozilla.org/Security_Severity_Ratings.

Comment 9

[Daniel Veditz [:dveditz]]

This is kind of the way windows works. If you can replace parts of Firefox then the locally installed malware has already run. By default we install Firefox into the protected Program Files location that malware should not be able to modify without already having elevated permissions.

Are there any library-using Windows executables that are not vulnerable to this when installed into an unprotected location? This seems like a general Windows anti-pattern that could be discussed in public. Any objection to unhiding the bug?

Comment 10

[Brian R. Bondy [:bbondy]]

No objection here, but others please chime in. Feel free to un-private my post and rstrongs as well.