Closed Bug 1773894 (CVE-2022-36314) Opened 1 year ago Closed 11 months ago

Capture NTLM hash via LNK file download on Windows

Categories

(Toolkit :: Downloads API, defect, P1)

defect
Points:
2

Tracking

()

RESOLVED FIXED
104 Branch
Tracking Status
firefox-esr91 - wontfix
firefox-esr102 103+ fixed
firefox102 --- wontfix
firefox103 + fixed
firefox104 + fixed

People

(Reporter: akucybersec, Assigned: enndeakin)

References

Details

(Keywords: csectype-disclosure, sec-moderate, sec-vector, Whiteboard: [reporter-external] [client-bounty-form][adv-main103+][adv-esr102.1+])

Attachments

(3 files, 1 obsolete file)

I don't know if this can be considered as a bug but I think this could be a security issue on Windows.
It's possible to download .lnk files with FireFox without any restriction and, using the IconLocation property of the link file, it's possible to capture the NTLM hash.

I made a video (not listed on YouTube, nobody can see it): https://www.youtube.com/watch?v=Ml_jE-pwisI
In this video I try to explain and show you the problem.
I've tried to replicate this using a public IP address and it works.

Mozilla Firefox version: 101.0.1 (64-bit)

Hope it helps.

Flags: sec-bounty?

Not sure if this is the right component - feel free to redirect.
From a quick glance, it looks like Windows can automatically take actions based on the contents of .lnk files, so it might be good to rename these files if users download them.

Component: Security → Downloads API
Product: Firefox → Toolkit

