Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 633885 cross-origin restriction bypass in track tag src
Starred by 2 users Reported by haojun...@gmail.com, Aug 3 2016 Back to list
Status: Fixed
Owner:
Closed: Oct 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug-Security



Sign in to add a comment
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/601.7.7 (KHTML, like Gecko) Version/9.1.2 Safari/601.7.7

Steps to reproduce the problem:
1. At first the expected behavior here is as the following URL.
http://adlabtest.applinzi.com/test7.html

This document tries to load a cross-origin font like this.
<track src="http://zih.pub/subtitles.vtt" kind="subtitles" srclang="en" label="English" />   But the loading error is shown on the console because the track doesn't send an Access-Control-Allow-Origin header.
2.But the flaw I found is the following.
http://adlabtest.applinzi.com/test8.html
This video also loads same subtitle as 1) but it's through 302 redirector like this.
<track src="http://adlabtest.applinzi.com/redirct2.php" kind="subtitles" srclang="en" label="English" /> 

What is the expected behavior?

What went wrong?
bypass same-origin 

Did this work before? N/A 

Chrome version: Chrome 52.0.2743.82  Channel: stable
OS Version: 10
Flash Version: 

I found that  the request of loading subtitle(webVTT)  was made with no-cors mode when the URL of Loading subtitle was same-origin. However, that same-origin request may be redirected to another origin.
I test this vulnerability on Chrome 52.0.2743.82 m ( win10) It will be success

Test site:
http://adlabtest.applinzi.com/test8.html

step1:
At first the expected behavior here is as the following URL.
http://adlabtest.applinzi.com/test7.html

This document tries to load a cross-origin font like this.
<track src="http://zih.pub/subtitles.vtt" kind="subtitles" srclang="en" label="English" />   But the loading error is shown on the console because the track doesn't send an Access-Control-Allow-Origin header.

Setp2:
But the flaw I found is the following.
http://adlabtest.applinzi.com/test8.html
This video also loads same subtitle as 1) but it's through 302 redirector like this.
<track src="http://adlabtest.applinzi.com/redirct2.php" kind="subtitles" srclang="en" label="English" />  

redirct2.php:
<?php
header("Location: http://zih.pub/subtitles.vtt");
?>
By the way, you should open the switch of subtitles

Then, the subtitle can be loaded with bypassing CORS restriction and the track is successfully applied to the video.

Author : Haojun Hou and Shenrong Liu in ADLab of Venustech.
Could you please help me assign a CVE for this issue?
 
Cc: lgar...@chromium.org yini...@chromium.org
Components: Blink>Media>Track
Labels: Security_Severity-Medium Security_Impact-Stable
Owner: japhet@chromium.org
Status: Assigned
japhet could please take a look at this?

I'm not quite sure the security implications of this because it seems similar to embedding static cross-origin content. lgarron: do you have any ideas?
Project Member Comment 2 by sheriffbot@chromium.org, Aug 4 2016
Labels: M-53
Project Member Comment 3 by sheriffbot@chromium.org, Aug 4 2016
Labels: -Pri-2 Pri-1
Project Member Comment 4 by sheriffbot@chromium.org, Aug 5 2016
Labels: M-53
Comment 5 by haojun...@gmail.com, Aug 14 2016
Excuse me, when this bug will be assigned a CVE number ? or could you please give me a rough idea what time ?
Cc: -yini...@chromium.org
Project Member Comment 7 by sheriffbot@chromium.org, Aug 17 2016
japhet: 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 8 by haojun...@gmail.com, Aug 21 2016
Sorry,could I know the latest developments about this vulnerability ?
Comment 9 by haojun...@gmail.com, Aug 23 2016
@sheriffbot@chromium.org, hi, could I know the latest developments about this vulnerability ? For example,is there a CVE for it?
Project Member Comment 10 by sheriffbot@chromium.org, Sep 1 2016
japhet: 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
Hi,it has been more than one month since I report this vulnerability,please let me konw the latest developments about it. 
I will be looking forward to your reply.
Hi,it has been more than one month since I report this vulnerability,please let me konw the latest developments about it. 
I will be looking forward to your reply.
Does anyone reply to me?
Hi,it has been more than one month since I report this vulnerability,please let me konw the latest developments about it. 
I will be looking forward to your reply,please.
#14: Thanks for your report. We're still looking at this; it appears that the Track element behavior does not match the spec and is both too restrictive (issue 472300) and not restrictive enough (this issue).

