New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 103630 link

Starred by 1 user

Issue metadata

Status: Fixed
Last visit > 30 days ago
Closed: Dec 2011
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Security

  • Only users with EditIssue permission may comment.

Sign in to add a comment

Security: iFrame SandBox Unique Origin not enforced in extensions

Reported by, Nov 9 2011

Issue description


The iframe sandbox requires that the framed content run under the privileges of a unique origin and not the privileges of the document you downloaded from. But this doesn't seem to be true.

Create an extension with a tabs permission, and 2 pages. The first say popup.html runs with full privileges and frames test.html in a sandbox.  test.html has code to create a new tab, which should fail since test.html is running under a unique origin. But it doesn't. This is a same-origin bypass.

Chrome Version: 17.0.932.0 dev
Operating System: Ubuntu 11.04

Attached tarball.

4.7 KB Download
Labels: -Area-Undefined Area-Internals Feature-Extensions
This is likely because the extension system uses document URLs for security checks rather than securityOrigin.

Comment 3 by, Nov 10 2011

Labels: -Pri-0 Pri-2 SecSeverity-Medium SecImpacts-Stable SecImpacts-Beta
Status: Untriaged
Thanks for the report, dev.akhawe.

It's an origin bypass, but difficult to exploit because you have to be able to get an extension to frame your resource. I'm setting severity to medium.

Comment 4 by, Nov 10 2011

If I understand correctly, this applies only when an extension frames one of its own resources in an iframe sandbox? If so, that's an extremely narrow case, so medium severity seems high.

Comment 5 by, Nov 10 2011

You're right, I missed that constraint looking at this earlier. In that case, does this have any security severity at all? I no longer see a plausible attack scenario.
Since the sandbox is *designed* for handling untrusted data, it is a bad idea not to reduce its privileges. An extension could frame untrusted data (test.html could just download and eval code received over the internet) and the sandbox is supposed to ensure that it can't do anything bad.

Comment 7 by, Nov 10 2011

Labels: -Pri-2 -SecSeverity-Medium Pri-3 SecSeverity-Low
Agree that the behavior is wrong, we're just looking at this against our severity guidelines, and the likelihood of this ever being used to attack a user. Downgrading to low severity, because I don't think it's at all common for extensions to actually do that.
If that's the case, the low priority makes sense. I wasn't sure whether sandbox is used; it's great that you guys have such good measurement/visibility into what extensions do / don't do.

Comment 9 by, Nov 10 2011

@dev.akhawke - The crux here is that the HTML frame has to be delivered as a resource in the extension CRX. So, there really is no safe way to sandbox content in the scenario you describe, because you'd eval untrusted script in the extension process and grant it access to the extension APIs (which is far more dangerous).

Accepting that, I'm not saying this isn't a bug. It definitely is and we should fix it. However, I'm at a loss for a scenario in which this bug would represent a real-world vulnerability. In that case, we treat the issue as no higher than low-severity (if we treat it as a security vulnerability at all).
An example of a real-world scenario for this bug is an RSS extension that renders a preview of the feed in a sandboxed iframe in a browser action popup.  For example, the Google-authored RSS extension either does that or something very similar.
@abarth - Isn't that done in a content script, and not the extension origin? In which case, this issue wouldn't apply, would it?
Labels: -Pri-3 Pri-2
Are you asking about the specific case of or the general case?  Anyway, I think SecSeverity-Low is the right severity because these sandboxed iframes are likely to have script disabled.
I was asking about the specific case, but I just looked and it appears I was wrong in my understanding of that particular extension. I agree in the general case though, and concur that low-severity seems right.

Comment 14 by, Nov 10 2011

Status: Started

Comment 15 by, Nov 14 2011

Labels: extensions-cleanup

Comment 16 by, Nov 16 2011

Labels: Mstone-17

Comment 17 by, Nov 16 2011

Labels: OS-All
Aaron, are you actively working on this bug?  I've stolen it so I can give it a swing.  Please feel free to steal it back.
Project Member

Comment 20 by, Dec 2 2011

The following revision refers to this bug:

r112655 | | Fri Dec 02 00:01:25 PST 2011

Changed paths:

Consider the origin when computing extension permissions

This patch teaches the extension system to use the document's origin when
computing extension permissions. Ideally, we'd use only the document's origin,
but because app extents don't cover entire origins, we need to also consider
the document's URL.

BUG= 103630 
Review URL:
This should now be fixed, but I still need to verify with the original repro.
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Status: FixUnreleased
Verified fix on canary.
@dev.akhawe: we'll happily credit you in our release notes. Any particular name / afiliation we should use?
Labels: CVE-2011-3956

Comment 25 by, May 15 2012

Status: Fixed
Marking old security bugs Fixed..
Project Member

Comment 26 by, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 27 by, Mar 10 2013

Labels: -Type-Security -Area-Internals -Feature-Extensions -SecSeverity-Low -SecImpacts-Stable -SecImpacts-Beta -Mstone-17 Cr-Platform-Extensions Security-Impact-Stable Security-Impact-Beta Security-Severity-Low Cr-Internals Type-Bug-Security M-17
Project Member

Comment 28 by, Mar 13 2013

Labels: Restrict-View-EditIssue
Project Member

Comment 29 by, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Labels: -Restrict-View-SecurityNotify -Restrict-View-EditIssue
Project Member

Comment 31 by, Mar 21 2013

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

Comment 32 by, Mar 21 2013

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

Comment 33 by, Mar 21 2013

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

Comment 34 by, Jun 14 2016

Labels: -security_impact-beta
Project Member

Comment 35 by, Oct 1 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Project Member

Comment 36 by, Oct 2 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Labels: allpublic
Labels: CVE_description-submitted

Sign in to add a comment