Firefox Treats Arris Modem Webpages (application/x-unknown-content-type) As Files to Download
Categories
(Core :: DOM: Security, defect, P2)
Tracking
()
People
(Reporter: bkerensa, Assigned: sstreich)
References
(Regression)
Details
(Keywords: regression, Whiteboard: [domsecurity-active])
Attachments
(1 file)
2.89 MB,
video/quicktime
|
Details |
[Tracking Requested - why for this release]:
When accessing Arris Modem webpages hosted on the modems built-in web server Firefox treats individual pages as files to be downloaded instead of loading those pages and rendering the content.
I have attached a screenshot to demonstrate and I did inspect the html of pages and do not see anything suspect that would be causing the links to download.
Can confirm this issue is on Nightly on MacOS and Firefox iOS stable and this is a new issue as Firefox never used to have this behavior with these pages.
Updated•5 years ago
|
Can you attach the headers (request and response) from the exchange with the Modem web server?
I wonder if this is a WebCompat issue?
Reporter | ||
Comment 2•5 years ago
|
||
Here you go!
Request
Host: 192.168.100.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:71.0) Gecko/20100101 Firefox/71.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
Referer: http://192.168.100.1/cgi-bin/status
Upgrade-Insecure-Requests: 1
Response
HTTP/1.1 200 OK
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src 'self' 'unsafe-inline'; img-src 'self'; child-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval';
X-Permitted-Cross-Domain-Policies: none
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache
Connection: close
Date: Fri, 20 Sep 2019 22:47:33 GMT
Server: lighttpd
Thanks. The triage owner for this component the bug is in may have further questions.
Comment 4•5 years ago
|
||
The issue is that it's sending:
X-Content-Type-Options: nosniff
In bug 1428473 we started honouring the mimetype sent by the server for those requests when they're documents. You can flip dom.security.respect_document_nosniff
to false
to work around it. We're in the process of unshipping this change in Firefox 70 (bug 1585055).
Sebastian/Christoph, what do we want to do here? These modems can't be updated, I expect...
Comment 5•5 years ago
|
||
What are Chrome and Safari doing here? Are they still sniffing if there's no Content-Type
header present on the response? Do we have a test matrix of sorts to see how compatible we are?
Comment 6•5 years ago
|
||
As Gijs mentioned in comment 4 we are unshipping XCTO within Firefox 70 and defer shipping till Firefox 71 (at least for now), that should buy us some time to resolve the issue.
(In reply to Anne (:annevk) from comment #5)
What are Chrome and Safari doing here? Are they still sniffing if there's no
Content-Type
header present on the response? Do we have a test matrix of sorts to see how compatible we are?
I would also be curious about the behavior of other browsers - :bkerensa do you happen to know?
Reporter | ||
Comment 7•5 years ago
|
||
I’m seeing this on Safari Deaktop and Mobile but not on Chrome and haven’t checked Brave etc.
I did file a bug with Apple they said they are addressing in a future release
Comment 8•5 years ago
|
||
Benjamin, could you tell us what you see happening in Chrome? Are you getting a text/plain document there or is there rendered HTML somehow?
Comment 9•5 years ago
|
||
This is a tricky case. We added webcompat interventions for other broken cases (e.g. bug 1584591), but there's no fixed origin for "my modem" so I don't think that will work here. Need more ideas than two bad choices:
- The modem says "nosniff" explicitly: believe them, they should fix it (which is effectively impossible)
- Ignore
x-content-type-options: nosniff
if there's nocontent-type:
to apply it to, for all web sites everywhere
Comment 10•5 years ago
|
||
Ksenia: is this something we could do an intervention for, like match all RFC 1918 ("private") addresses and stick in Content-type: text/html
if there isn't one and there's a nosniff
header?
Comment 11•5 years ago
|
||
Well, there's a third choice, if Chrome is displaying this as text/plain we can change our default from downloading to showing as text/plain. We decided to side with Safari when implementing as that is what we already do in other cases, but we could switch things around if necessary.
Comment 12•5 years ago
|
||
We could look into adding an intervention, though that is a lot of addresses, so there might be a performance impact. I can run talos tests to verify.
Comment 13•5 years ago
|
||
Sebastian, assigning this to you as well in the meantime - thanks!
Comment 14•5 years ago
|
||
(In reply to Ksenia Berezina [:ksenia] from comment #12)
We could look into adding an intervention, though that is a lot of addresses, so there might be a performance impact. I can run talos tests to verify.
Chatting with Ksenia about this yesterday, we have some concerns about shipping the interventions for all private IP addresses for what would probably be forever (unless we can hook in some telemetry to know when this modem disappears...).
Do we have a sense of how feasible Anne's suggestion in Comment #11 is, and if it might be upliftable? We could consider a short-term intervention as a bandaid too.
Comment 15•5 years ago
|
||
Who knows how feasible Anne's suggestion in comment #11 is?
Comment 16•5 years ago
|
||
We talked about options and we are going to change things so that XCTO nosniff only blocks if there is an 'incorrect' mime type but not a missing mime type. In turn that change will render this bug as a 'WORKSFORME'.
Additional note when the XCTO will be prefed on:
FF 70 - disabled
FF 71 - currently enabled, but will be disabled
FF 72 - will be enabled with the carveout from above (not blocking for missing mime type)
Updated•5 years ago
|
Comment 18•5 years ago
•
|
||
Christoph, that still won't be compatible with Chrome though, right? I can kinda see why we might want to implement a short term workaround, but long term being different from both Chrome and Safari doesn't seem like a good outcome.
Assignee | ||
Comment 19•4 years ago
|
||
I'm marking this as a duplicate as we shipped our short-term fix for this problem in Bug 1591932 :)
Updated•4 years ago
|
Updated•4 years ago
|
Updated•2 years ago
|
Description
•