(In reply to Dana Keeler (she/her) (use needinfo) (:keeler for reviews) from comment #1)

Not sure if this is the right component - feel free to redirect.
From a quick glance, it looks like Windows can automatically take actions based on the contents of .lnk files, so it might be good to rename these files if users download them.

I think this component is appropriate.
If we take Chrome as example (as shown in the video), it automatically renames the LNK files in .download
Of course, this is more like a Windows problem since it's Windows that tries to authenticate using the credentials, but I think that FireFox should "help"!

After the review, can I publish the video or should I delete it?
Thank you for your time.

Mike, is this basically the same root cause as bug 1659731?

Flags: needinfo?(mozilla)

Yes, same issue.

Flags: needinfo?(mozilla)

(In reply to Mike Kaply [:mkaply] from comment #4)

Yes, same issue.

Mike or Neil, do either of you have cycles to look into this? Although it's the same root issue as bug 1659731, I think this has gotten worse considering the driveby potential of maintaining the extension with the default download behaviour (save to disk).

Flags: needinfo?(mozilla)
Flags: needinfo?(enndeakin)

(would be worth checking if this still reproduces with 102 given it includes bug 1746052)

Is there anything I can do to help you troubleshooting this?
If you need anything, just ask, I'll reply as soon as possible.

(In reply to akucybersec from comment #7)

Is there anything I can do to help you troubleshooting this?
If you need anything, just ask, I'll reply as soon as possible.

Does the issue also happen with nightly (https://nightly.mozilla.org/ ) ?

Flags: needinfo?(akucybersec)
Attached image Nightly issue
Flags: needinfo?(akucybersec)

(In reply to :Gijs (he/him) from comment #8)

(In reply to akucybersec from comment #7)

Is there anything I can do to help you troubleshooting this?
If you need anything, just ask, I'll reply as soon as possible.

Does the issue also happen with nightly (https://nightly.mozilla.org/ ) ?

It does! I attached an image.

Remember that the issue happens when the user downloads the .lnk file in a folder and he opens the folder.
If the folder is already open, maybe in background, sometimes it happens even if the users does NOT bring the folder on the foreground (this applies to the Desktop too, since the Desktop is always "open").

Hope it helps.

Unfortunately I don't have cycles right now.

Flags: needinfo?(mozilla)
Assignee: nobody → enndeakin
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(enndeakin)
Points: --- → 2

This also fixes an issue where content types that have no primary extension associated with them end up with the wrong extension in some cases, which affected the newly added tests.

Severity: -- → S3
Priority: -- → P1

The severity field for this bug is set to S3. However, the bug is flagged with the sec-high keyword.
:enndeakin, could you consider increasing the severity of this security bug?

For more information, please visit auto_nag documentation.

Flags: needinfo?(enndeakin)

Comment on attachment 9283062 [details]
Bug 1773894, special-case some extensions when downloading them, r=gijs

Security Approval Request

  • How easily could an exploit be constructed based on the patch?: Someone just needs to create a file with the right contents and the lnk extension for download, then get the user to drag it to their file system.

The issue also existed on Chrome at one point and we implement a similar fix, so someone could compare the code here.

This version of the patch doesn't include the tests and has a slightly more generic description.

  • Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: Unknown
  • Which older supported branches are affected by this flaw?: All
  • If not all supported branches, which bug introduced the flaw?: None
  • Do you have backports for the affected branches?: No
  • If not, how different, hard to create, and risky will they be?: Would require a different patch for code before bug 1746052.
  • How likely is this patch to cause regressions; how much testing does it need?: Unlikely to cause regressions. An automated test exists.
  • Is Android affected?: Unknown
Flags: needinfo?(enndeakin)
Attachment #9283062 - Flags: sec-approval?
Severity: S3 → S2

Comment on attachment 9283062 [details]
Bug 1773894, special-case some extensions when downloading them, r=gijs

Approved to land an uplift

Attachment #9283062 - Flags: sec-approval? → sec-approval+

We can land the test mid-september.

Whiteboard: [reporter-external] [client-bounty-form] [verif?] → [reporter-external] [client-bounty-form] [verif?][reminder-test 2022-09-14]

(In reply to Tom Ritter [:tjr] from comment #17)

We can land the patch mid-september.

Uh, I guess you mean the test patch? Or you meant mid-July?

Flags: needinfo?(tom)

(In reply to :Gijs (he/him) from comment #18)

(In reply to Tom Ritter [:tjr] from comment #17)

We can land the patch mid-september.

Uh, I guess you mean the test patch? Or you meant mid-July?

The patch containing the test. Sorry I a word.

Flags: needinfo?(tom)
Group: firefox-core-security → core-security-release
Status: NEW → RESOLVED
Closed: 11 months ago
Resolution: --- → FIXED
Target Milestone: --- → 104 Branch

This grafts cleanly to Beta & ESR102 and can be nominated for uplift when you're ready. It'll need a rebased patch for ESR91, however.

See Also: → 1750979
Attachment #9282074 - Attachment description: Bug 1773894, change lnk extension on Windows when downloading files so that they aren't handled by the system, r=gijs → [Version with test] Bug 1773894, change lnk extension on Windows when downloading files so that they aren't handled by the system, r=gijs
Flags: in-testsuite?

Comment on attachment 9283062 [details]
Bug 1773894, special-case some extensions when downloading them, r=gijs

Beta/Release Uplift Approval Request

  • User impact if declined: Security issue that allows an attacker to access information about the user's system simply by having them download a specially crafted file.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: No
  • 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): Only affects files with specific extensions (lnk, location) that are not normally downloaded.
  • String changes made/needed: None
  • Is Android affected?: Unknown

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration:
  • User impact if declined: Security issue that allows an attacker to access information about the user's system simply by having them download a specially crafted file.
  • Fix Landed on Version: 103
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Only affects files with specific extensions (lnk, location) that are not normally downloaded.
Flags: needinfo?(enndeakin)
Attachment #9283062 - Flags: approval-mozilla-esr102?
Attachment #9283062 - Flags: approval-mozilla-beta?

Without bug 1746052, a patch for esr91 would be very different and would require changes in five or so different locations. Not sure how worth it would be for 2 months.

Dan, given the rating of this bug, I think the question in comment 25 should probably be answered by your team.

Flags: needinfo?(dveditz)

We're lowering the severity here a little because of the manual steps and likely social engineering required (the user has to go open the .lnk later), and also because we think this is only useful when the attacker is on the same local domain. The impact is enough different (NTLM hash) that we are going to award a bounty, however, and not deny it on the basis of the two-year old duplicate bug 1659731

Keywords: sec-highsec-moderate
Flags: sec-bounty? → sec-bounty+

Comment on attachment 9283062 [details]
Bug 1773894, special-case some extensions when downloading them, r=gijs

Approved for 103.0b9, thanks.

Attachment #9283062 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Flags: needinfo?(dveditz)

Comment on attachment 9283062 [details]
Bug 1773894, special-case some extensions when downloading them, r=gijs

Approved for ESR102.1, thanks.

Attachment #9283062 - Flags: approval-mozilla-esr102? → approval-mozilla-esr102+
QA Whiteboard: [post-critsmash-triage]
Flags: qe-verify-
Whiteboard: [reporter-external] [client-bounty-form] [verif?][reminder-test 2022-09-14] → [reporter-external] [client-bounty-form][reminder-test 2022-09-14][adv-main103+]

I'm sorry, just a question since this is my first time: I've noticed that I will receive a bounty for this submission.
Since it says "Awarded: 2022-07-12" and I did not receive any notification via email or something, I was wondering if everything's ok and I'll receive further details later.
Thanks.

Someone @mozilla.com will reach out to your primary email address.

Attached file advisory.txt

(In reply to Frederik Braun [:freddy] from comment #33)

Someone @mozilla.com will reach out to your primary email address.

Thank you!

Alias: CVE-2022-36314
Whiteboard: [reporter-external] [client-bounty-form][reminder-test 2022-09-14][adv-main103+] → [reporter-external] [client-bounty-form][reminder-test 2022-09-14][adv-main103+][adv-main102.1+]
Whiteboard: [reporter-external] [client-bounty-form][reminder-test 2022-09-14][adv-main103+][adv-main102.1+] → [reporter-external] [client-bounty-form][reminder-test 2022-09-14][adv-main103+][adv-esr102.1+]
Group: core-security-release

6 months ago, Tom Ritter [:tjr] placed a reminder on the bug using the whiteboard tag [reminder-test 2022-09-14] .

enndeakin, please refer to the original comment to better understand the reason for the reminder.

Flags: needinfo?(enndeakin)
Whiteboard: [reporter-external] [client-bounty-form][reminder-test 2022-09-14][adv-main103+][adv-esr102.1+] → [reporter-external] [client-bounty-form][adv-main103+][adv-esr102.1+]

The test never landed but I updated it as part of bug 1809923.

Flags: needinfo?(enndeakin)
Duplicate of this bug: 983857
Attachment #9282074 - Attachment description: [Version with test] Bug 1773894, change lnk extension on Windows when downloading files so that they aren't handled by the system, r=gijs → Bug 1773894, change lnk extension on Windows when downloading files so that they aren't handled by the system, r=gijs
Attachment #9282074 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.