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 4 users

Issue metadata

Status: Fixed
Owner:
Closed: Jul 2018
Cc:
Components:
EstimatedDays: ----
NextAction: 2018-09-25
OS: Linux , Android , Windows , Chrome , Mac , Fuchsia
Pri: 1
Type: Bug-Security

Blocked on:
issue 827083
issue 831073
issue 848531
issue 848535
issue 849820


Participants' hotlists:
x..


Sign in to add a comment
link

Issue 848123: Cross-origin-read attack by chaining three vulnerabilities

Reported by luan.her...@hotmail.com, May 31 2018

Issue description

VULNERABILITY DETAILS
By combining three vulnerabilities it's possible to read data from cross-origin websites when an user opens a local HTML file.

The following vulnerabilities are being chained in this attack:
1. Simulating an Alt-Click (click with the alt key pressed) through javascript allows the download of cross-origin resources.
2. Using history.back() allows the download of multiple files without the need to give permission to the page.
3. File urls are considered same-origin amongst themselves, allowing any local resource to be re-downloaded with a new name and extension through the use of the download attribute.

The only requirement to perform this attack is that the targeted website must have an endpoint which contains user-controlled input (this happens in almost any API). For example, https://issuetracker.google.com and https://bugzilla.mozilla.org are both vulnerable.

The exploit works as follows:
1. Attacker makes an endpoint contain a script tag (in the example displayed in the video, the attacker reports a bug to a HackerOne program with the title <script>...</script>).
2. Later, the attacker sends the malicious page to a triager of the program (someone with access to reported bugs).
3. Triager downloads and opens the malicious HTML file containing the attacker's script.
4. By simulating an alt-click the script downloads https://hackerone.com/bugs.json with the default name of "response.json" (note that we can't control the name nor the extension of the downloaded file because it's a cross-origin resource).
5. By using history.back() the attacker re-downloads "response.json". This time from the Downloads folder instead of /bugs.json. We do this because all local files are same-origin resources, permitting the use of the download attribute to change the filename to "injection.html".
6. The script redirects the user to "injection.html" and the script tag that was inserted earlier is now executed, allowing the attacker to exfiltrate the information contained in https://hackerone.com/bugs.json.

Because the PoC exfiltrates information from a private program on HackerOne you will not be able to reproduce it. But if needed, I can create another PoC that doesn't use HackerOne.

I have also attached a reproduction case for each individual vulnerability used.

And here is a video simulating the attack:
https://www.youtube.com/watch?v=67nWiqIl5bc
 
VERSION
Chrome 67.0.3396.62  (Official Build) stable (64-bit)
Chrome 68.0.3440.7   (Official Build) dev    (64-bit)

REPRODUCTION CASE
simulate.html: Downloads cross-origin resources.
download.html: Bypasses the download limit restriction.
change.html:   Downloads local file with different name and extension.
bug.html:      Full PoC that is used in the video.
 
simulate.html
562 bytes View Download
download.html
378 bytes View Download
change.html
339 bytes View Download
bug.html
1.5 KB View Download

Comment 1 by luan.her...@hotmail.com, May 31 2018

Oops, I missed the back.html file (must be on the same folder as download.html).
back.html
118 bytes View Download

Comment 2 by elawrence@chromium.org, May 31 2018

Thanks for the report! A working PoC would probably be better for reproducing the issue than a POC that does not work.

Use of a simulated Alt+Click sounds like a circumvention of the protections introduced in  Issue 608669 .

> all local files are same-origin resources

In Chrome, this isn't supposed to be the case, but it sounds like you may have found a case where it is unexpectedly so.

Chrome might also consider blocking local files from triggering "Download" of other local files, which was deemed innocuous in  Issue 827083 .

Comment 3 by luan.her...@hotmail.com, May 31 2018

Hi Eric,

I will be creating a new PoC then.

About local files not being same-origin, I thought that was the case because on m67 we can download local files and use the download attribute to set a new name (which should only be possible between same-origin resources).

Comment 4 by luan.her...@hotmail.com, May 31 2018

Here is the new PoC:
https://lbherrera.github.io/lab/cross-read/start.html

To reproduce it you must click on the click and then open the automatically downloaded HTML file.

Assume that https://bharl.github.io/test/dummy.json is the targeted cross-origin endpoint where the attacker inserted his malicious script tag and wants to steal the information from.

Comment 5 by luan.her...@hotmail.com, May 31 2018

I gave this more thought and realized this vulnerability can also be used to exploit previously "unexploitable" XSSes that would otherwise been blocked by CSP or the XSS Auditor.

Granted this can't be used to steal a user session, but it could be used to exfiltrate CSRF tokens as well as any private information that was rendered in the page at the time of the download.

