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

Issue 588766 link

Starred by 13 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , All , Chrome , Mac
Pri: 3
Type: Bug



Sign in to add a comment

Security: Incognito Mode Detection via "Logic" Flaw In Chrome Extensions

Reported by l33tera...@gmail.com, Feb 22 2016

Issue description

VULNERABILITY DETAILS
A web page is able to detect if the user is using Incognito mode or not, using a logic "flaw" of chrome extensions.
As you know, extensions don't work on Incognito mode, unless you allow them to (in the chrome://extensions/ page).
In addition, when you install Chrome there are a few default extensions that comes with it. One of them is Google Docs Offline.
Google Docs Offline (ghbmnnjooekpmoecnnnilnnbdlolhkhi) has a web_accessible_resource - page_embed_script.js.
This resource can be loaded from a local web, using the simple <script src=""></script> tag.

But, when a user is surfing on incognito mode, the load of this default js file is being blocked, with the error:
chrome-extension://ghbmnnjooekpmoecnnnilnnbdlolhkhi/page_embed_script.js net::ERR_ADDRESS_UNREACHABLE

So, all we have to do is try loading this local script, and put an 'onerror' event to detect if the user is on incognito or not.

This is very exploitable since the extension I am using is pre-installed on every version of chrome.

Watch this private PoC video here: https://youtu.be/LmXEjIc5zR8

VERSION
Chrome Version: I am using the latest, but this is relevant among all versions.
Operating System: I am using 10 x64, but I have tested on 7 x86 and x64.

REPRODUCTION CASE
1. On incognito mode, create a <script src=""> tag to a location of a chrome-extension web_accessible_resource, such as a .js file.
2. Put an onerror event that will trigger if there will be a problem loading the extension's file.
3. Surf on incognito
4. And boom - you are now detected since the extension is disabled in incognito by default.
5. You can watch this private (for your eyes only) PoC video here: https://youtu.be/LmXEjIc5zR8

FOR CRASHES, PLEASE INCLUDE THE FOLLOWING ADDITIONAL INFORMATION
No crashes were detected.
 

Comment 1 by och...@chromium.org, Feb 23 2016

Components: UI>Browser>Incognito
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Type-Bug
I don't think incognito mode makes the guarantee that it's undetectable to sites. See https://www.chromium.org/Home/chromium-security/security-faq#TOC-What-are-the-security-and-privacy-guarantees-of-Incognito-mode- and https://support.google.com/chrome/answer/95464?hl=en&p=cpn_incognito.

I'll leave this to incognito folks to triage just in case.
Components: Platform>Extensions Privacy
Incognito shouldn't be detectible ideally. The bug like this is to be fixed.

Comment 3 Deleted

@2 Hi, I would like your opinion about the severity of this issue, since this directly threats user's privacy.
Thanks.
Owner: rdevlin....@chromium.org
Devlin: assigning to you if you don't mind. Looks similar to bug 448002, and directly relevant to bug 588766.
Labels: OS-All
Status: Assigned (was: Unconfirmed)

Comment 7 by mea...@chromium.org, Aug 10 2016

Err, I meant "directly relevant to bug 139592"
Cc: jawag@chromium.org
This is a well-known aspect of web accessible resources, and is even documented [1].  If an extension exposes any web accessible resources, it means that its presence can be determined.  In a perfect world, yes, we would change this, but it's unclear when or if that can happen.

It's also not an excellent indication of incognito or not - many users don't have the drive extension installed, and some who do have it enabled incognito - in both cases, the conclusion drawn here would be incorrect.

IMO, the best fix here would be for drive to remove the web accessible resource.  I don't think there's really any need for it.  James, do you have a contact on the drive team that could look into this?

[1] https://developer.chrome.com/extensions/manifest/web_accessible_resources

Comment 9 by jawag@chromium.org, Aug 17 2016

Yep, I'll kick off a thread with the Drive folks about this.
Labels: OS-Chrome OS-Linux OS-Mac OS-Windows Pri-3
Revisiting old bugs.  jawag@, did the thread with the drive folks ever go anywhere?
This vulnerability is now being used for bad purposes. Navigating to https://www.technologyreview.com/s/601842/inside-genomics-pioneer-craig-venters-latest-production/ gives me the message:

Hello,

We noticed you're browsing in private or incognito mode.

To continue reading this article, please exit incognito mode or log in.
RE #11: Actually, I believe they're using a different Incognito detection mechanism, see https://bugs.chromium.org/p/chromium/issues/detail?id=93417#c14

The article's script has detections for the private mode of each browser; detects = [ ["Webkit RequestFileSystem", isWebkitRequestFileSystem, detectWebkitRequestFileSystem], ["Firefox IndexedDB", isFirefoxIndexedDB, detectFirefoxIndexedDB], ["IE10+ / Edge", isIE10PlusOrEdge, detectIE10PlusOrEdge], ["Safari LocalStorage", isSafariLocalStorage, detectSafariLocalStorage]];

Comment 13 by phistuck@gmail.com, Feb 23 2018

#12 - right, the same here - https://www.haaretz.co.il/gallery/literature/.premium-MAGAZINE-1.5840639 - :(
The other bug is private, so I cannot comment there.
Cc: -jawag@chromium.org rdevlin....@chromium.org
Owner: jawag@chromium.org
James, any updates here?  (See comments 8, 9, 10)

Comment 15 Deleted

Cc: rhalavati@chromium.org
Components: Privacy>Incognito

Sign in to add a comment