Closed Bug 1582671 Opened 5 years ago Closed 4 years ago

Firefox Treats Arris Modem Webpages (application/x-unknown-content-type) As Files to Download

Categories

(Core :: DOM: Security, defect, P2)

71 Branch
defect

Tracking

()

RESOLVED DUPLICATE of bug 1591932
Tracking Status
firefox70 --- wontfix
firefox71 --- wontfix
firefox72 --- fixed

People

(Reporter: bkerensa, Assigned: sstreich)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [domsecurity-active])

Attachments

(1 file)

Attached video FF-ARRIS.mov

[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.

Has Regression Range: --- → no
Component: Untriaged → File Handling
Keywords: regression
Summary: Firefox Treats Arris Modem Webpages As Files to Download → Firefox Treats Arris Modem Webpages (application/x-unknown-content-type) As Files to Download

Can you attach the headers (request and response) from the exchange with the Modem web server?

I wonder if this is a WebCompat issue?

Flags: needinfo?(bkerensa)

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

Flags: needinfo?(bkerensa) → needinfo?(ehumphries)

Thanks. The triage owner for this component the bug is in may have further questions.

Flags: needinfo?(ehumphries)

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...

Component: File Handling → DOM: Security
Flags: needinfo?(sstreich)
Flags: needinfo?(ckerschb)
Product: Firefox → Core
Regressed by: 1428473

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?

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?

Flags: needinfo?(ckerschb) → needinfo?(bkerensa)

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

Flags: needinfo?(bkerensa)

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?

Flags: needinfo?(bkerensa)

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:

  1. The modem says "nosniff" explicitly: believe them, they should fix it (which is effectively impossible)
  2. Ignore x-content-type-options: nosniff if there's no content-type: to apply it to, for all web sites everywhere

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?

Flags: needinfo?(kberezina)

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.

See Also: → 1589150

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.

Flags: needinfo?(kberezina)

Sebastian, assigning this to you as well in the meantime - thanks!

Assignee: nobody → sstreich
Priority: -- → P2
Whiteboard: [domsecurity-active]

(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.

Who knows how feasible Anne's suggestion in comment #11 is?

Flags: needinfo?(ckerschb)

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)

Flags: needinfo?(ckerschb)
Flags: needinfo?(sstreich)
See Also: → 1591932

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.

I'm marking this as a duplicate as we shipped our short-term fix for this problem in Bug 1591932 :)

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
Flags: needinfo?(bkerensa)
Has Regression Range: no → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: