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:
Buried. Ping if important.
Closed: Jan 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug-Security
Nag

Blocked on:
issue 558232


Show other hotlists

Hotlists containing this issue:
HSTS-History-Sniffing


Sign in to add a comment
link

Issue 544765: Privacy: browser history sniffing attack using HSTS + CSP

Reported by jen...@gmail.com, Oct 19 2015

Issue description

This template is ONLY for reporting security bugs. Please use a different
template for other types of bug reports.

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


VULNERABILITY DETAILS
I wrote a PoC for reliably sniffing browser history in Chrome/Firefox by observing which domains have associated HSTS entries. I showed it to Chris Palmer, who suggested I file it here :). The code is pretty well-commented but basically it works like this:
1. User visits attacker page
2. Browser attempts to load images from various HSTS domains over HTTP
3. Attacker has set a CSP policy that restricts images to HTTP, so image sources are blocked before they are redirected to HTTPS. This is crucial; if the browser completes a request to the HTTPS site, then it will receive the HSTS pin, and the attack will no longer work when the user visits the page again.
4. When an image gets blocked by CSP, its onerror handler is called. In this case, the onerror handler does some tricks to time how long it took for the image to be redirected from HTTP to HTTPS. If this time is on the order of a millisecond, it was an HSTS redirect (no network request was made), which means the user has visited the image's domain before. If it's on the order of 100 milliseconds, then a network request probably occurred, meaning that the user hasn't visited the image's domain.

This also works in incognito mode (can see which hosts the user has visited in their non-incognito session) and chrome on android. I haven't tried other platforms.

Please note this will be shown as part of a demo of new browser fingerprinting methods at Toorcon next Sunday (10/25). 

VERSION
Chrome Version: 46.0.2490.71 stable
Operating System: OSX 10.10.4

REPRODUCTION CASE
Live demo at http://zyan.scripts.mit.edu/sniffly/. Source files also attached. (Please don't share the link.)
 
index.html
1.2 KB View Download
index.js
14.2 KB View Download

Comment 1 by palmer@chromium.org, Oct 19 2015

Cc: mef@chromium.org palmer@chromium.org battre@chromium.org rsleevi@chromium.org mkwst@chromium.org
Labels: Cr-Privacy Cr-Security Cr-Internals-Network-SSL Cr-UI-Browser-History
Owner: palmer@chromium.org
Status: Assigned
See also:
https://code.google.com/p/chromium/issues/detail?id=311296
https://code.google.com/p/chromium/issues/detail?id=258667

Comment 2 by palmer@chromium.org, Oct 19 2015

(Taking ownership only to make sure somebody does. Feel free to take it if the spirit moves you.)

Comment 3 by palmer@chromium.org, Oct 19 2015

(Taking ownership only to make sure somebody does. Feel free to take it if the spirit moves you.)

Comment 4 by och...@chromium.org, Oct 19 2015

Labels: Security_Severity-Medium Security_Impact-Stable
Assuming this impacts stable.

Comment 5 by och...@chromium.org, Oct 19 2015

Labels: M-47

Comment 6 by lgar...@chromium.org, Oct 19 2015

Note that the HSTS portion of this is  Issue 436451 , which is currently WontFix:  https://crbug.com/436451#c34 

Comment 7 by ClusterFuzz, Oct 19 2015

Project Member
Labels: Pri-1

Comment 8 by jen...@gmail.com, Oct 21 2015

Thank you for the prompt replies. FWIW, I found this type of timing attack also works using plain ol' 301 redirect caches instead of HSTS. Assuming 301's are cached based on full URL (not just origin), this can be potentially used to reveal full URLs in browsing history by guess-and-check.

To repro:
1. Open an incognito tab in chrome
2. Load some URLs that 301 to HTTPS, such as http://americanexpress.com/ and http://surveymonkey.com/
3. Load the attached index.html and index.js

This attack will populate the cache, so it won't work again if you reload index.html.

-yan
index.html
1.3 KB View Download
index.js
2.8 KB View Download

Comment 9 by palmer@chromium.org, Oct 21 2015

Cc: engedy@chromium.org

Comment 10 by kenrb@chromium.org, Oct 22 2015

Cc: yitingc@chromium.org

Comment 11 by engedy@chromium.org, Oct 27 2015

Cc: dvadym@chromium.org

Comment 12 by palmer@chromium.org, Nov 12 2015

Cc: jww@chromium.org
Owner: mkwst@chromium.org
I verified that the 301 redirect version, #8, also works.

I am not sure how solvable this problem is, without also breaking something else.