It's less clear how useful this vector is to an attacker and whether it leaks any unique cross-origin information to the requesting page.
Summary: cross-origin restriction bypass in track tag src (was: cross-orign restriction bypass in track tag src)
In terms of exploitability, it turns out that JavaScript /can/ read the cue text using <trackId>.track.cues[i].getCueAsHTML() which means this does offer a cross-origin read in violation of CORS. Exploitability appears to be limited, however, as the parser for WebVTT requires those characters appear atop the file ( https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/track/vtt/VTTParser.cpp?sq=package:chromium&dr=CSs&rcl=1474471143&l=130 ), which would mean that the attacker would need to attack e.g. a vulnerable JSONP endpoint to get these characters at the top of the target resource he was trying to steal.

The original repro site is down, so I've posted one here:

https://whytls.com/test/crossorigin/index.html
https://whytls.com/test/crossorigin/index-302.html

In Chrome 55.2867, the direct cross-origin reference shows the error message "Text track from origin 'https://www.whytls.com' has been blocked from loading: Not at same origin as the document, and parent of track element does not have a 'crossorigin' attribute. Origin 'https://whytls.com' is therefore not allowed access." and captions are not shown. In contrast, the redirected cross-origin reference yields no console message and the captions are loaded.

In Firefox 52.0a1, captions load when directly referenced across origin. When referenced indirectly via the same-origin URL that returns a cross-origin HTTP/302, Firefox does not follow the redirect and does not display the caption; there is no console warning.

In Internet Explorer 11, captions load only when same-origin; direct cross-origin references are ignored, and indirect references result in following the 302 and then ignoring the resulting download; no console error is shown.

Debuggers looking to step through this can walk through TextTrackLoader::load(const KURL& url, CrossOriginAttributeValue crossOrigin)


Hello!  Any more changes expected for this, or can we move it to Fixed?  Cheers.
Labels: Merge-Request-54
Do we want this for M54?
Comment 20 by dimu@chromium.org, Oct 4 2016
Labels: -Merge-Request-54 Merge-Review-54 Hotlist-Merge-Review
[Automated comment] Less than 2 weeks to go before stable on M54, manual review required.
Labels: -Merge-Review-54 Merge-Approved-54
I'd like to take for M54, since it's a security fix.
Project Member Comment 22 by sheriffbot@chromium.org, Oct 5 2016
Status: Fixed
Please mark security bugs as fixed as soon as the fix lands, and before requesting merges. This update is based on the merge- labels applied to this issue. Please reopen if this update was incorrect.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member Comment 24 by sheriffbot@chromium.org, Oct 6 2016
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Labels: Release-0-M54
Labels: reward-topanel
Labels: CVE-2016-5192
Labels: -reward-topanel reward-unpaid reward-1000
Congratulations! The panel decided to award $1,000 for the bug, noting the mitigations mentioned in comment 16.  A member of our finance team will be in touch shortly.

*** 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.
*********************************
Labels: reward-inprocess
Labels: -reward-unpaid
hi,I have two questions, first , How do I get a reward? Second, is there no description like "HaojunHou in ADLab of Venustech" in your vulnerability publication?
I will be looking forward to your reply.
Hi,in the first time I reported this vulnerability , information about Author like "Haojun Hou in ADLab of Venustech" in it , but I check your vulnerability information publication , these information did not be present.
Hi,in the first time I reported this vulnerability , information about Author like "Haojun Hou in ADLab of Venustech" in it , but I check your vulnerability information publication , these information did not be present.
I will be looking forward to your reply.
Hello, how can I get the reward? 
Hello Haojun!  The advisory went live a while ago (https://googlechromereleases.blogspot.com/2016/10/stable-channel-update-for-desktop.html) but it looks like we ended up just using your email address. Sorry about that.  Would you like us to update it with the text you gave in #35?

I shall follow up on #36 via email.
Ok,thanks.By the way, I have a question, how can I get the reward $1,000 for the bug ?
Project Member Comment 39 by sheriffbot@chromium.org, Jan 11
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