Closed Bug 1642400 (CVE-2020-12423) Opened 1 year ago Closed 1 year ago

DLL Hijacking via webauthn.dll

Categories

(Core :: DOM: Device Interfaces, defect, P1)

76 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla79
Tracking Status
firefox-esr68 --- wontfix
firefox-esr78 78+ fixed
firefox77 --- wontfix
firefox78 + fixed
firefox79 --- fixed

People

(Reporter: riccardoancarani94, Assigned: mhowell)

Details

(Keywords: sec-moderate, Whiteboard: [reporter-external] [web-bounty-form] [verif?][post-critsmash-triage][adv-main78+])

Attachments

(3 files, 1 obsolete file)

A DLL hijacking vulnerability was found in the Firefox Windows version. An attacker that obtained access to the victim system would be able to use this vulnerability to maintain persistence or evade defences.
More specifically, the webauthn.dll DLL was found to be missing and it was possible to hijack it by creating a DLL with the same name in one of the directories within the %PATH% variable.

Additionally, just right after the installation process, the process firefox.exe was looking in the %APPDATA%\Local\Microsoft\WindowsApps directory for the aforementioned DLL (see attached screenshot). The directory is usually writable by the current user and it's outside the %PATH% variable, meaning that even without ACL misconfiguration (being able to write in a folder within the %PATH%) it would still be possible to execute code in this way.

This was tested with Firefox version 76.0.1

Flags: sec-bounty?
Group: websites-security → firefox-core-security
Type: task → defect
Component: Other → Security
Product: Websites → Firefox
Version: unspecified → 76 Branch

I'm not sure if this is an issue with WebAuthn or some installer thing. Or maybe both?

Group: firefox-core-security → dom-core-security
Component: Security → DOM: Device Interfaces
Flags: needinfo?(jjones)
Product: Firefox → Core
Summary: DLL Hijacking in Firefox for Windows → DLL Hijacking via webauthn.dll
Flags: needinfo?(mhowell)

I'm not familiar with it, but it looks like webauthn.dll is an OS library. We're trying to load it from here. We're using the correct DLL search path for that load, the problem is that the DLL we are trying to load does not exist on all Windows systems (presumably it was added fairly recently), so we keep walking the path until we end up trying to load from places we really should not be trying to load things from because they are user-writable.

We should load this DLL from an absolute path to the system directory using something like this helper instead of just by name. Perhaps we could also skip trying to load it on systems where we know it isn't supported, assuming we have some easier means of telling that than just checking if the file exists (if we know it was added in some specific Windows version for example; I'm having a hard time finding that or any other information about this thing).

Flags: needinfo?(mhowell)

Hi,

Molly's solution to use an absolute path seems to be optimal to me. Even if the DLL is not present in the system, then it would only look in the system folders like system32, considerably reducing the risk of this issue.
Looks like the WebAuthn support was intruduced natively in Windows 10 1903 as said here, but older versions of Windows 10 do not have this library.

If there is anything you'd like me to do, in terms of further testing, just let me know and I'd be more than happy to help.

I'm going to go ahead and take this bug, it should be straightforward to fix.

(In reply to riccardoancarani94 from comment #3)

Looks like the WebAuthn support was intruduced natively in Windows 10 1903 as said here, but older versions of Windows 10 do not have this library.

Thanks for pointing me to that; I think I didn't find it because I was looking for reference documentation, which is not there.

If there is anything you'd like me to do, in terms of further testing, just let me know and I'd be more than happy to help.

When I have one ready, I'll link to a patched build and ask if you can reproduce the bug using it, if that's okay.

Assignee: nobody → mhowell
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P1

I've just observed on a Win10 1803 system that an apparently compatible webauthn.dll exists there too, so I don't actually know where the version check should be set at. I don't believe that check is a necessary part of the fix, just an extra layer, so I'm going to leave it out.

As promised, here's an installer for a patched test build. With this patch I can no longer see any attempts to load this DLL from insecure locations, but I'd also like to get your confirmation that this resolves the issue if possible. Thanks.

Flags: needinfo?(riccardoancarani94)

Hi Molly,

I just tested your installer. I can confirm that webauthn.dll gets only searched from System32.

Flags: needinfo?(riccardoancarani94)

Thanks for putting the patch together.

Flags: needinfo?(jjones)

[Tracking Requested - why for this release]:
I don't see this as being bad enough to uplift to 68 or to 77, but it probably should get into 78 to be there for 78 ESR, so tracking requested. If you disagree, feel free to cancel.

Group: dom-core-security → core-security-release
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla79

Please request beta uplift when you get a chance.

Flags: needinfo?(mhowell)

Comment on attachment 9153568 [details]
Bug 1642400 - Improve DLL loading. r=jcj

Beta/Release Uplift Approval Request

  • User impact if declined: sec-moderate local privilege escalation 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 is a tiny patch, all it does is load an OS-provided DLL file from the exact path that we know it must be located at, by using a pre-existing helper function intended for this specific purpose.
  • String changes made/needed:
Flags: needinfo?(mhowell)
Attachment #9153568 - Flags: approval-mozilla-beta?

Comment on attachment 9153568 [details]
Bug 1642400 - Improve DLL loading. r=jcj

approved for 78.0b8, thanks

Attachment #9153568 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Flags: qe-verify-
Whiteboard: [reporter-external] [web-bounty-form] [verif?] → [reporter-external] [web-bounty-form] [verif?][post-critsmash-triage]
Flags: sec-bounty? → sec-bounty+
Whiteboard: [reporter-external] [web-bounty-form] [verif?][post-critsmash-triage] → [reporter-external] [web-bounty-form] [verif?][post-critsmash-triage][adv-main78+]
Attached file advisory.txt (obsolete) —
Attached file advisory.txt
Attachment #9158636 - Attachment is obsolete: true
Alias: CVE-2020-12423
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.