1948543 - MIME sniffing treats short plain-text responses as binary, but other browsers treat it as text/plain

Status: NEW

(Core :: Networking, defect, P2)

Description

[Aaryan9898]

Attachment: Firefox file download misinterpret.mp4

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36

Steps to reproduce:

Visit https://login.starhubgee.com.sg/VCRLS/secure-sg.imrworldwide.com
You might need to visit twice and see an exe gets downloaded.

Actual results:

The browser interpreted the response as exe even though there is no content-deposition header in response.

Expected results:

Just the rsponse should have been displayed.

Comment 1

[Dave Townsend [:mossop]]

The server isn't setting any content-type in the response and the response doesn't look like anything in particular (it looks like base64 encoded data) so we just classify it as an octet-stream.

I think this lives in networking but this just appears to be a misconfigured website. What is the security issue that you're concerned about here?

Comment 2

[Dave Townsend [:mossop]]

needinfo for comment 1.

Comment 3

[Daniel Veditz [:dveditz]]

On Safari, Chrome, and cURL I get the response "Cannot connect to the RightAccess Agent Service, please check setup". In our own dev tools we're seeing that as the base64 version of that. Spoofing our user agent doesn't change what the server sends us (not that I thought it would). The headers sent to each of the user agents appears to be the same. Are we misinterpreting something in HTTP/2? Or do the other browsers have some MIME-sniffing heuristic that decodes base64 to see if it looks like a known type?

That might be a browser-parity issue we want to do something about, but the outcome here is not a security bug.

• If the server doesn't give us a type we guess via various heuristics ("MIME sniffing")
• if the content-type or our guessed type says it's "binary" then we download it
• if there's no header giving us a different filename then we guess one based on the URL, which in this case ends in ".com"
• the handling of that is no different than for an actual executable the site intended to download.

Comment 4

[Daniel Veditz [:dveditz]]

Actually the server sends Content-length: 67 which matches the plain text. Our own devtools must be doing the base64 encoding when it's worried about displaying binary content. This looks like it's just a MIME-sniffing difference.

Comment 5

[Aaryan9898]

Hi @everybody.
I have not dug it up well.
I would like to know if this is a matter of concern to the team or not ?
If team want me to craft the malicious data into that exe file, i will try to look up into the issue deeply.

Also any site can have similar response which might get misinterpreted as exe.

Let me know about the decision.
Thanks