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: Feb 2013
Cc:
EstimatedDays: ----
NextAction: ----
OS: All , Mac
Pri: 2
Type: Bug-Security



Sign in to add a comment
link

Issue 173906: document.referrer leakage with XSS Auditor page block

Reported by homakov@gmail.com, Feb 3 2013

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.101 Safari/537.11

Steps to reproduce the problem:
1. http://homakov.blogspot.com/2013/02/hacking-with-xss-auditor.html
2. 
3. 

What is the expected behavior?

What went wrong?
http://homakov.blogspot.com/2013/02/hacking-with-xss-auditor.html

Did this work before? N/A 

Chrome version: 23.0.1271.101  Channel: n/a
OS Version: OS X 10.8.2
 

Comment 1 by scarybea...@gmail.com, Feb 3 2013

Owner: tsepez@chromium.org
Interested in triaging, Tom?

Comment 2 by tsepez@chromium.org, Feb 3 2013

Reporter is saying that for pages which contain mode=block; it is trivial to fake an injection by including part of the page in an unused URL paramater (we do this for testing all the time), and that the final result is an about:blank page.  Do this in an iframe, and the about:blank page inherits the parent's origin.  Clever.

I've not tried it, but I'm reasonably certain this works based upon the explanation.

The fix is to give the page a unique origin (in the shouldTreatAsUniqueOrigin() sense).  I'm not sure we can do that with about:blank, so we may have to move this to another palce.

Comment 3 by tsepez@chromium.org, Feb 3 2013

Cc: abarth@chromium.org

Comment 4 by homakov@gmail.com, Feb 3 2013

Yes. But technically it's not compulsory to change origin because *only* leaking and precious value is document.referrer. If we could steal POST params from action=about:blank it would be much more dangerous..
Thus I think working around by clearing document.referrer will simplify the fix

Comment 5 by homakov@gmail.com, Feb 3 2013

Not only mode=block  btw
i can make action=about:blank for any form and trick user to click submit, then obtain document.referrer

Comment 6 by abarth@chromium.org, Feb 4 2013

Yeah, we should put the blocked page into a unique origin.

Comment 7 by tsepez@chromium.org, Feb 4 2013

@homakov - FYI, this bug might have been eligible for an award under the chrome vulnerabilities reward program had it been reported to us directly, but is no longer eligible since you have already blogged about it.  Next time, see http://www.chromium.org/Home/chromium-security/reporting-security-bugs and http://www.chromium.org/Home/chromium-security/vulnerability-rewards-program if you'd like to be considered for an award.

Comment 8 by homakov@gmail.com, Feb 4 2013

really? hypothetically what would reward be lol

Comment 9 by cdn@chromium.org, Feb 4 2013

Labels: SecImpacts-Stable SecImpacts-Beta SecSeverity-Low OS-All Mstone-24
Status: Assigned

Comment 10 by homakov@gmail.com, Feb 5 2013

sev low? I just wrote exploit to steal any access_token from any client_id which facebook user authorized. This is a big deal: private info, posting on wall etc.
P.S. since im not getting bounty is there a way to forward that money to charity :) and, hall of fame, no?

Comment 11 by tsepez@chromium.org, Feb 5 2013

No, once it's been publicly disclosed, all this is off the table.  Since it was subsequently triaged as severity low, it is unlikely it would have met the criteria.

Comment 12 by tsepez@chromium.org, Feb 5 2013

No, once it's been publicly disclosed, all this is off the table.  Since it was subsequently triaged as severity low, it is unlikely it would have met the criteria.

Comment 13 by homakov@gmail.com, Feb 5 2013

ok, good to know. (i created another bug about switching off auditor for location fragment)

Comment 14 by scarybea...@gmail.com, Feb 5 2013

@tsepez: given that it sounds like this enables theft of certain types of token, I wonder if Medium severity might be appropriate?

Comment 15 by homakov@gmail.com, Feb 5 2013

up to you but.. There are lots of OAuth2 implementation and Single Sign On that allows to bounce user back with custom payload. Custom payload is code from final page. Stolen token = stolen account.

This is PoC for facebook auth + chrome. Choose any app user has authorized previously and steal his private data, access_token, post on the wall etc: https://gist.github.com/homakov/38da08536f710cb39a4c

Comment 16 by homakov@gmail.com, Feb 5 2013

sure, i already reported facebook about the critical vulnerability. My post on blogspot doesn't disclose real world vulnerabilities, i will publish them only when all of them will be fixed.

Comment 17 by tsepez@chromium.org, Feb 5 2013

@abarth: how about navigating to something like "data:text/html,Blocked by XSSAuditor" instead of about:blank?

Comment 18 by homakov@gmail.com, Feb 5 2013

