1961777 - (CVE-2025-6435) .url download via saving a response in DevTools lead to arbitrary file read

Status: VERIFIED FIXED

(DevTools :: Netmonitor, defect, P2)

Description

[:Gijs (he/him)]

(cloned from bug 1950056)

HI Team, Firefox is vulnerable for downloading dangerous extension such as .url, .lnk etc

These issues are already fixed in many save as areas by appending a .download to the file extension
My Bug Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=1809923

Issue is in Save Response As Feature

Steps to Reproduce

1. Visit the vulnerable page
2. click f12 and save the request using Save Response As
3. You can see the .url extension is downloaded now.

We can use this to read arbitrary files from the windows machine.

I have attached the poc video and html,.url files used in the poc for reference

Comment 1

[:Gijs (he/him)]

In bug 1950056 we established that the Windows file open/save dialog dereferences lnk/url files itself, so the consumer cannot really protect itself from this. So we tried telling the file dialog to never do that, but the consequence of that turned out to be that "shortcut" folders also became un-navigable (bug 1958222 and its 10 or so duplicates), because Windows does not distinguish between linked files or folders.

Given that that more thorough fix is therefore not really viable, as noted in the original bug and in comment 0 here, we already sanitize filenames in a lot of places, and we should work out why devtools is the "odd one out" here (vs. save link as... and various other paths to saving files).

Comment 2

[Ameen Basha M K]

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

we already sanitize filenames in a lot of places, and we should work out why devtools is the "odd one out" here (vs. save link as... and various other paths to saving files).

Team, This is the exact rootcause of my issue, which i was trying to explain in #1950056

Can you guys assign me as a reporter of this issue? else can we do a bounty revaluation and award me for a remaining amount (because as stated in mail thread the bounty amount for 1950056 was low due to the team was fixing a thing which was not reported but a part of). But now this ticket is exactly what i report so can you guys please look into this those perspective.

Comment 3

[Julian Descottes [:jdescottes]]

I imagine devtools bypasses the logic added in order to append .download ? We are using the following helper to save the response: https://searchfox.org/mozilla-central/rev/29184ec2b107c8b9dd8c9a594711c27545dfb2c7/devtools/shared/DevToolsUtils.js#830-868

/**
 * Save the given data to disk after asking the user where to do so.
 *
 * @param {Window} parentWindow
 *        The parent window to use to display the filepicker.
 * @param {UInt8Array} dataArray
 *        The data to write to the file.
 * @param {String} fileName
 *        The suggested filename.
 * @param {Array} filters
 *        An array of object of the following shape:
 *          - pattern: A pattern for accepted files (example: "*.js")
 *          - label: The label that will be displayed in the save file dialog.
 * @return {String|null}
 *        The path to the local saved file, if saved.
 */
exports.saveAs = async function (
  parentWindow,
  dataArray,
  fileName = "",
  filters = []
) {
  let returnFile;
  try {
    returnFile = await exports.showSaveFileDialog(
      parentWindow,
      fileName,
      filters
    );
  } catch (ex) {
    return null;
  }

  await IOUtils.write(returnFile.path, dataArray, {
    tmpPath: returnFile.path + ".tmp",
  });

  return returnFile.path;
};

I see the logic for adding .download is at https://searchfox.org/mozilla-central/rev/29184ec2b107c8b9dd8c9a594711c27545dfb2c7/uriloader/exthandler/nsExternalHelperAppService.cpp#3741-3757

if (!(aFlags & VALIDATE_ALLOW_INVALID_FILENAMES)) {
  // If the extension is one these types, replace it with .download, as these
  // types of files can have significance on Windows or Linux.
  // This happens for any file, not just those with the shortcut mime type.
  if (StringEndsWith(outFileName, u".lnk"_ns,
                     nsCaseInsensitiveStringComparator) ||
      StringEndsWith(outFileName, u".local"_ns,
                     nsCaseInsensitiveStringComparator) ||
      StringEndsWith(outFileName, u".url"_ns,
                     nsCaseInsensitiveStringComparator) ||
      StringEndsWith(outFileName, u".scf"_ns,
                     nsCaseInsensitiveStringComparator) ||
      StringEndsWith(outFileName, u".desktop"_ns,
                     nsCaseInsensitiveStringComparator)) {
    outFileName.AppendLiteral(".download");
  }
}

