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 2 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Jun 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Security



Sign in to add a comment
link

Issue 696806: Security: Allowed to set AppCache-manifest under CSP: Sandbox / Fallback on full origin

Reported by fr...@detectify.com, Feb 28 2017

Issue description

VULNERABILITY DETAILS
It seems like the specification of how App Cache is working is a lot less restrictive compared to Service Workers. 

The following scenarios are possible using an App-Cache manifest:

* manifest can be set even though page has Content-Security-Policy: sandbox
* manifest can be set on origin, even being on a suborigin
* manifest FALLBACK can fetch resources not allowed by CSP
* an SVG-file can set a manifest (even if mime is image/svg+xml)
* an XML can set manifest (using xmlns=xhtml)
* a file below a path (u/XYZ) can set FALLBACK for the complete origin

This currently affects a bunch of file serving services which uses sandboxed origins but still serve inline content on the sandboxed domains. By triggering a cookie-bomb combined with a manifest, you're able to hijack any URL on the sandboxed domain using FALLBACK independently if the files are served from a sub-path on the domain. 

There are no CSP-rules to prevent the App Cache manifest from getting installed and the only mitigation as far as I know today is to block any inline content.

Manifest should not be possible to set from a page having Content-Security-Policy: sandbox

Manifest should (probably) not be possible to set from a subfolder onto the complete origin (this will probably break a bunch of apps tho)

Setting a manifest should probably be restricted to text/html only.

VERSION
56.0.2924.87 (Official Build) (64-bit) 

REPRODUCTION CASE
Attached a file with CSP: sandbox that will still trigger the Manifest-installation.

Also attached a manifest.txt-file that will set the FALLBACK to a specific URL, this manifest can be set from any path on the origin and will set the FALLBACK for the complete domain.
 
test.php
89 bytes View Download
manifest.txt
71 bytes View Download

Comment 1 by fr...@detectify.com, Feb 28 2017

If it's possible, I would like to add dev@dropbox.com (which suggested that we posted this as a bug) and also avlidienbrunn@gmail.com as we both were involved.

Comment 2 by fr...@detectify.com, Feb 28 2017

Maxime at Dropbox also sent this:
https://www.w3.org/TR/2015/WD-html51-20150506/browsers.html#security-concerns-with-offline-applications-caches

It seems like the specification of how Application Cache should work actually states the following:

"manifests can only specify fallbacks that are in the same path as the manifest itself. This means that a content injection upload vulnerability in a particular directory on a server can only be escalated to a take-over of that directory and its subdirectories. If there is no way to inject a file into the root directory, the entire site cannot be taken over."

Which is not really how it works today.

Having a manifest.txt, xss.html and load-manifest.html inside a subdirectory (/u/123), where the manifest says:

FALLBACK:
/ /u123/xss.html

will actually set that fallback for the complete origin when visiting /u123/load-manifest.html

Comment 3 by kerrnel@chromium.org, Feb 28 2017

Components: Blink>SecurityFeature

Comment 4 by kerrnel@chromium.org, Feb 28 2017

Owner: mkwst@chromium.org
Status: Assigned (was: Unconfirmed)
mkwst@, are you able to assess this issue?

Comment 5 by est...@chromium.org, Feb 28 2017

Cc: d...@dropbox.com avlidien...@gmail.com
adding requested ccs

Comment 6 by est...@chromium.org, Feb 28 2017

Cc: -d...@dropbox.com akw...@dropbox.com

Comment 7 by est...@chromium.org, Feb 28 2017

Cc: -akw...@dropbox.com akh...@dropbox.com

Comment 8 by mkwst@chromium.org, Mar 2 2017

Cc: jochen@chromium.org jakearchibald@chromium.org
Labels: Security_Severity-Medium Security_Impact-Stable
Owner: michaeln@chromium.org
Setting to medium/stable, as the origin checks really do seem problematic.

I would be thrilled to add tons of restrictions to appcache, up to and including removing it from the platform. :)

Reassigning to michaeln@, and CCing Jake, who both know things about our appcache implementation. They should be able to answer the above questions in a more informed way than I.

* manifest can be set even though page has Content-Security-Policy: sandbox

This seems like a bug. Sandboxed pages should have an opaque origin, and shouldn't be able to set an appcache for the origin from which they were delivered. Is this the case for HTML files, or just SVG?

* manifest can be set on origin, even being on a suborigin

I expect this is related to the above: we might not be correctly consulting `SecurityOrigin` for suborigins. CCing jochen@ for the spec issue.

* manifest FALLBACK can fetch resources not allowed by CSP

I don't think this is something CSP can reasonably limit, in the same way that it doesn't limit what ServiceWorkers can do with an outgoing request. The fact that appcache isn't CSP-aware is certainly bad, but it's a deeper problem with appcache, not an issue with CSP per-se.

* an SVG-file can set a manifest (even if mime is image/svg+xml)

This seems strange. Is it expected behavior, Jake/Michael?

* an XML can set manifest (using xmlns=xhtml)

Ditto, but less surprising.

* a file below a path (u/XYZ) can set FALLBACK for the complete origin

Service workers' decisions to the side, path-based restrictions don't have much security impact. I'm not sure that we should pretend that they do. But we're apparently not following the spec's guidance here, so we should either make that an explicit decision, or align with the spec.

Comment 9 by mkwst@chromium.org, Mar 2 2017

Components: Blink>Storage>AppCache

