Download Protection: WEBLOC and WEBBOOKMARK files are not checked on Mac OS
Reported by
resea...@nightwatchcybersecurity.com,
Apr 6 2016
|
|||||||
Issue descriptionThis template is ONLY for reporting Download Protection Bypass bugs within Chrome and is not for requesting a review of sites or binaries identified as malicious. VERSION Chrome Version: 49.0.2623.87 Official Build Operating System: Mac OS X El Capitan, version 10.11.3 REPRODUCTION CASE WEBLOC and WEBBOOKMARK files are shortcuts to Internet sites. WEBLOC is opened by both Safari and Chrome, and WEBBOOKMARK is opened by Safari. These are not being checked by Chrome, while .URL is. The behavior should match. In theory it would be possible to put malicious Javascript in these files, plus WEBBOOKMARK can be binary. Sample file: https://github.com/sindresorhus/shortcut-url-cli/blob/master/fixture/google.webloc You can rename this file as WEBBOOKMARK and it will open in Safari. To get a binary file, drag a Safari bookmark to the Mac Desktop. We can try to make a patch if covered under Patch Rewards.
,
Apr 6 2016
,
Apr 22 2016
We did some more testing, and confirmed that Safari does not allow Javascript to be executed from a bookmark. The best use case we have now is a download URL being stored inside a WEBBOOKMARK file which would trigger an automatic download in Safari - essentially using Safari to bypass Chrome's Safe Browsing. This would need the user to click first on the WEBBOOKMARK file, and then second on the downloaded file, so we are unclear if enough friction is present or not, as far as VRP is concerned. Here is a POC for WEBBOOKMARK with an intermediate page shown: https://theowl.xyz/cr/600910/test1.webbookmark Here is a second POC which just triggers the download: https://theowl.xyz/cr/600910/test3.webbookmark This file is downloaded: https://dl.google.com/chrome/mac/stable/GGRO/googlechrome.dmg For the WEBLOC case, Chrome also autodownloads the file BUT, since Chrome would open the bookmark, Safe Browsing would kick in if they downloaded an unsafe file.
,
May 6 2016
,
May 13 2016
Just wondering if this issue is still being looked at
,
May 27 2016
Thanks for reporting the issue and the detailed analysis. Please see my replies to your posts. > This would need the user to click first on the WEBBOOKMARK file, and then second on the downloaded file This exploit relies on the user to use a different web browser (Safari, in this case). If the user does that, there's little that Chrome can do beyond that. > For the WEBLOC case, Chrome also autodownloads the file BUT, since Chrome would open the bookmark, Safe Browsing would kick in if they downloaded an unsafe file. That's true, which makes this case as WorkingAsIntended.
,
May 29 2016
Being that Safari is always installed on Mac OS just like IE is on Windows, an argument could be made that the exploit will always work.
,
Jun 3 2016
Yes, but that's outside the scope of Chrome's threat model.
,
Mar 9 2017
,
Mar 10 2017
For all Download Protection VRP bugs: removing label Restrict-View-Google and adding Restrict-View-SecurityTeam instead.
,
Mar 11 2017
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 |
|||||||
Comment 1 by nparker@chromium.org
, Apr 6 2016