Here is 1 idea, and I have no idea how good or bad of an idea it is: The attack seems to rely on the ability to set a CSP policy like "img-src: http://*" (presumably all of the *-src CSP directives could be used, in the same way). It seems odd to me that CSP enables affirmatively unsafe behavior, so I wonder if we could disallow or deprecate using *-src to set non-secure origins as sources? If browsers did not honor such policies, would that mitigate or solve this history leak problem?

Would it be acceptable, if it did work?

I am no CSP expert, so I leave it to people who are.

I suspect trying to obscure cache timing is unlikely to work at all, or well enough. That's why I am thinking CSP-related approaches.

Comment 13 by palmer@chromium.org, Nov 12 2015

Summary: Privacy: browser history sniffing attack using HSTS + CSP (was: Security: browser history sniffing attack using HSTS + CSP)

Comment 14 by mkwst@chromium.org, Nov 19 2015

Sorry, I made the change to the CSP spec, but neglected to fix the implementation. Doing that this morning.

Comment 15 by mkwst@chromium.org, Nov 19 2015

Blockedon: chromium:558232

Comment 16 by bugdroid1@chromium.org, Nov 19 2015

Project Member
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/568075bbc5d16239a5cbdeb579a8768f9836f13e

commit 568075bbc5d16239a5cbdeb579a8768f9836f13e
Author: mkwst <mkwst@chromium.org>
Date: Thu Nov 19 11:54:24 2015

CSP: Source expressions can no longer lock sites into insecurity.

CSP's matching algorithm has been updated to make clever folks like Yan
slightly less able to gather data on user's behavior based on CSP
reports[1]. This matches Firefox's existing behavior (they apparently
changed this behavior a few months ago, via a happy accident[2]), and
mitigates the CSP-variant of Sniffly[3].

On the dashboard at https://www.chromestatus.com/feature/6653486812889088.

