Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 2 users
Status: Fixed
Owner:
Closed: Sep 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug-Security



Sign in to add a comment
Mark of the Web bypass in Chrome
Reported by msvulnre...@gmail.com, Apr 7 2016 Back to list
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2486.0 Safari/537.36 Edge/13.10586

Steps to reproduce the problem:
1.       In Windows, open Chrome and browse to http://payloadhoster.cloudapp.net/WordDataRedirect.htm
2.       Click the “download.docx” file that appears at the bottom of the Window.

Expected: the document file has Mark of the Web (MOTW) applied to it, and is opened in protected view.
Actual: the document does not have MOTW applied to it and is opened without protected view.

This works because the web page uses javascript to set the document location to a URL beginning with “data:application/vnd.openxmlformats-officedocument.wordprocessingml.document;base64,”. Chrome will open data: URI’s with arbitrary MIME types, and does not apply Mark of the Web to files downloaded this way in Windows.

This bug cannot be reproduced in Firefox (which applies mark of the web) or IE (which won’t open data: URI’s for arbitrary MIME types like this).

As an additional note, the filename for the document can be controlled using the “download” attribute of an anchor tag.

A repro with this addition can be found here:
http://payloadhoster.cloudapp.net/WordDataRedirect2.htm

What is the expected behavior?
the document file has Mark of the Web (MOTW) applied to it, and is opened in protected view.

What went wrong?
the document does not have MOTW applied to it and is opened without protected view.

Did this work before? N/A 

Chrome version: 46.0.2486.0  Channel: n/a
OS Version: 10.0
Flash Version: Shockwave Flash 21.0 r0

please email msvr@microsoft.com for any correspondence and include MSVR 1525 in the title
 
Comment 1 by kenrb@chromium.org, Apr 8 2016
Cc: elawre...@chromium.org
Components: UI>Browser>Downloads
Labels: -Pri-2 Security_Severity-Medium Security_Impact-Stable M-50 Pri-1
Owner: asanka@chromium.org
Status: Assigned
Thank you for the report.

asanka@: Is this one known? I can't see any reference to this approach in existing open bugs.
Chrome relies on AttachmentServices to apply the MOTW. We've been discussing applying the MOTW ourselves to work around a number of issues with AttachmentServices, of which this could be another.

There's also a separate discussion about whether data: and blob: URLs should be considered invalid navigation targets. But I consider that tangential to the issue here since <a download> would still work (doesn't go through navigation logic).

