New issue
Advanced search Search tips

Issue 815418 link

Starred by 3 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows , Mac
Pri: 3
Type: Bug



Sign in to add a comment

FileSystem API access cannot be disabled in 63.0.3239.132

Reported by tom...@gmail.com, Feb 24 2018

Issue description

This template is ONLY for reporting security bugs. If you are reporting a
Download Protection Bypass bug, please use the "Security - Download
Protection" template. For all other reports, please use a different
template.

Please READ THIS FAQ before filing a bug: https://chromium.googlesource.com
/chromium/src/+/master/docs/security/faq.md

Please see the following link for instructions on filing security bugs:
https://www.chromium.org/Home/chromium-security/reporting-security-bugs

NOTE: Security bugs are normally made public once a fix has been widely
deployed.

VULNERABILITY DETAILS
Please provide a brief explanation of the security issue.

VERSION
Chrome Version: 63.0.3239.132 (Official Build) (64-bit) (cohort: Stable)
Operating System: Windows 10 X64 Latest

REPRODUCTION CASE
I accessed this link:
https://mega.nz/#!sElGBCZJ!rq7TNBmYe6SufjfkIMww7fnSBTXjk_J0YIn2rzbvvjE
Chose OK to allow Mega to access the FileSystem API. The file was downloaded.

Next I wanted to revoke the rights, which isn't possible.
a) Clicking the mega-icon and "site settings" => reset site settings => Reload to apply doesn't work. The file is still in the cache:
c:\Users\THEUSER\AppData\Local\Google\Chrome\User Data\Default\File System\

b) Going through all settings under chrome://settings/content?search=content doesn't help

c) Clearing the history (including cookies) for the last hour doesn't help

d) Clearing the files c:\Users\THEUSER\AppData\Local\Google\Chrome\User Data\Default\File System\ helps somewhat. Mega detects the data is missing, but redownloads without asking for permission.

e) Restarting Chrome doesn't help.

In all, I'd say Mega can access the FileSystem API and I cannot stop it.

Thanks,
Tomas

 
Components: UI>Browser>Permissions Blink>Storage>FileSystem
Labels: FoundIn-66 FoundIn-63 OS-Mac OS-Windows
Status: Untriaged (was: Unconfirmed)
It's not entirely clear how this is supposed to work. In Chrome 66, choosing "Block" on the permission prompt doesn't visibly impact the site (the file downloads without any problem) or any of the Site Settings shown by chrome://settings/content/siteDetails?site=https%3A%2F%2Fmega.nz

Visiting chrome://settings/cookies/detail?site=mega.nz&search=files shows 

  Origin
    https://mega.nz/
  Persistent storage
    0 B
  Temporary storage
    678 MB

Running chrome://restart does not seem to impact the value (e.g. suggesting that Temporary Storage is not cleared on browser exit). 

The permission requested is |QuotaPermissionRequest| https://cs.chromium.org/chromium/src/chrome/browser/chrome_quota_permission_context.cc?l=44&rcl=12522853769d394073efa4531964a6addef6698a
Cc: jsb...@chromium.org
This request is badly named. I think it is to request "quota" https://cs.chromium.org/chromium/src/chrome/app/generated_resources.grd?rcl=43318c02bb32c8eb07e9739904d15778d64d3094&l=9374 to store stuff.

This is very old tech and my knowledge might be wrong, but I think apps normally have unlimited temporary quota, but if they want to store stuff in their local (sandboxed) file system they have to request quota.

Temporary here means 'treated like the cache' and freed when under storage pressure. It doesn't mean cleared after every chrome restart.

I haven't seen anything here to indicate the system has bugs, but there are some design flaws:
- there is no way to see or undo that permission grant
- the wording of the permission grant is confusing.

I think the new durable storage system is meant to fix all this...

Comment 3 by kenrb@chromium.org, Feb 27 2018

Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Type-Bug
Summary: FileSystem API access cannot be disabled in 63.0.3239.132 (was: Security: FileSystem API access cannot be disabled in 63.0.3239.132)
Clearing security flags because this is more of a feature request for the ability to revoke a storage quota grant.
#c2 is correct. "temporary" is how most storage behaves (Indexed DB, Cache API, localStorage, etc) - evicted only under storage pressure. The newfangled spec term for this is "best effort".

The legacy, Chrome-only FileSystem API has a "PERSISTENT" namespace (different from the persistent permission, *sigh*) which prompts the user, and such storage is immune from eviction.

In theory, the webkitRequestFileSystem(PERSISTENT, ...) call should prompt, and be a permission that's visible/clear-able. Not sure why that's not (no longer?) the case.



Cc: pwnall@chromium.org
Components: Blink>Storage>Quota
Labels: Pri-3
Status: Available (was: Untriaged)
Cc: c...@chromium.org

Sign in to add a comment