I discovered an incorrect symbol override of the character when placed in the file extension name. When the "Always ask for file save" flag is enabled, it is possible to save prohibited extensions that will not be converted to .download.
It is not possible to run such a file from the browser, but if the user executes the file from the folder, it could be dangerous.

An example of a file name looks like this: example.url. You can change it to any type of extension by adding just the character.
This works only for Windows.
I see that I cannot correctly transmit this character through the panel, decrypt BASE64 to understand which character is being discussed.

Using a phishing attack, it is also possible to read local files.

Hey Neil, could you take a look? I'm surprised that the null byte would be able to bypass any of the constraints added here.

The filename in the testcase is \u0001, there is no null character that I can see.

A null character gets turned into an underscore so the filename becomes example._url
The \u0001 character will get converted into space so the filename becomes example. url with a space prefix.

My version of Windows 11 does not treat either case as a shortcut/link file. Is this different for earlier versions of Windows?

We could change the substitution to use a underscore for both I suppose if the space is causing an issue.

(In reply to Neil Deakin from comment #3)

The filename in the testcase is \u0001, there is no null character that I can see.

A null character gets turned into an underscore so the filename becomes example._url
The \u0001 character will get converted into space so the filename becomes example. url with a space prefix.

My version of Windows 11 does not treat either case as a shortcut/link file. Is this different for earlier versions of Windows?

We could change the substitution to use a underscore for both I suppose if the space is causing an issue.

It appears that this works only for Windows 10 and only for Save As. I have looked at Google Chrome changing to underscore, and I think it would be wise to do the same.

Note that the file format transformation duplicates the file extension, and if we replace it with an underscore, we will no longer have this bug?

I checked and other characters, adding a character at the beginning of the file extension allows bypassing the filter. We can add space characters or ">", ":"
Based on this, it would be reasonable to limit the addition of characters at the beginning of the file extension.
Examples:
". :url"
". url"
".>url"

The primary issue here is that while we replace the invalid characters with spaces, at https://searchfox.org/mozilla-central/rev/fe2743c6c5c708061c7f6504b26958fcc815bb4a/widget/windows/nsFilePicker.cpp#1021 we strip out the whitespace, leaving a default extension with the same characters without the spaces. The Windows filepicker then does its own filename modification to match the extension filter.

We could change the substitution to use a underscore for both I suppose if the space is causing an issue.

Yeah, space is a bad substitution character—for anything, really—in the file extension part.

(In reply to Neil Deakin from comment #7)

The primary issue here is that while we replace the invalid characters with spaces, at https://searchfox.org/mozilla-central/rev/fe2743c6c5c708061c7f6504b26958fcc815bb4a/widget/windows/nsFilePicker.cpp#1021 we strip out the whitespace, leaving a default extension with the same characters without the spaces. The Windows filepicker then does its own filename modification to match the extension filter.

Alas, we can't just drop the StripWhitespace call -- there are spaces in the input, both from the Web and internally. While I would like to move to something more like what the Gtk file-picker does and actually parse the input string instead of "sanitizing" it — preferably in cross-platform code, at that —

(In reply to Daniel Veditz [:dveditz] from comment #8)

Yeah, space is a bad substitution character—for anything, really—in the file extension part.

— +1. This happens well before the platform-specific file-picker gets its hands on the filename and/or filter-set, and is presumably a cross-platform issue.

Neil, are you able to pick this up?

I think what can happen here is to generally replace all invalid characters with underscores instead of spaces (Chrome seems to have this behaviour), and remove any whitespace from the extension.

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

For more information, please visit BugBot documentation.

Backed out for assertion failures:
https://hg.mozilla.org/integration/autoland/rev/c70f720dd79a60e2604dcb63fec8d4a53f0ebb96

Push with failures
Failure log

ASSERTION: Illegal file characters have changed!: '!strcmp(QuotaManager::kReplaceChars, FILE_ILLEGAL_CHARACTERS FILE_PATH_SEPARATOR)', file /builds/worker/checkouts/gecko/dom/quota/SanitizationUtils.cpp:20) at /builds/worker/checkouts/gecko/xpcom/base/nsDebugImpl.cpp:512

The R(C) and Wr4 tasks are also assertion failures from this commit.

https://hg.mozilla.org/mozilla-central/rev/91862a7f6297

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

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox127 to wontfix.

For more information, please visit BugBot documentation.

Comment on attachment 9398698 [details]
Bug 1891234, additional filename filter checks, r=gijs

Beta/Release Uplift Approval Request

• User impact if declined: Improves the filename sanitization when saving files, otherwise a filename given by a page can be used to create a file that is saved an internet shortcut to a local 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): Improves filename sanitization using underscores instead of whitespace in a way similar to the way other browsers do.
• String changes made/needed: None
• Is Android affected?: Yes

Original Revision: https://phabricator.services.mozilla.com/D208659

esr115 Uplift Approval Request

• User impact if declined: Improves the filename sanitization when saving files, otherwise a filename given by a page can be used to create a file that is saved an internet shortcut to a local file.
• Code covered by automated testing: yes
• Fix verified in Nightly: no
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: n/a
• Risk associated with taking this patch: Low
• Explanation of risk level: Improves filename sanitization using underscores instead of whitespace in a way similar to the way other browsers do.
• String changes made/needed: None
• Is Android affected?: yes

Comment on attachment 9398698 [details]
Bug 1891234, additional filename filter checks, r=gijs

Approved for 127 beta 6, thanks.

Neil, on esr115 the uplift is causing some failures:
https://treeherder.mozilla.org/logviewer?job_id=460383707&repo=mozilla-esr115&lineNumber=14423

Could you have a look please? Thanks