@tsepez how does X-Frame-Options block work? Because it looks just same - redirect to about:blank but referrer is not accessible? Is there any trick used for it? It could be same here

Comment 20 by tsepez@chromium.org, Feb 7 2013

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Status: Fixed
Fixed in http://trac.webkit.org/changeset/142063

Comment 21 by scarybea...@gmail.com, Feb 7 2013

Labels: Merge-Approved reward-topanel

Comment 22 by scarybea...@gmail.com, Feb 12 2013

Labels: -Mstone-24 -Merge-Approved Mstone-26 Release-0
This can go into Chrome 26.

Comment 24 by scarybea...@gmail.com, Feb 20 2013

Labels: -Mstone-26 -reward-topanel Mstone-25 Merge-Approved
@homakov: unfortunately, you've blogged widely before we patched the issue to Chrome stable.
As you can see, I had added the "reward-topanel" label to this bug in order to internally suggest we should reward this clever piece of work. I now have to revoke that label :(

Still, these XSS Auditor bugs are interesting and pretty impressive so you should drop me an e-mail if you are currently interested in job opportunities.

Comment 25 by homakov@gmail.com, Feb 20 2013

Wow, i am not very familiar with labels so i thought there is no way to get bounty for this issue.. i just wanted to prove that it's severe, for myself :)

Comment 26 by scarybea...@gmail.com, Feb 20 2013

Oops, I see @tsepez already said the same thing in #c7, I think I'm just confusing things :)

Yeah, you've put together a decent bug chain.

We're still happy to reconsider the severity rating if we got it wrong. Would this Chrome bug ever trigger on a well-written web site or can it only be abused in the presence of bugs (e.g. Facebook's OAuth2 bugs?)

Comment 27 by homakov@gmail.com, Feb 20 2013

depends on API complexity. Such comprehensive providers like facebook, they always have hooks to use it.
But i nevermind about severity, just posted a link here to demonstrate :)

Comment 28 by scarybea...@gmail.com, Feb 20 2013

So all that's missing is a link to your resume ;-)

Comment 29 by homakov@gmail.com, Feb 20 2013

haha, i have a short one with plain history: http://homakov.blogspot.com/p/service.html
ruby, web security :)

Comment 30 by tsepez@chromium.org, Feb 20 2013

@homakov - re: "still not patched" - we were wondering if you have tested using the dev channel of chrome (26.0.1410 or better), and whether this issue remains for you.

Comment 31 by homakov@gmail.com, Feb 20 2013

@tsepez i mean it's not patched on people's computers. For example mine is Version 24.0.1312.57
Pretty sure it's patched on trunk, it's obvious from diff.

Though, because of data extraction issue this patch will be refactored I guess to use different origin.

Comment 32 by tsepez@chromium.org, Feb 20 2013

@homakov - we expect that a contributing factor in your FB exploit is the use of http:// links, rather https://.  Are you able to make this work against an SSL flow?  (We consider passing tokens over http:// an issue in itself).

Comment 33 by scarybea...@gmail.com, Feb 20 2013

Labels: -Release-0 -Merge-Approved Release-1 Merge-Merged
M25: http://trac.webkit.org/changeset/143508

Comment 34 Deleted

Comment 35 by homakov@gmail.com, Feb 20 2013

Not understood your question, but https pages don't set document.referrer. In my exploit final page is http:// but first page is https. This happenede because "authorize" page must be HTTPS according to oauth2 specs, but "website" can be whatever.

Comment 36 by scarybea...@gmail.com, Mar 2 2013

Labels: CVE-2013-0909

Comment 37 by bugdroid1@chromium.org, Mar 10 2013

Project Member
Labels: -Type-Security -SecImpacts-Stable -SecImpacts-Beta -SecSeverity-Low -Mstone-25 Security-Severity-Low Security-Impact-Stable Security-Impact-Beta M-25 Type-Bug-Security

Comment 38 by bugdroid1@chromium.org, Mar 21 2013

Project Member
Labels: -Security-Severity-Low Security_Severity-Low

Comment 39 by bugdroid1@chromium.org, Mar 21 2013

Project Member
Labels: -Security-Impact-Stable Security_Impact-Stable

Comment 40 by bugdroid1@chromium.org, Mar 21 2013

Project Member
Labels: -Security-Impact-Beta Security_Impact-Beta

Comment 41 by jsc...@chromium.org, Nov 18 2013

Labels: -Restrict-View-SecurityNotify
Bulk release of old security bug reports.

Comment 42 by sheriffbot@chromium.org, Jun 14 2016

Project Member
Labels: -security_impact-beta

Comment 43 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 44 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 45 by mbarbe...@chromium.org, Oct 2 2016

Labels: allpublic

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

Labels: CVE_description-submitted

Sign in to add a comment