You can reproduce it here:
https://lbherrera.github.io/lab/cross-read/bypass.html

Comment 6 by mea...@chromium.org, Jun 1 2018

Labels: Security_Severity-Medium Security_Impact-Stable OS-Android OS-Chrome OS-Fuchsia OS-Linux OS-Mac OS-Windows
This bug requires a few preconditions, so assigning medium severity (the site must allow user input and the user needs to open the downloaded file).

I'll split the bugs.

Comment 7 by mea...@chromium.org, Jun 1 2018

Blockedon: 848531

Comment 8 by mea...@chromium.org, Jun 1 2018

Blockedon: 848535

Comment 9 by mea...@chromium.org, Jun 1 2018

Blockedon: 827083

Comment 10 by mea...@chromium.org, Jun 1 2018

Cc: dtrainor@chromium.org
Components: UI>Browser>Downloads

Comment 11 by luan.her...@hotmail.com, Jun 1 2018

Hi meacer,

While it's true that the site must allow user input, the practice is extremely common, even more so for websites that use any kind of API. I feel the severity is closer to high than medium given the user is one click away from having confidential information stolen. Additionally, simply opening a HTML file is not generally seen as an attack vector, even among technical users (no warnings are shown, for example).

I personally feel this hasn't the same severity as  Issue 608669 , which requires the victim not only to open a local HTML file, but also upload it to the attacker's website. Finally, my attack can also exfiltrate information from dozens of websites in only one go, which  Issue 608669  doesn't allow.

What do you think?

Comment 12 by sheriffbot@chromium.org, Jun 1 2018

Project Member
Labels: M-67

Comment 13 by sheriffbot@chromium.org, Jun 1 2018

Project Member
Labels: Pri-1

Comment 14 by gov...@chromium.org, Jun 1 2018

Cc: awhalley@chromium.org
+awhalley@ (Security TPM)

Comment 15 by gov...@chromium.org, Jun 1 2018

Cc: pbomm...@chromium.org creis@chromium.org nasko@chromium.org

Comment 16 by mea...@chromium.org, Jun 1 2018

Cc: asanka@chromium.org
> While it's true that the site must allow user input, the practice is extremely common, even more so for websites that use any kind of API. I feel the severity is closer to high than medium given the user is one click away from having confidential information stolen. 

Yes, this is admittedly a low bar. But:

> Additionally, simply opening a HTML file is not generally seen as an attack vector, even among technical users (no warnings are shown, for example).

Quoting asanka from https://bugs.chromium.org/p/chromium/issues/detail?id=780770#c9:

"""
So to address the question in #4, marking all downloads that run JS was in fact what we were doing in the past. But mitigations around treating file:// origins as unique in Chrome was considered sufficient to no longer consider downloaded HTML as being dangerous. Where scripts are not run such mitigations in place (e.g. .js files that could be executed with external script engines) downloads continue to be considered dangerous.

I don't think considering HTML to be dangerous again would help in this case. The chain already requires user interaction unless the user has configured HTML as a file type that opens automatically.
"""

So we consider local HTML files non-dangerous, but the user opening them is still a mitigation. I don't have a strong opinion about the severity though. If anyone disagrees and wants to raise this to high, that's okay with me.

Comment 17 by jochen@chromium.org, Jun 4 2018

Cc: rbyers@chromium.org
+rbyers who I recently talked to about site initiated downloads

Comment 18 by luan.her...@hotmail.com, Jun 5 2018

On the past few days I made two discoveries:

1. A redirect also bypasses the protections introduced in  Issue 608669 , allowing resources to be downloaded cross-origin. Should I file another bug report on this? I don't know if the root cause is the same as the alt+click bypass (If I had to guess I would say they are unrelated).

// redirect.php
<?php
header("Location: ".$_GET["url"], true, 301);
exit;
?>

// index.html
<a href="redirect.php?url=http://google.com" download>Cross-origin download</a>

2. I also created a PoC which can trick users into opening local HTML files (or other files) by abusing a clickjacking vulnerability.

It can be reproduced here (although it will probably be misaligned because I only had my screen resolution in mind):
https://lbherrera.github.io/lab/game-read/

And here's a video simulating the full attack (clickjacking + cross-origin read):
https://www.youtube.com/watch?v=6cz2J6KGVoU

Should I also file another bug report about this?

Comment 19 by jochen@chromium.org, Jun 5 2018

Comment 20 by palmer@chromium.org, Jun 5 2018

