1843032 - Spoofing via filename download (firefox android)

Status: RESOLVED FIXED

(Firefox for Android :: Downloads, defect, P3)

Description

[Hafiizh]

Attachment: firefox_downloadspoof.mp4

I found vulnerability via filename donwload using \n or \r . lead to spoof filename

step to produce:

1. open http://103.186.0.20/downloadspoof.html or downloadspoof.html
2. click "open" button

impact : victim can be spoofed will think that it is a document file and even though it is an apk file

Comment 1

[Hafiizh]

Attachment: downloadspoof.html

Comment 2

[Hafiizh]

Attachment: spoof.jpg

Comment 3

[Hafiizh]

using filename : "fakeapk.doc\r\r\n\n\n\rhacked\n\rlink\rdownload\r:\rattacker.com\n.apk"

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

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

For more information, please visit BugBot documentation.

Comment 5

[Mike a [:mavduevskiy]]

Thanks for reporting this bug! It looks like were are displaying the file name exactly the way it is.

There are a few paths that we could take. Firefox desktop replaces special characters with a single space, while Android Chrome with the underscore. I would actually vote for underscore in this case, as files names with empty spacing in the name often leads to unexpected problems – though generally Linux is capable of handling those.

It might also be a good idea to ask the UX team to take a look into this.

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

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

For more information, please visit BugBot documentation.

Comment 7

[Daniel Veditz [:dveditz]]

Firefox Desktop uses spaces, but it's careful to make sure the filename is shown on one line. It doesn't linebreak on those spaces, and formats the dialog to clearly distinguish between the part that is the filename and the part that comes from Firefox. With the simple Android panel (visually more appealing than the desktop one) you can see there's lots of room for an attacker to add text that might look like explanation "from Firefox" to further the spoof. We need to coalesce whitespace to prevent that. [On desktop they have to be careful to show the end of the filename in case the single-line filename is "too long": they truncate the front of the filename.]

Can we simply not, though? No download for you, you malicious bastard! Do we have a fallback if the download attribute isn't given at all, or is entirely invalid characters? If so, would that work? For an https link we try to use the filename in the URL, but that doesn't apply here with a data: url. Sadly we can't be that strict: a site might use a valid character on their tested platform that happens to be invalid on Android, but we shouldn't punish Firefox users for the site's problems.

Comment 8

[Daniel Veditz [:dveditz]]

Bug 1822968 is a completely different issue, but coordinate work so we don't stomp on the dialog changes

Comment 9

[Mike a [:mavduevskiy]]

If android coalesces whitespaces, it will cause linebreak given how limited screen width is available for a phone. I do believe that going with coalesced underscore is a safer bet.

If the name is not provided, Fenix will use to come up with a based on url file name, with a fallback 'downloadfile'

We don't truncate really long file-names though, we display some lines and the rest of context is scrollable. Maybe it's also something we should look into.

I don't think we could manipulate heavily (like denying) with logic depending on the naming, but some form of sanitizing is definitely needed.
There is another bug related to not sanitized names – 1815613. A good sanitizing function would kill two birds, but the usecase is different and I won't mark it as duplicate.

I wonder what's inside the bug? I don't have access

Comment 10

[Hafiizh]

Hello any updates?

Comment 11

[Hafiizh]

Hello any updates?

Comment 12

[Hafiizh]

Attachment: downloadff.jpg

I tried it on the latest Firefox Nightly and I can't reproduce it. The file name if there is a space has been changed to "_" have you fixed it?

Comment 14

[Daniel Veditz [:dveditz]]

It appears this was fixed in bug 1873528 (patch https://hg.mozilla.org/mozilla-central/rev/38e15afaa78d) by folks who likely couldn't see this bug.

If that hadn't been fixed first, the fix for bug 1815613 (filed earlier, but fixed later) may have led to blocking the control characters too. Or maybe it would not have.

The description of a spoofing attack here is different from what the developers thought they were fixing in that other bug. Therefore I'm going to close this one as "FIXED" depending on that other bug rather than make it a duplicate merely because the fix was the same. That will work better for judging this for the bug bounty.