If an authority-less URL passed to IAttachmentExecute::SetSource, I think it ought to be defaulting to treating the source as Internet Zone (and that's what MapURLToZone does today). So we should probably kick that part back to Microsoft for them to clean up on their side.

Having said that, when we call SetSource (https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/safe_util_win.cc&q=IAttachmentExecute&sq=package:chromium&l=84) should we really be using the data: URI at all? It seems like it would make much more sense to supply the security-origin in which that Data URL lives, or perhaps something like "about:internet" if there is no security origin.

Microsoft mitigates this problem on their side somewhat by not supporting navigation to Data URIs, but Edge does tag an <a download href="data:">-created file with a MOTW.
#3: Agreed on using something akin to the interface origin for data URLs. We can try the referrer if it's available, or some made up URL that'll reliably map to the internet zone.

Project Member Comment 5 by sheriffbot@chromium.org, Apr 23 2016
asanka: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member Comment 6 by sheriffbot@chromium.org, May 7 2016
asanka: Uh oh! This issue still open and hasn't been updated in the last 28 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Any updates/timeline for this?
FYI: if this issue is fixed and an acknowledgement given, credit should go to:
Jonathan Birch and Microsoft Vulnerability Research
Comment 9 by aarya@google.com, May 25 2016
Cc: palmer@chromium.org f...@chromium.org lgar...@chromium.org est...@chromium.org
+cc enamel folks if they can help with this during fixit.
While we use IAttachmentExecute, we're subject to Windows' whims and lack of documentation of the interface's behavior. If we expect to use the interface indefinitely, I think we need to kick this back to them and ask for better documentation of what's expected here and/or what Internet Explorer does; it certainly *seems* like the API should default to the Internet Zone for any URL Protocol (like DATA) that does not override the default. Unfortunately, afaik, IAttachmentExecute hasn't had much investment since ~2004 and there were always weird ownership issues of this code between the Windows Shell team and IE teams. So we may not find any good answers there.

Tactically, I think this fix is simple: If the URL we're calling SetSource on has a scheme of kAboutScheme,kBlobScheme,kDataScheme,kGopherScheme (if supported),kJavaScriptScheme (if that can ever create a context), then we should look up the effective security context of that origin (e.g. what does document.domain return for script running in that context) and use that as the URL we pass to set source. If we cannot determine the context URL, then we should pass "about:internet" into SetSource so that the file reliably gets an Internet Zone marking. 

I don't know if Chrome has any sort of protocol extensibility; we probably should be proactive and, for any scheme we don't recognize (everything but ftp,http,https,data,blob,about,javascript,gopher, in url_constants.h), pass "about:internet" to cover the case where we have a protocol that URLMon does not recognize. 

We could be even more cautious/aggressive and ignore the security context URL entirely and always unconditionally pass "about:internet" for any URL that does not contain an authority component, but this will cause some downloads to behave differently than they do today.

Project Member Comment 11 by sheriffbot@chromium.org, May 26 2016
Labels: -M-50 M-51
I'm not entirely sold on there being a reliable solution involving IAttachmentExecute. The last time I dug in there, it seemed that the decision to annotate was a function of source, referrer, danger level of the file type, trustworthiness of the application associated with said file type, effective security zone and policies thereof. I'm sure I'm missing something, but overall the sense I got after dealing with this the last time is that the non-specificity of the documentation is intentional. I trust that "about:internet" will work as you say it does, but I still couldn't find documentation stating so. The only relevant thing I found was that in the absence of a source or referrer, IAE will assume the file came from the "restricted" zone.

This issue makes the assumption that MOTW is a critical security feature to the extent that its omission constitutes a vulnerability. Consequently it seems what we are doing here is trying to come up with a set of inputs that'll yield a deterministic outcome from IAE. I'd argue that coming up with such a set of inputs in a future proof manner isn't feasible. After all this, if IAE decides not to apply a MOTW to an executable, is that considered OK (see issue 355810)?

I can write up a CL for determining a more appropriate source (or referrer) urls for downloads and pass those along to IAE, but I think we should reconsider how we use IAE ( Issue 601187 ).

By the way, has anyone independently verified this behavior? Passing in data: URLs to IAE seems to work as expected on the machines I've looked at. There doesn't seem to be anything special in their zone configuration.
Comment 14 by f...@chromium.org, Jun 1 2016
Cc: nparker@chromium.org
+nparker, this seems like a SB-related thing
Status: Started
https://codereview.chromium.org/2025103002 (waiting for review)
Project Member Comment 16 by sheriffbot@chromium.org, Jul 21 2016
Labels: -M-51 M-52
I see asanka is OOO for the month but has a patch up: https://codereview.chromium.org/2025103002 

It looks like he was waiting for elawrence to take a look. elawrence: perhaps you can review the patch?
The patch looks reasonable to me. I've pinged my URLMon contacts to confirm that "about:internet" is as reliable as I think, and pinged MSVR about the repro url (which is presently down).
MSVR put the repro back online and I spent some time walking through the repro in the debugger. 

Stepping through the code of the repro, I see that the call to attachment_services->SetSource() fails with hr=0x80070057 (E_INVALIDARG). Within Chrome, BaseFile::AnnotateWithSourceInformation gets back the HR from the SetSource() but it discards it because the target file was not deleted by the attachment_services.

Probing this (on Windows 7), I find that the problem isn't use of the data: protocol, but it's instead caused by the fact that internally SetSource fails if the passed string is longer than INTERNET_MAX_URL_LENGTH 2083 characters. Notably, this limitation is NOT mentioned in the MSDN documentation for the method (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb776306(v=vs.85).aspx). Data URLs shorter than 2083 are properly tagged Internet Zone.

Thus, the problem here is more general than just long Data URIs; you can evade MotW tagging for HTTPS Urls as well; see e.g. https://whytls.com/longurl.htm. This problem does not appear to affect IE11 or Edge largely because neither of these browsers can reliably Download files from URLs of that length (https://blogs.msdn.microsoft.com/ieinternals/2014/08/13/url-length-limits/).

While I think the CL in #17 is probably still a good idea, it's not complete; we should consider handling overlong URLs explicitly, and I think AVScanFile should check for (FAILED(hr)) in all 3 calls to attachment_services and in the event that ANY fail, it should call SetInternetZoneIdentifierDirectly(full_path);

-= OTHER BROWSERS =-
Brave 0.11.4 is vulnerable.
Vivaldi 1.3.551.30 is vulnerable.
Opera 41.0.2315.0 is vulnerable.
Firefox 48 is not vulnerable.

Project Member Comment 20 by sheriffbot@chromium.org, Sep 1 2016
Labels: -M-52 M-53
I believe this is now fixed by https://codereview.chromium.org/2025103002/, right?
Project Member Comment 22 by bugdroid1@chromium.org, Sep 26 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6ef77adf8c1f6ab03e8614646275d22b4fa3f448

commit 6ef77adf8c1f6ab03e8614646275d22b4fa3f448
Author: asanka <asanka@chromium.org>
Date: Mon Sep 26 21:36:40 2016

Use better fallback URLs when calling AVScanFile().

Windows Attachment Services defaults to treating downloads of data: URLs
and other unknown URL schemes as being trustworthy. In addition, source URLs
that are longer than INTERNET_MAX_URL_LENGTH could also cause the
mark-of-the-web to not be applied.

This CL attempts to mitigate these cases by changing base_file_win.cc to
use the referrer URL if one is available and is either http or https.
Furthermore, if the source URL is too long or is empty,
quarantine_win.cc will use the safe fallback "about:internet" as the
source URL.

In addition, quarantine_win.cc now also sets the Referrer field if a
valid referrer is found.

BUG= 601538 

Review-Url: https://codereview.chromium.org/2025103002
Cr-Commit-Position: refs/heads/master@{#421000}

[modify] https://crrev.com/6ef77adf8c1f6ab03e8614646275d22b4fa3f448/content/browser/download/base_file.cc
[add] https://crrev.com/6ef77adf8c1f6ab03e8614646275d22b4fa3f448/content/browser/download/base_file_win_unittest.cc
[modify] https://crrev.com/6ef77adf8c1f6ab03e8614646275d22b4fa3f448/content/browser/download/quarantine_win.cc
[modify] https://crrev.com/6ef77adf8c1f6ab03e8614646275d22b4fa3f448/content/browser/download/quarantine_win_unittest.cc
[modify] https://crrev.com/6ef77adf8c1f6ab03e8614646275d22b4fa3f448/content/test/BUILD.gn

Status: Fixed
Labels: reward-NA
Project Member Comment 25 by sheriffbot@chromium.org, Sep 28 2016
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Comment 26 by wfh@chromium.org, Nov 4 2016
Cc: m...@microsoft.coma
adding msvr@microsoft.com as per comment #0
Cc: -m...@microsoft.coma m...@microsoft.com
Labels: -M-53 M-55
Project Member Comment 29 by sheriffbot@chromium.org, Nov 5 2016
Labels: Merge-Request-55
Comment 30 by dimu@chromium.org, Nov 5 2016
Labels: -Merge-Request-55 Merge-Review-55 Hotlist-Merge-Review
[Automated comment] Commit may have occurred before M55 branch point (10/6/2016), needs manual review.
Cc: awhalley@chromium.org
Labels: -Merge-Review-55
M55 was branched on oct 6th at Chromium revision 423768. CL listed at #22 landed on September 26th {#421000}, so no merge is needed here. Removing "Merge-Review-55" label. 
Labels: -Hotlist-Merge-Review
Labels: Release-0-M55
Labels: CVE-2016-5214
Project Member Comment 35 by sheriffbot@chromium.org, Jan 4 2017
Labels: -Restrict-View-SecurityNotify allpublic
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Sign in to add a comment