Labels: -M-67 M-68
Owner: asanka@chromium.org
Status: Assigned (was: Unconfirmed)
The repro in #5 works for me. I think Medium is the right severity; High is defined (https://chromium.googlesource.com/chromium/src/+/master/docs/security/severity-guidelines.md#High-severity) as "A bug that allows full circumvention of the same origin policy. Universal XSS bugs fall into this category, as they allow script execution in the context of an arbitrary origin".

It's a large value of Medium, though. :)

asanka, you seem to be the main Downloads OWNER, is that right? Can you please see this family of bugs through, and/or help find other people? Thanks.

67 is out the door and this is a complicated suite of bugs, so I'm bumping the Milestone to 68. It'd be great if we could make that.

Comment 21 by palmer@chromium.org, Jun 5 2018

Blockedon: 831073

Comment 22 by mea...@chromium.org, Jun 5 2018

Blockedon: 849820

Comment 23 by mea...@chromium.org, Jun 5 2018

Just in case we want to do something about the clickjacking attack in Comment #18, I filed bug 849820. (another variant of it that uses the download shelf is bug 636974)

Comment 24 by luan.her...@hotmail.com, Jun 5 2018

Is Bug 780770 about dropping javascript files inside the Downloads folder? Because reading asanka's quote made me realize that websites that load external javascript from the root folder and are using relative path are also vulnerable to this attack.

Which is relevant because even after all the bugs that I reported are fixed, the attacker will still be able to drop javascript files inside the Downloads folder and when/if an user saves a page to the Downloads folder and opens it, the attacker's script will end up being executed. This might be something worth fixing (if possible at all).

Comment 25 by asanka@chromium.org, Jun 6 2018

Owner: dtrainor@chromium.org
dtrainor@ is the new downloads TL. Passing along to him. I'd be happy to help as well.

Comment 26 by dtrainor@chromium.org, Jun 7 2018

Cc: qin...@chromium.org

Comment 27 by dtrainor@chromium.org, Jun 7 2018

Taking a look thanks!  Will work to get this in by 68!

Comment 28 by qin...@chromium.org, Jun 7 2018

for #24, i think we have to also think about the normal cases.
For example, a lot of crbug reports contain both javascript and html files, if we don't allow the javascript to run when opening the html file after download, then it will put a lot of extra effort to reproduce those issues.

Comment 29 by luan.her...@hotmail.com, Jun 7 2018

asanka@: About your comment on  Bug 827083 , it seems the behavior you described is only true for m67.

On m68, simply using the download attribute on an anchor tag already redirects the user to the file:// URL instead of downloading it.

The behavior on m68 only changes when the alt+click bypass starts the download, in which the file:/// URL will be downloaded with the new name and extension.

Comment 30 by dtrainor@chromium.org, Jun 12 2018

@29 - Your PoC looks like it simulates an alt click on the download, but I'm not seeing injection.html created in the download folder (instead it navigates to dummy.json like you said in @29).  Is this particular step in the flow fixed or is it still useful in the attack chain?

Comment 31 by luan.her...@hotmail.com, Jun 13 2018

It seems a change was made on m69 which prevents the alt+click bypass from being able to download cross-origin resources (breaking the attack chain), but I wouldn't know which change did that. Prior to comment 29 I had only tested on m66, m67 and m68. One thing that I found strange while testing is that non-simulated alt+clicks on anchor tags with the download attribute are still allowed to download cross-origin files with different names/extensions, even on Canary.

Comment 32 by dtrainor@chromium.org, Jun 13 2018

Thanks!  Will try to track down the relevant change.

Comment 33 by dtrainor@chromium.org, Jun 19 2018

Cc: dpa...@chromium.org

Comment 34 by dpa...@chromium.org, Jun 19 2018

Cc: dbeam@chromium.org

Comment 35 by luan.her...@hotmail.com, Jun 30 2018

dtrainor@: I did some digging and found the relevant change that broke the attack chain: https://chromium.googlesource.com/chromium/src/+/4379a7fcff8190aa7ba72307b398161c32102c52

Comment 36 by sheriffbot@chromium.org, Jul 3 2018

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

Comment 37 by sheriffbot@chromium.org, Jul 17 2018

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

Comment 38 by luan.her...@hotmail.com, Jul 30 2018

Can I get access to  issue 848531 ?

Comment 39 by awhalley@chromium.org, Jul 30 2018

luan.herrera@ - added you to that issue, thanks

Comment 40 by luan.her...@hotmail.com, Jul 31 2018

awhalley@: Thanks!

Seeing all issues were fixed with exception of issue 849820 I was wondering if this bug can be marked as fixed given issue 849820 isn't really an issue blocking the chain described in this attack but rather just a way to trick the user into opening a local file, which can be achieved in several ways, such as demonstrated in issue 63773 and issue 636974.

Comment 41 by awhalley@google.com, Jul 31 2018

