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

Issue 696806 link

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

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
Components: Blink>SecurityFeature
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
Project Member

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

Labels: M-57
Project Member

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

Labels: Pri-1
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.
Labels: OS-All

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

Cc: a...@google.com
Project Member

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

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

Comment 16 by sheriffbot@chromium.org, Mar 28 2017

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
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.

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

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

Labels: -M-57 M-58
Cc: jsb...@chromium.org
michaeln@ - any more changes expected or can we mark this as fixed?  Thanks!
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.

Hi,
Great job getting this resolved.
Will this qualify for a bounty?
This will qualify for bounty consideration once it's marked as fixed, looks like there's some remaining work per #26.
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?
Security sheriff ping x 2.
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.

Project Member

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

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Labels: reward-topanel
Labels: -reward-topanel reward-unpaid reward-2000
Congrats! The VRP Panel decided to award $2,000 for this bug. Thanks!
Labels: -reward-unpaid reward-inprocess
Thanks a lot!

Comment 38 Deleted

Labels: -M-58 M-60
Project Member

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

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