1644954 - (CVE-2020-15657) DLL Hijacking in Firefox 77.0.1 - dwrite.dll and ntmarta.dll

Status: RESOLVED FIXED

(Toolkit :: Startup and Profile System, defect)

Description

[Nyan Lin]

Attachment: dll_hijack_mozilla.zip

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36

Steps to reproduce:

Firefox version: 77.0.1 (x86)

Use ProcMon to monitor DLLs which FireFox request but are missing. Out of a few, one of them is dwrite.dll.

This DLL is loaded from "C:\Program Files (x86)\Mozilla Firefox" and user can simply drop their own malicious code to be executed once FireFox is launched.

Actual results:

Code execution on client side. In the PoC, a text box with "DLL Hijacked!" was successfully executed once firefox.exe was launched.

This could also lead to privilege escalation if the firefox.exe is run with admin privileges.

Expected results:

As per Microsoft's recommendations, the developers should:

Validate their applications for instances of nonsecure library loads (examples of each are given later in this article). These include the following:
- The use of SearchPath to identify the location of a library or component.
- The use of LoadLibrary to identify the version of the operating system.

Use fully qualified paths for all calls to LoadLibrary, CreateProcess, and ShellExecute where you can.

Comment 1

[Nyan Lin]

Additionally, the ntmarta.dll DLL is also vulnerable to hijacking.

Comment 2

[Nyan Lin]

There is also a vulnerable dll called "ntmarta.dll" which is in the same directory - "C:\Program Files (x86)\Mozilla Firefox".

Leveraging on these two DLLs, a reverse shell could be executed using a meterpreter payload.

Comment 3

[Daniel Veditz [:dveditz]]

We do use searchpath. When we run into problems like this is has almost always been windows itself loading the dlls, and we can't specify the full path for those. Can the dlls be loaded from somewhere else? We generally figure that if a user can drop a .DLL into the firefox install directory they could just replace Firefox itself with a fake copy. The victim has obviously lost control of their machine long before Firefox loaded the hijack .dll.

Comment 4

[Daniel Veditz [:dveditz]]

What version of WIndows are you seeing this on?

Comment 5

[Nyan Lin]

Hi Daniel,

I was using Windows 7 - 6.1.7601. I could not load the dlls from anywhere else other than the installation directory so I think you are right in saying that once the user has access to the install directory, they will need to have administrator privileges, and by then a fake FF exe could be dropped too.

Regards,
Steve

Comment 6

[Daniel Veditz [:dveditz]]

Molly: I believe you fixed a similar issue recently, though in that case we were loading it explicitly. Is there anything that can be done about these or is it expected Windows behavior to try to load these from the install directory?

Comment 7

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

Here's my initial analysis: on Windows 10 I don't see any attempt to open ntmarta.dll outside of system32, so I'm thinking that's a Windows issue that's been corrected. We are trying one time to open dwrite.dll from the install directory (not from the rest of the search path), but it's well after that DLL has already been loaded, so I can't reproduce any attempt to actually load the image at that path. We shouldn't be trying to open that file at all though, so I'm looking into where that's happening.

Comment 8

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

On further investigation, the LoadLibrary for ntmarta.dll on Windows 7 is coming from advapi32.dll, so that one is Windows itself. I found a couple different places where we end up trying to load dwrite.dll ourselves, so I'll patch those.

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:mossop, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 10

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

Attachment: Bug 1644954 - Improve DLL loading. r=#gfx-reviewers

Comment 11

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

This bug doesn't have a sec- rating right now, but it's effectively the same thing as bug 1642400 (probably milder than that one in fact), and it was sec-moderate, so now that this patch has r+ I'm planning to forego the security approval process and just land it.

Comment 12

[Daniel Veditz [:dveditz]]

Is there some linting we could do to prevent these being introduced?

Comment 13

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/integration/autoland/rev/781d1e1704c14b18ad843dafa9f8bc507e754a20
https://hg.mozilla.org/mozilla-central/rev/781d1e1704c1

Comment 14

[Ryan VanderMeulen [:RyanVM]]

Please nominate this for Beta and ESR78 approval when you get a chance.

Comment 15

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

Comment on attachment 9159780 [details]
Bug 1644954 - Improve DLL loading. r=#gfx-reviewers

Beta/Release Uplift Approval Request

• User impact if declined: sec-moderate code execution bug
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This patch just changes a DLL load to use the absolute path where we know the DLL file must be instead of searching for it.
• String changes made/needed:

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Low risk patch for a sec-moderate bug.
• User impact if declined:
• Fix Landed on Version: 80
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky):
• String or UUID changes made by this patch:

Comment 16

[Julien Cristau [:jcristau]]

Comment on attachment 9159780 [details]
Bug 1644954 - Improve DLL loading. r=#gfx-reviewers

approved for 79.0b4 and 78.1esr

Comment 17

[Julien Cristau [:jcristau]]

https://hg.mozilla.org/releases/mozilla-beta/rev/6e11fb81cbfb

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr78/rev/b234c76deb4a

Comment 20

[Daniel Veditz [:dveditz]]

sec-low is a better rating. These .DLLs do exist in the windows directory so they will be found. bug 1642400 was worse because in older versions of windows it did not exist and then the rest of the user's search path could be used, and some of those directories might be writable (as in that bug's PoC) even if the Firefox directory itself is protected.

Comment 21

[Nyan Lin]

Any action required on my part?

Comment 22

[Frederik Braun [:freddy]]

Attachment: advisory.txt