Status: Fixed (was: Assigned)
re comment 40 - sounds reasonable. Marking as fixed.

Comment 42 by sheriffbot@chromium.org, Aug 1

Project Member
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify

Comment 43 by awhalley@chromium.org, Aug 7

Labels: reward-topanel

Comment 44 by sheriffbot@chromium.org, Aug 8

Project Member
Labels: Merge-Request-69

Comment 45 by sheriffbot@chromium.org, Aug 8

Project Member
Labels: -Merge-Request-69 Merge-Review-69 Hotlist-Merge-Review
This bug requires manual review: M69 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), kariahda@(iOS), cindyb@(ChromeOS), govind@(Desktop)

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

Comment 46 by gov...@chromium.org, Aug 8

awhalley@ (Security TPM) for M69 merge review

Comment 47 by awhalley@google.com, Aug 9

Labels: -Merge-Review-69 Merge-Rejected-69
Tracking any merges in the child bugs, no merges needed for this bug.

Comment 48 by awhalley@chromium.org, Aug 13

Labels: -reward-topanel reward-unpaid reward-2000
*** 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.
*********************************

Comment 49 by awhalley@google.com, Aug 13

Hi luan.herrera@! The VRP panel decided to award $2,000 for this report - thanks!

Comment 50 by awhalley@google.com, Aug 13

Labels: -reward-unpaid reward-inprocess

Comment 51 by luan.her...@hotmail.com, Aug 14

Hi again awhalley@!

I started writing down about this attack chain for an upcoming article that I plan to release when the Stable version comes out and I realized that I missed some key points that the panel might have also overlooked.

At first I didn't give too much attention about the bug's ability to re-download local files with different names and extensions, but this essentially also allows an attacker to steal local files if they can somehow inject their malicious javascript code into them.

Knowing this I decided to look which local Chrome files could be remotely altered by the attacker and found a few (there are others but for brevity I will omit them, also, they are not as relevant as the ones below):

/home/user/.config/google-chrome/Default/History
/home/user/.config/google-chrome/Default/Web Data
/home/user/.config/google-chrome/Default/Network Action Predictor

Redirecting an user to "http://example.com/<script>...</script>" for example, would add this URL to their browsing history and consequently to their local Chrome history file, which then could be downloaded by the attacker, renamed to injection.html and forced to be opened by the victim. This would then execute the attacker controlled javascript, allowing all of the user's history to be stolen.

Username/passwords in GET parameters, SSO tokens, CSRF tokens, secret gists/pastebins/videos/images, all this and much more would be leaked.

Also (I imagine you guys already know this, but wasn't mentioned before by me), it's possible to launch this attack from a locally opened pdf instead of a html file. Albeit the technical distinction between these two aren't that big, for a common user, I think opening a pdf file would appear less threatening.

In light of these new discoveries, would be possible for this report to be revaluated by the panel? If a new PoC is deemed necessary I can create and provide one.

Thanks again!

Comment 52 by luan.her...@hotmail.com, Aug 15

Oops, redirecting the user to "http://example.com/<script>...</script>" would not do the trick because the URL is actually encoded before being saved.

Instead, the attacker would need to create a page, set the title of the page to their payload and then redirect the user to it (the title of the page is saved inside the Chrome history file without being escaped).

Also, I noticed that the Cookies file can also be stolen by this attack. I am not familiar with the details behind it but it seems the cookies are encrypted using the computer's password as a key. I think it would be possible for an attacker to download and bruteforce it offline.

Comment 53 by awhalley@google.com, Aug 16

Labels: reward-topanel

Comment 54 by awhalley@chromium.org, Aug 27

Labels: -reward-topanel
Hi luan.herrera@ - thanks for the additional details. The VRP panel took another look at this, and decided to keep the reward amount at 2k, I'm afraid. Cheers!

Comment 55 by luan.her...@hotmail.com, Sep 4

Seems this bug is missing in the release notes :(

Comment 56 by awhalley@google.com, Sep 5

Apologies, this has been fixed.

Comment 57 by luan.her...@hotmail.com, Sep 5

awhalley@: When would you feel comfortable with me publishing an article about this chain of bugs? Do you think waiting one week for users to update would suffice?

Comment 58 by awhalley@google.com, Sep 5

Would waiting until the 25th be OK? That's two weeks after the Chrome OS release date.

Comment 59 by luan.her...@hotmail.com, Sep 5

Sure, no problem.

Comment 60 by awhalley@google.com, Sep 5

NextAction: 2018-09-25

Comment 61 by monor...@bugs.chromium.org, Sep 25

The NextAction date has arrived: 2018-09-25

Comment 62 by sheriffbot@chromium.org, Nov 7

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