Issue metadata
Sign in to add a comment
|
Security: IndexedDB data not isolated between local HTML documents
Reported by
mamach...@gmail.com,
Sep 11 2016
|
||||||||||||||||||||||||
Issue description
VULNERABILITY DETAILS
IndexedDB data from all local files are shared when the right behaviour would be that each file has its own IndexedDB data.
It can lead to information leak or even code execution, because you can read/overwrite the IndexedDB data of any local files.
VERSION
It has been tested on the last stable version of Chrome : "Version 53.0.2785.101 (64-bit)" and on Chromium on "Windows 7 SP1" and "Ubuntu 16.04.1 LTS".
Even in "incognito mode".
REPRODUCTION CASE
To reproduce the problem I have created two html files (see attachments) :
- indexeddb1.html : It creates an ObjectStore and to read data from it ;
- indexeddb2.html : It doesn't create any ObjectStore, but try to read from a pre-existent one.
The steps to view the problem :
1°) Start by deleting your IndexedDB cache files before starting Chrome :
rm -rf ~/.config/google-chrome/Default/IndexedDB/
2°) Open the file "indexeddb1.html" and click on the button ; you'll see the data from the ObjectStore from this page.
3°) Open the file "indexeddb2.html" and click on the button ; you'll see the data from the ObjectStore from the first page. The expected behaviour would be to see nothing.
WHERE THE PROBLEM IS LOCATED IN THE SOURCES
The whole problem can be trace in the file "src/storage/common/database/database_identifier.cc".
The end of the problem is in the function "DatabaseIdentifier::UniqueFileIdentifier" :
// static
const DatabaseIdentifier DatabaseIdentifier::UniqueFileIdentifier() {
return DatabaseIdentifier("", "", 0, true, true);
}
This code is called when the scheme is identified as a local file in "DatabaseIdentifier::CreateFromOrigin" :
if (origin.SchemeIsFile())
return UniqueFileIdentifier();
There we can see that nothing is done to use the origin name to generate the IndexedDB path.
The same bug occured in the function "DatabaseIdentifier::Parse" :
if (scheme == "file")
return UniqueFileIdentifier();
No parameter is used.
As a result whenever you open a local file using IndexedDB, the db will always be stored and read from the folder named "file__0.indexeddb.leveldb".
The expected result whould have contain the path of the opened file in it ; for instance "file_home_user_indexeddb1.html_0.indexeddb.leveldb".
,
Sep 12 2016
jsbell@ can you take a look at this potential security issue? Thanks!
,
Sep 12 2016
This is basically the same as issue 271996. We don't isolate storage between file: URLs for any of the storage types (localStorage, Indexed DB, WebSQL, etc) - see comment #59 in that issue.
,
Sep 13 2016
In comment #59 you say that "Firefox just blocks IDB in file: origins". I don't know if it was true back then (in 2014), but now it isn't : Firefox allow IDB in file: origins. And it isolates data between each local document. I just confirmed it by opening my two example files : $ ls -d ~/.mozilla/firefox/dg81bruy.default/storage/default/file*/ /home/user/.mozilla/firefox/dg81bruy.default/storage/default/file++++home+user+Downloads+indexeddb1.html/ /home/user/.mozilla/firefox/dg81bruy.default/storage/default/file++++home+user+Downloads+indexeddb2.html/
,
Sep 13 2016
,
Sep 14 2016
,
Sep 27 2016
jsbell: 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
,
Sep 28 2016
I'm bumping this down from P1 since (1) the issue has been around "forever", (2) it affects all storage back ends not just IDB, and (3) it's "file:" i.e. not the drive-by web.
,
Oct 13 2016
jsbell: 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
,
Nov 1 2016
jsbell, a friendly ping from the security sheriff: any updates on this? Do you know how this is happening? Per https://src.chromium.org/viewvc/blink?revision=195464&view=revision Blink should treat file:// URLs as unique origins. From a quick glance, it looks like url::Origin may be what's used to make IDB security decisions in the browser process, and url::Origin treats file URLs as a ("file", "", 0) tuple, which means that all file:// URLs would be treated as same-origin according to url::Origin. mkwst does this ring any bells for you? Should we update url::Origin to treat file URLs as unique origins?
,
Nov 1 2016
,
Nov 1 2016
estark@ - yes, that analysis of behavior is correct. See 271996 (marked as blocking) for previous (unresolved) discussion.
,
Dec 2 2016
,
Jan 26 2017
,
Feb 7 2017
,
Mar 10 2017
,
Apr 20 2017
,
May 1 2017
Ping from security sheriff. pwnall: I see this has been assigned to you. Any update on progress here?
,
Jun 6 2017
,
Jun 22 2017
Time for another security sheriff ping. jsbell/pwnall - any update on this issue?
,
Jun 22 2017
No update. What to do with file:// URLs and storage isolation still requires exploration (and understanding of what would break if we make a change) If anyone from Security wants to make the decision we'll be happy to support it. :)
,
Jul 26 2017
,
Sep 6 2017
,
Oct 18 2017
,
Nov 15 2017
No updates here since June... CC'ing folks from Site Isolation in case they have any thoughts.
,
Dec 5 2017
This is a duplicate of issue 271996; that bug is properly a Type=Bug-Security. Removing view restrictions on this one since the earlier bug has been public for years.
,
Dec 5 2017
,
Dec 5 2017
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by elawrence@chromium.org
, Sep 12 2016Summary: Security: IndexedDB data not isolated between local HTML documents (was: Security: Restriction access inexistant with IndexedDB on local files)