and we could use it similarly to https://searchfox.org/mozilla-central/rev/29184ec2b107c8b9dd8c9a594711c27545dfb2c7/toolkit/components/downloads/DownloadPaths.sys.mjs#46

return mimeSvc.validateFileNameForSaving(leafName, "", flags);

Comment 4

[Julian Descottes [:jdescottes]]

Attachment: Bug 1961777 - [devtools] Sanitize filename used in devtools saveAs helper

Comment 5

[Ameen Basha M K]

Team kindly check on my comment (comment 2)

Comment 6

[:Gijs (he/him)]

(In reply to Ameen Basha M K from comment #2)

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

we already sanitize filenames in a lot of places, and we should work out why devtools is the "odd one out" here (vs. save link as... and various other paths to saving files).

Team, This is the exact rootcause of my issue, which i was trying to explain in #1950056

No, the root cause is that Windows follows all these things and gives the consumer of its standard file dialogs no insight into what is happening, and as a result we have to keep working around. We tried to address that instead, and it didn't work well.

Can you guys assign me as a reporter of this issue?

bugzilla does not allow changing the reporter field for an issue, so we physically are not able to even if we wanted to.

The only reason I filed a separate issue is to be able to accurately track when the actual user-visible problem was fixed on a per-release basis, given that we ended up turning off the fix from bug 1950056, but the code still exists.

else can we do a bounty revaluation and award me for a remaining amount (because as stated in mail thread the bounty amount for 1950056 was low due to the team was fixing a thing which was not reported but a part of). But now this ticket is exactly what i report so can you guys please look into this those perspective.

I am not involved in any bounty decisions. But for what it's worth, I think it's very very implausible that anyone actually gets exploited via devtools in the way described in the original report (and copied here). We can still "fix" it, but if anything, I think drawing attention to the generic problem was more valuable than finding this specific instance in devtools, so any resulting bounty for "just" the devtools issue would be lower than whatever was awarded for 1950056. Just my personal opinion!

I will also point out that Mozilla itself did all the due diligence in terms of making sure any remaining issues were addressed by filing a second bug. That is, this bug got filed more than 2 weeks after the original bug was "unfixed" on the release channel. At no point did you contact us or query anything. To be clear I'm not complaining - it's not your responsibility! - but it feels pretty odd to then come and ask for (more) money for this bug when we did all the work ourselves.

Comment 7

[Daniel Veditz [:dveditz]]

Can you guys assign me as a reporter of this issue? else can we do a bounty revaluation and award me for a remaining amount

We tried to fix bug 1950056 one way that seemed more general, and this task bug is about trying to fix it in a more narrow way because we had to back the first attempt out. Either way the bounty s covered by bug 1950056; this is not a different vulnerability.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8d68574a82d7
[devtools] Sanitize filename used in devtools saveAs helper r=devtools-reviewers,bomsy

Comment 9

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

https://hg.mozilla.org/mozilla-central/rev/8d68574a82d7

Comment 10

[BugBot [:suhaib / :marco]]

The patch landed in nightly and beta is affected.
:jdescottes, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox139 to wontfix.

For more information, please visit BugBot documentation.

Comment 11

[Catalin Sasca, Desktop Test Engineering [:csasca]]

I was able to reproduce the issue on Firefox 139.0a1 (2025-04-22) on Windows 11 with help from Gijs.

The issue is fixed on Firefox 140.0b1 and Firefox 141.0a1 (2025-05-28) on the same system.

Comment 12

[Tom Ritter [:tjr]]

Attachment: advisory.txt

Comment 13

[Tom Ritter [:tjr]]

Attachment: advisory.txt