Comment 10 by sheriffbot@chromium.org, Mar 2 2017

Project Member
Labels: M-57

Comment 11 by sheriffbot@chromium.org, Mar 2 2017

Project Member
Labels: Pri-1

Comment 12 by mkwst@chromium.org, Mar 2 2017

Cc: maxime.s...@gmail.com
Dev asked for me to add maxime.s.serrano@gmail.com to the CC list, as they've been working together on the issue.

Comment 13 by elawrence@chromium.org, Mar 7 2017

Labels: OS-All

Comment 14 by a...@google.com, Mar 9 2017

Cc: a...@google.com

Comment 15 by sheriffbot@chromium.org, Mar 14 2017

Project Member
michaeln: 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 16 by sheriffbot@chromium.org, Mar 28 2017

Project Member
michaeln: Uh oh! This issue still open and hasn't been updated in the last 28 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 by michaeln@chromium.org, Apr 12 2017

Sounds like the change to make is in Blink is to ignore the manifest attribute value when the securityOrigin.HasSuborigin() or when the securityContext.IsSandboxed(). That should prevent creation of new application caches from those contexts.

I'll take a stab at doing that in HTMLHtmlElement::MaybeSetupApplicationCache().

* manifest FALLBACK can fetch resources not allowed by CSP

I think we leave this one alone, multiple pages with different CSPs can refer to the same manifest. Pages can get added after the appcache is established.

* SVG/XML

I'm not sure if its expected or not per the spec, its not really a security issue afaict.

* a file below a path (u/XYZ) can set FALLBACK for the complete origin

The spec got changed sometime after apps using this feature were release. Changing this behavior would absolutely break existing apps.

Comment 18 by michaeln@chromium.org, Apr 12 2017

First some history and then an idea about a mitigation...

Back in 2011, it was decided that the text/cache-manifest mimetype requirement was too onerous and needed to be relaxed, so we did so.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14701
https://bugs.chromium.org/p/chromium/issues/detail?id=103939

Sometime later, we reinstated the mimetype requirement for a powerful non-standard feature.
https://bugs.chromium.org/p/chromium/issues/detail?id=372634


We could require the mimetype for FALLBACKS at "/" or urls not nested down under the manifest's directory.

Comment 19 by akh...@dropbox.com, Apr 12 2017

hey! thanks for the pings. Your mitigation sounds good but I am confused: per https://bugs.chromium.org/p/chromium/issues/detail?id=367812 and https://bugs.chromium.org/p/chromium/issues/detail?id=372634 it looks like it should already be the case that the mimetype is required?

Comment 20 by michaeln@chromium.org, Apr 12 2017

That reinstated the the content-type requirement for a specific case where the manifest was using the non-standard CHROMIUM-INTERCEPT feature, otherwise the content-type is ignored.

I'm suggesting we could require it for "dangerous" FALLBACK usages too.

Comment 21 by akh...@dropbox.com, Apr 12 2017

aah ok. That sounds good to me!

Comment 23 by sheriffbot@chromium.org, Apr 20 2017

Project Member
Labels: -M-57 M-58

Comment 24 by michaeln@chromium.org, Apr 20 2017

Cc: jsb...@chromium.org

Comment 25 by awhalley@chromium.org, Apr 24 2017

michaeln@ - any more changes expected or can we mark this as fixed?  Thanks!

Comment 26 by michaeln@chromium.org, Apr 24 2017

I think we should leave it open to mitigate the last bullet item too.

There are 6 items listed in the OP. The first two are taken care of, the third is 'not a bug', the next two are not a security matter, but that last one scares people. 

My vote would be to require the C/T for some subset of FALLBACK uses.

Comment 27 by fr...@detectify.com, Apr 25 2017

Hi,
Great job getting this resolved.
Will this qualify for a bounty?

Comment 28 by awhalley@chromium.org, Apr 28 2017

This will qualify for bounty consideration once it's marked as fixed, looks like there's some remaining work per #26.

Comment 29 by dominickn@chromium.org, May 2 2017

Friendly security sheriff ping. :)

michaeln: do we need some more consensus on how to address the last bullet point, more discussion, or is a fix possible and awaiting time / someone to do it?

Comment 30 by dominickn@chromium.org, May 9 2017

Security sheriff ping x 2.

Comment 31 by jsb...@chromium.org, Jun 5 2017

Status: Fixed (was: Assigned)
michaeln@ and I chatted - the outstanding issue is already tracked as  issue 422987  so we can go ahead and mark this fixed.

Comment 32 by sheriffbot@chromium.org, Jun 6 2017

Project Member
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify

Comment 33 by awhalley@chromium.org, Jun 6 2017

Labels: reward-topanel

Comment 34 by awhalley@chromium.org, Jun 8 2017

Labels: -reward-topanel reward-unpaid reward-2000

Comment 35 by awhalley@chromium.org, Jun 8 2017

Congrats! The VRP Panel decided to award $2,000 for this bug. Thanks!

Comment 36 by awhalley@chromium.org, Jun 8 2017

Labels: -reward-unpaid reward-inprocess

Comment 37 by fr...@detectify.com, Jun 25 2017

Thanks a lot!

Comment 38 Deleted

Comment 39 by awhalley@google.com, Sep 5 2017

Labels: -M-58 M-60

Comment 40 by sheriffbot@chromium.org, Sep 12 2017

Project Member
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