Note: Cannot repro from a Corp Profile due to admin-controlled permissions blocking.

In the report I focused on the dangerous file check bypass (arbitrary code execution outside the sandbox).

Perhaps it is also worth noting that the vulnerable method can also be used to write to arbitrary files. Combined with the ability to read local files (bug 805557) and vulnerabilities to crash or restart Chrome, this could be used to modify Chrome's configuration files to unlock more powers, persistently.

If there is a higher reward for it, I'm willing to develop a PoC exploit.

When I run the repro on Windows 10, I get a Windows security warning dialog for the vbs file. Is the idea to bypass that dialog?

^ I see this on 64.0.3282.119 stable, by the way.

@#3 That is a warning from Windows (which may or may not show, depending on the configuration of "SaveZoneInformation"). If you see the warning then it means that Chrome is already attempting to run the program.

Another way to see that Chrome's defence has failed is to run the following from the extension background's console:
   chrome.downloads.search({}, console.log);

... and observe that the "danger" key of the download is "safe" (https://developer.chrome.com/extensions/downloads#type-DangerType).

I'm aware it's the mark-of-the-web dialog from Windows, hence my question about whether it was expected to be bypassed as well, because that's what the video implies :)

I'd like to get an opinion from SafeBrowsing before assigning severity to this, but this seems low severity given the significant user interaction required to run the executable (extension install + accepting OS warning).

Severity-low underestimates the severity of this bug. I expected High severity.


> my question about whether it was expected to be bypassed as well

It depends on the configured SaveZoneInformation policies [1]. In my Windows 7 VM, there were no OS warnings, until I remove HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Associations\LowRiskFileTypes (which contained ".vbs").
I have modified the PoC to use .url instead of .vbs. Now my Windows 7 VM launches mspaint again without warnings (see attachment).

MOTW can also be bypassed by saving the file to a filesystem that does not support Alternate Data Streams (ADS), such as a FAT32-formatted USB stick or a network drive. An attacker can either guess the location (or enumerate local drives (e.g. with bug 805557) to find such a location), and use the vulnerable method to write a file to that location.


> low severity given the significant user interaction ... (extension install + accepting OS warning).

Because of the Extension install requirement, I would drop the severity from Critical (escaped sandbox) to High.

The OS warning is Windows-specific and optional (see above).
On Linux, when I launch the above PoC, a text editor is opened via xdg-open (default handler of .vbs), but it could have been any other program or interpreter.

[1] https://support.microsoft.com/en-us/help/883260/information-about-the-attachment-manager-in-microsoft-windows

Deleted: debugger-downloadBehavior-v2.zip 1.8 KB

debugger-downloadBehavior-v2.zip 1.8 KB Download

As I remarked in  https://bugs.chromium.org/p/chromium/issues/detail?id=805905#c8 , the Page.setDownloadBehavior method was primarily designed for headless Chrome, so disabling this method for non-headless Chrome sounds like the best fix to me.

It would be useful to mention that you were testing on Windows 7. I tested with multiple VMs Microsoft offers at https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/. Using the PoC v2 in comment #9:
- IE8 on Win7, IE9 on Win7, IE10 on Win7: No MOTW warning.
- IE11 on Win7, IE11 on Win8 : MOTW warning is displayed.

All Win7 VMs have Windows 7 Enterprise edition (Build 7601: Service Pack 1) for VirtualBox. None of them have the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Associations\LowRiskFileTypes entry. I suspect the IE version makes a difference here. Can you please try with a VM that has IE11? (that's the only supported IE version at the moment)

Also, I'm well aware MOTW isn't supported on FAT32, but all Windows versions supported by Chrome (Windows 7 and above) default to NTFS installations. Downloading to a FAT32 filesystem is a non-default configuration, because it would either require changing default OS installation or the default download directory.

> On Linux, when I launch the above PoC, a text editor is opened via xdg-open (default handler of .vbs), but it could have been any other program or interpreter.

SafeBrowsing doesn't mark .vbs files as dangerous on Linux anyways [1], so bypassing it doesn't gain anything to the attacker. This isn't different than just using chrome.download.open to open the .vbs file on Linux.

We also discussed this offline, and if there is a reliable bypass of the MOTW warning via devtools, we are happy to reconsider the severity. But currently the only bypass is SafeBrowsing dangerous file types mark, which we'd consider a medium severity on its own. The fact that an extension with powerful permissions is required to use this bypass and that only a subset of users on old, unsupported OS configurations is directly impacted, I think low severity is appropriate.

[1] https://cs.chromium.org/chromium/src/chrome/browser/resources/safe_browsing/download_file_types.asciipb?rcl=694bf0eb3c5de0a290054716b548e4cadf9284ee&l=1395

ericlaw@ pointed that ReFS on Win8 didn't support MoTW either, and that's not an unsupported configuration. With that information, raising this back to severity-medium. I still maintain that severity-high is too high here, because of the two separate mitigating factors (extension install and MOTW on most configs) but I'll leave it to the next sheriff to decide whether this is a fair assessment.

dvallet: Can you please take a look?

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

commit 81ad563077484d112e544347da87c09dd2ba0af8
Author: David Vallet <dvallet@chromium.org>
Date: Wed Jan 31 05:50:14 2018

Always mark content downloaded by devtools delegate as potentially dangerous

Bug:  805445 
Change-Id: I7051f519205e178db57e23320ab979f8fa9ce38b
Reviewed-on: https://chromium-review.googlesource.com/894782
Commit-Queue: David Vallet <dvallet@chromium.org>
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#533215}
[modify] https://crrev.com/81ad563077484d112e544347da87c09dd2ba0af8/content/browser/devtools/protocol/devtools_download_manager_delegate.cc

pfeldman: 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

dvallet: Can this be closed now? Thanks.

I have reported two issues,
- safe browsing bypass - fixed.
- writing to arbitrary locations - not fixed yet.

The combination of the two increases the likelihood of a MOTW bypass, because an attacker can write to a filesystem that does not support MOTW, such as a (FAT32-formatted) USB stick.

We are working on a new interface for downloads: https://crrev.com/c/861546
Once it lands, we'll remove the download path option.

pfeldman: Uh oh! This issue still open and hasn't been updated in the last 30 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

This bug requires manual review: M66 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), josafat@(ChromeOS), abdulsyed@(Desktop)

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

This was fixed before the M66 branch point.

*** Boilerplate reminders! ***
Please do NOT publicly disclose details until a fix has been released to all our users. Early public disclosure may cancel the provisional reward. Also, please be considerate about disclosure when the bug affects a core library that may be used by other products. Please do NOT share this information with third parties who are not directly involved in fixing the bug. Doing so may cancel the provisional reward. Please be honest if you have already disclosed anything publicly or to third parties. Lastly, we understand that some of you are not interested in money. We offer the option to donate your reward to an eligible charity. If you prefer this option, let us know and we will also match your donation - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing.
*********************************

And $2,000 for this one - cheers!

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

(note that even though this was fixed before M66 branch point, it should have retained the M-66 label)