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

Issue 878014 link

Starred by 1 user
Status: WontFix
Owner: ----
Closed: Aug 28
Cc:
█ kbr@chromium.org
vmi...@chromium.org
ericrk@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: ----
Type: Bug-Security



Sign in to add a comment

Security: side channel attacks for website fingerprinting and activity tracking through the GPU

Reported by nae...@gmail.com, Aug 27 
Hi --

Please see the attached paper that will be presented at CCS 2018.  We reported the vulnerability to Nvidia, and they are planning a public disclosure in October.  The Nvidia PSIRT team suggested that we share our results with browser developers.

Please feel free to contact me if you would like any further details.

Nael Abu-Ghazaleh
Professor, CSE and ECE Departments
University of California, Riverisde
---
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

An unprivileged application can track the activities of a browser through side channels using the memory resource APIs or the performance counter APIs.  The attack can be launched through graphics APIs such as OpenGL, or GPU compute APIs such as OpenCL or CUDA.

It appears that WebGL is not vulnerable at this stage, but we are concerned about future planned extensions which may enable the attack to be launched through malicious Javascript program.

VERSION
Chrome Version: [x.x.x.x] + [stable, beta, or dev]
Operating System: [Please indicate OS, version, and service pack level]

As far as we know -- all Chrome versions on Linux, Windows and possibly other operating systems are vulnerable.  Hardware rendering, which is on the Chrome roadmap, amplifies the vulnerability.

REPRODUCTION CASE
Please include a demonstration of the security bug, such as an attached
HTML or binary file that reproduces the bug when loaded in Chrome. PLEASE
make the file as small as possible and remove any content not required to
demonstrate the bug.

Please contact us.

FOR CRASHES, PLEASE INCLUDE THE FOLLOWING ADDITIONAL INFORMATION
Type of crash: [tab, browser, etc.]
Crash State: [see link above: stack trace *with symbols*, registers,
exception record]
Client ID (if relevant): [see link above]
ccs18_gpu_side_channel.pdf
1.3 MB Download

Comment 1 by vakh@chromium.org, Aug 27

Cc: kbr@chromium.org vmi...@chromium.org
Components: Internals>GPU

Comment 2 by vakh@chromium.org, Aug 27 

kbr@chromium.org, vmiura@chromium.org -- can you please take a look and comment whether there's anything actionable for Chrome?

Comment 3 by kbr@chromium.org, Aug 27

Cc: ericrk@chromium.org
Interesting paper. As I understand it, performance counters for tracking GPU memory allocations and shader execution are used to deduce the behavior of other applications running on the GPU. Using various machine learning techniques, the signal of other apps' memory allocations and other computations is processed, and with a reasonable degree of accuracy, the spy process can determine which web site the user is browsing to, and timing of keystrokes they input.

None of these measurement APIs are exposed to the web via WebGL or other APIs, so it's not possible to launch such an attack from a web page.

Plausibly Chrome could insert some sort of "chaff" allocations (like "chaff bugs" -- https://arxiv.org/abs/1808.00659 ) to deter introspection by other spy processes, and perhaps also some sort of chaff GPU computations, but defending against other hostile apps on the system isn't part of Chrome's attack model, and I wouldn't recommend doing so. (Though Chrome is trying to harden itself against the presence of malware on the system, IIUC.)

Thanks for the information. For the time being I think the browser doesn't need to do anything in response.

Comment 4 by tsepez@chromium.org, Aug 28

Labels: Security_Severity-Low Security_Impact-Stable
Status: WontFix (was: Unconfirmed)
Agreed.  Please re-open if there is a way for a web page to do this, otherwise see https://chromium.googlesource.com/chromium/src/+/master/docs/security/faq.md#Why-arent-physically_local-attacks-in-Chromes-threat-model
Project Member

Comment 5 by sheriffbot@chromium.org, Dec 5

Labels: -Restrict-View-SecurityTeam 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