New issue
Advanced search Search tips

Issue 780760 link

Starred by 3 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 2
Type: Feature



Sign in to add a comment

Suborigin bug leading to a security bypass

Reported by marcus.n...@hackmanit.de, Nov 2 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.75 Safari/537.36

Steps to reproduce the problem:
VULNERABILITY DETAILS
HTML canvas elements will be currently not marked as "tainted" in case of two different suborigins.

VERSION
Chrome Version: Version 61.0.3163.100 (Offizieller Build) (64-Bit)
Operating System: MacOS 10.12.6
"chrome://flags/": "Experimental Web Platform features Mac, Windows, Linux, Chrome OS, Android" is enabled

REPRODUCTION CASE
Original way to reproduce the bug:
---
1) Go to http://your-sop.com/index.php?exec=native
2) Click on the button "ED: MP4 and OGG" ->  "EE: <canvas>"
3) Please look on the "(not set)" test cases (cross-origin, Access-Control-Allow-Origin, and Use-Credentials) – please look at the attachment.

We can see that we have "yes(pixel)" access both in the same ("Suborigin: your") and cross ("Suborigin: your" vs "Suborigin: other") origin case. This only happens in case of our Suborigin testbed; we also have "javascript:" and the at USENIX published "<script>" stuff there.

What we currently do is that we test on one domain (your-sop.com) within the same path (/). We have two different suborigins: origin A (HD/ED top line) means ("Suborigin: your") and Origin B (HD/ED bottom line) means ("Suborigin: other").

To sum it up, we have read access although we have two different suborigins.

===
New testbed created to verify the "bug" (attached)
---
1) Go to http://your-sop.com/bugs/chrome/canvas-png.php
2) By clicking on the above links, we run test cases for a canvas-element which loads an img-element.

We always have access in the "Origin: same" case; even when we test for "Origin: same - Suborigin: other".

What is the expected behavior?
From my point of few, there could be a problem in case of <canvas> and/or <img>. For this reason I have created another testbed with a <canvas> reading a <video>. We have the same behavior there: http://your-sop.com/bugs/chrome/canvas-video.php – it seems to be a <canvas> problem.

What went wrong?
We should taint the canvas in case that there is a different suborigin header.

Did this work before? N/A 

Chrome version: 62.0.3202.75  Channel: stable
OS Version: OS X 10.12.6
Flash Version: 

I have discussed this issue with Mike West, Artur Janc, Jochen Eisinger, and Devdatta Akhawe.
 
stats-compare.png
311 KB View Download
vulnerable-test-case-example.png
791 KB View Download
newTestbed.zip
10.1 KB Download

Comment 1 by mkwst@chromium.org, Nov 2 2017

Cc: a...@google.com jochen@chromium.org
Components: Blink>SecurityFeature>SameOriginPolicy
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam OS-Android OS-Chrome OS-Linux OS-Windows Type-Feature
Status: Available (was: Unconfirmed)
This is something we'll need to decide on one way or another in the spec before we ship the feature. https://github.com/w3c/webappsec-suborigins/issues/79 has been filed for that discussion.

As we haven't shipped this yet, I'll drop view restrictions on the bug. We'll make sure it's aligned with the spec once we figure out what the spec should say. :)

Comment 2 by est...@chromium.org, Nov 10 2017

Labels: Hotlist-EnamelAndFriendsFixIt

Comment 3 by est...@chromium.org, Feb 18 2018

Labels: -Hotlist-EnamelAndFriendsFixIt

Sign in to add a comment