[1]: https://github.com/w3c/webappsec-csp/commit/0e81d81b64c42ca3c81c048161162b9697ff7b60
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1218524#c2
[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1218778#c7

BUG= 544765 ,558232

Review URL: https://codereview.chromium.org/1455973003

Cr-Commit-Position: refs/heads/master@{#360562}

[modify] http://crrev.com/568075bbc5d16239a5cbdeb579a8768f9836f13e/third_party/WebKit/Source/core/frame/csp/CSPSource.cpp
[modify] http://crrev.com/568075bbc5d16239a5cbdeb579a8768f9836f13e/third_party/WebKit/Source/core/frame/csp/CSPSourceListTest.cpp
[modify] http://crrev.com/568075bbc5d16239a5cbdeb579a8768f9836f13e/third_party/WebKit/Source/core/frame/csp/CSPSourceTest.cpp

Comment 17 by ClusterFuzz, Dec 10 2015

Project Member
Labels: Nag
mkwst@: Uh oh! This issue is still open and hasn't been updated in the last 21 days. Since this is a serious security vulnerability, we want to make sure progress is happening. Can you update the bug with current status, and what, if anything, is blocking?

If you are not the right Owner for this bug, please find someone else to own it as soon as possible and remove yourself as Owner.

If the issue is already fixed or you are to unable to reproduce it, please close the bug. (And thanks for fixing the bug!).

These nags can be disabled by adding a 'WIP' label and an optional codereview link.

- Your friendly ClusterFuzz

Comment 18 by ClusterFuzz, Jan 1 2016

Project Member
mkwst@: Uh oh! This issue is still open and hasn't been updated in the last 42 days. Since this is a serious security vulnerability, we want to make sure progress is happening. Can you update the bug with current status, and what, if anything, is blocking?

If you are not the right Owner for this bug, please find someone else to own it as soon as possible and remove yourself as Owner.

If the issue is already fixed or you are to unable to reproduce it, please close the bug. (And thanks for fixing the bug!).

These nags can be disabled by adding a 'WIP' label and an optional codereview link.

- Your friendly ClusterFuzz

Comment 19 by mkwst@chromium.org, Jan 1 2016

Status: Fixed
This is mitigated via r360562 above, which adopted the behavior Firefox is running with (`img-src http:` === `img-src http: https:`). This won't fix variants of the attack that rely on cache timing, but it removes the trivial DOM event that the PoC relied on for 100% accuracy.

Comment 20 by ClusterFuzz, Jan 1 2016

Project Member
Labels: -Restrict-View-SecurityTeam Merge-Triage M-48 Restrict-View-SecurityNotify
Adding Merge-Triage label for tracking purposes.

Once your fix had sufficient bake time (on canary, dev as appropriate), please nominate your fix for merge by adding the Merge-Requested label.

When your merge is approved by the release manager, please start merging with higher milestone label first. Make sure to re-request merge for every milestone in the label list. You can get branch information on omahaproxy.appspot.com.

- Your friendly ClusterFuzz

Comment 21 by timwillis@google.com, Jan 8 2016

Labels: -Merge-Triage Merge-Request-48
Merge Requested for M48 - branch 2564

Comment 22 by tin...@google.com, Jan 8 2016

Labels: -Merge-Request-48 Merge-Approved-48 Hotlist-Merge-Approved
Your change meets the bar and is auto-approved for M48 (branch: 2564)

Comment 23 by timwillis@google.com, Jan 11 2016

@mkwst: Can you please land this today? Last M48 beta candidate cuts 12 Jan @ 5pm MTV time.

Comment 24 by bugdroid1@chromium.org, Jan 12 2016

Project Member
Labels: -Merge-Approved-48 merge-merged-2564
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ab830edb26a1f56f660b06459d70e1d48a707975

commit ab830edb26a1f56f660b06459d70e1d48a707975
Author: Mike West <mkwst@google.com>
Date: Tue Jan 12 08:56:39 2016

CSP: Source expressions can no longer lock sites into insecurity.

CSP's matching algorithm has been updated to make clever folks like Yan
slightly less able to gather data on user's behavior based on CSP
reports[1]. This matches Firefox's existing behavior (they apparently
changed this behavior a few months ago, via a happy accident[2]), and
mitigates the CSP-variant of Sniffly[3].

On the dashboard at https://www.chromestatus.com/feature/6653486812889088.

[1]: https://github.com/w3c/webappsec-csp/commit/0e81d81b64c42ca3c81c048161162b9697ff7b60
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1218524#c2
[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1218778#c7

BUG= 544765 ,558232

Review URL: https://codereview.chromium.org/1455973003

Cr-Commit-Position: refs/heads/master@{#360562}
(cherry picked from commit 568075bbc5d16239a5cbdeb579a8768f9836f13e)

Review URL: https://codereview.chromium.org/1581573002 .

Cr-Commit-Position: refs/branch-heads/2564@{#538}
Cr-Branched-From: 1283eca15bd9f772387f75241576cde7bdec7f54-refs/heads/master@{#359700}

[modify] http://crrev.com/ab830edb26a1f56f660b06459d70e1d48a707975/third_party/WebKit/Source/core/frame/csp/CSPSource.cpp
[modify] http://crrev.com/ab830edb26a1f56f660b06459d70e1d48a707975/third_party/WebKit/Source/core/frame/csp/CSPSourceListTest.cpp
[modify] http://crrev.com/ab830edb26a1f56f660b06459d70e1d48a707975/third_party/WebKit/Source/core/frame/csp/CSPSourceTest.cpp

Comment 25 by bugdroid1@chromium.org, Jan 14 2016

Project Member

Comment 26 by timwillis@google.com, Jan 19 2016

Labels: Release-0-M48 reward-topanel

Comment 27 by timwillis@google.com, Jan 20 2016

Labels: -reward-topanel reward-500 reward-unpaid
Hi jenuis - our reward panel reviewed this issue and decided to award you $500 for bringing this issue to our attention (even if you only gave us a week to fix it!). Although you probably already know this, bugs that are made public before we have a chance to fix them aren't usually eligible for a reward, but the panel decided to give you a one-off $500 reward anyway.

We'll list your name in the Chrome release notes as "jenuis". If you'd like me to update it to another name, please let me know.

Someone from our finance team should be in contact within 7 days to collect some details for payment. If that doesn't happen, please either update the bug or contact me at timwillis@

I'll update this bug shortly with a CVE ID for your records. Thanks again for helping secure chrome and happy bug hunting!

Comment 28 by timwillis@google.com, Jan 20 2016

Labels: CVE-2015-1617

Comment 29 by timwillis@google.com, Jan 20 2016

Labels: -CVE-2015-1617 CVE-2016-1617
CVE-2016-1617

Comment 30 by jen...@gmail.com, Jan 20 2016

timwil...@google.com, please list my name as "Yan Zhu" in the release notes. Thanks!

Comment 31 by timwillis@google.com, Feb 2 2016

Labels: -reward-unpaid reward-inprocess

Comment 32 by sheriffbot@chromium.org, Apr 8 2016

Project Member
Labels: -Restrict-View-SecurityNotify
This security bug has been closed for more than 14 weeks. Removing view restrictions.

For more details visit https://sites.google.com/a/chromium.org/dev/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 33 by sheriffbot@chromium.org, Oct 1 2016

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

Comment 34 by sheriffbot@chromium.org, Oct 2 2016

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

Comment 35 by mbarbe...@chromium.org, Oct 2 2016

Labels: allpublic

Comment 36 by awhalley@chromium.org, Apr 25 2018

Labels: CVE_description-submitted

Sign in to add a comment