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 46 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment
link

Issue 477328: Security: Incognito information leak

Reported by charlieh...@overclocked.net, Apr 15 2015

Issue description

VULNERABILITY DETAILS
Incognito mode exposed my porn to a family member!

How?

GPUs don't respect process boundaries - physical memory is NOT zeroed when it is passed to a new process. When you close an incognito window, all GPU assets (framebuffer, textures, etc) are left sitting in VRAM. Later, another application can create a new buffer on the GPU and find it filled with the previous incognito window contents. 

I discovered this in the most painful way possible - Diablo 3 has a bug with it's loading screen - it doesn't clear the background to black - it just allocates a new texture and renders it. In this particular instance, it got an almost pixel perfect copy of some porn I had viewed a few hours earlier. To make things worse, the game was frozen on this screen for several seconds as it loaded...

Exploiting this issue reliably is problematic as it relies on the behaviour of the GPU driver's memory manager. I've written a simple OpenGL application in go to try and demonstrate the issue, but it doesn't always produce pixel perfect reproductions. 

I've included the program source, as well as the diablo launch screen (that my family so helpfully screenshotted for me :/ ). I also included some screenshots of my exploit running to various degrees of success (using reddit.com as a target)

This isn't really an exploitable bug, but it is a problem for anyone expecting incognito mode to hide their browsing on a shared computer. 

HOW TO FIX
Draw black into every graphic asset and texture before freeing it (stuff still leaks on a crash, but without patching the gpu driver you can't fix that)


VERSION
Chrome Version: 41.0.2272.118
Operating System: OSX 10.8.5
Graphics Card: Dedicated AMD or NVIDIA cards only - this doesn't happen on intel graphics

REPRODUCTION CASE
Run the attached program with the --clear-memory problem first 
Close an incognito window
Run the attached program with no arguments, hit enter repeatedly to see different segments of GPU memory. You will often see contents from the incognito window.
 
chrome_vram_leak.zip
3.0 MB Download

Comment 1 by f...@chromium.org, Apr 16 2015

Status: WontFix
Hi, thanks for the report.

Incognito does not provide guarantees for hiding browsing on a shared computer. (Someone who could see the shared memory could also install a keylogger, etc. on your computer.)

You can read more about Incognito here: http://www.chromium.org/Home/chromium-security/security-faq#TOC-What-are-the-security-and-privacy-guarantees-of-Incognito-mode-

Comment 2 by ClusterFuzz, Jul 24 2015

Project Member
Labels: -Restrict-View-SecurityTeam
Bulk update: removing view restriction from closed bugs.

Comment 3 by netheri...@gmail.com, Jan 10 2016

> Incognito does not provide guarantees for hiding browsing on a shared computer. (Someone who could see the shared memory could also install a keylogger, etc. on your computer.)

Deliberately installing a keylogger to monitor you and accidentally seeing you watching porn is entirely different. If incognitio mode cannot even defend against that, what purpose does it serve at all? It is not like it can defend against anyone on the network.

Comment 4 by noamne...@gmail.com, Jan 10 2016

While this is only a problem when other programs have bugs, the bottom line is that incognito doesn't do its intended job (preventing accidental glimpses into private browsing) as long as this hole isn't patched.

While fixing the bugs in all other software in the world would be the ideal solution, making Chrome clear the buffer before quitting an incognito window would be more pragmatic.

From a PR perspective, most users would blame Chrome, anyway.

Comment 5 Deleted

Comment 6 by btek.p...@gmail.com, Jan 10 2016

actually the inherent issue here is that chrome should be assuring that this memory is cleared or zeroed out somehow.
since chrome is initializing the buffers that hold and manipulate this memory that is being leaked then chrome should be responsible for assuring that this memory is cleared out which is obviously not happening here.

after all, you are responsible for cleaning up any resources your application allocates and this issue should be dealt with by chrome developers since this issue at hand is being raised due to data allocated and manipulated via chrome clearly not being wiped.

Comment 7 Deleted

Comment 8 by nduca@chromium.org, Jan 11 2016

Cc: vmi...@chromium.org kbr@chromium.org enne@chromium.org
Labels: Cr-Internals-GPU
+gpu peeps

Comment 9 by f...@chromium.org, Jan 11 2016

Labels: -Type-Bug-Security Type-Bug
Status: Available
Marking this as available if someone from the GPU team would like to take a look at it as a general resource issue.

Comment 10 by vmi...@chromium.org, Jan 11 2016

Interesting.  We could attempt to clear textures, however drivers are free to re-allocate, mirror textures in memory, or otherwise work around us trying to clear textures, so I don't think we could guarantee that all memory is scrubbed without driver support.

Comment 11 by me...@meganwalker.me.uk, Jan 11 2016

I think as long as you scrub your own allocated memory, the driver should be responsible for making sure that any memory it allocates is scrubbed before handing it over.

Comment 12 by kbr@chromium.org, Jan 11 2016

Cc: -kbr@chromium.org reve...@chromium.org
Chromium already clears all textures it allocates before it uses them. It doesn't clear them when it releases them. Plausibly, in incognito mode, Chromium could clear those textures upon releasing them. Most GPU drivers do not zero out textures, buffers, or other GPU-side allocations before returning them to applications, ostensibly for performance reasons -- Chromium's code would be simpler if they did.

Comment 13 by vertigo...@gmail.com, Jan 12 2016

I don't use Chrome for sensitive stuff, since I don't trust Google when privacy is concerned; However, I'm always a proponent of furthering privacy and fixing potential causes for privacy leaks or violations.

I find it interesting the official response appears to be that incognito mode does not guarantee privacy locally. First of all, it clearly states when you enable it that it doesn't protect your privacy from others on your network, your ISP, or the websites you visit. OK, fine. That makes sense, and is fairly obvious. But now Google is saying it doesn't protect you locally either. So what's the point?? That's a somewhat rhetorical question, since it does still at least somewhat protect you, which is better than nothing.

But that leads me to my second point: something is better than nothing, and while sure, it can't "guarantee" your privacy, that doesn't/shouldn't mean that should be used as an excuse to not do everything reasonably possible to protect it. Just because somebody can use keyloggers, screen capture, or any number of other things to snoop on a user, doesn't mean this should just be ignored. I don't think any reasonable person expect Chrome to protect their privacy against someone actively trying to spy on them. But this is an issue that resulted in an accidental exposure, which should not occur.

And yes, it would be ideal if the video drivers did their part, but that can't be relied on. Chrome (and any browser with an incognito mode) has a responsibility to do what they can to protect users' privacy. If they're not willing to do this, then either the incognito mode should be removed or the warning should be modified appropriately so users can find another one that does.

Comment 14 by marat.bu...@gmail.com, Jan 12 2016

Function readPixels() is also available in WebGL. So, personal data from not zeroed VRAM potentially can be leaked via malicious web site.

Comment 15 by kirus...@gmail.com, Jan 12 2016

Let's just fill all the textures, frame buffers, etc. with random bytes before memory release?

Comment 16 by reve...@chromium.org, Jan 12 2016

Cc: piman@chromium.org ccameron@chromium.org
Owner: vmi...@chromium.org
Status: Assigned
Sorry to hear that you were affected by this problem. As kbr@ already mentioned, Chrome will already clear textures before usage if necessary and that should be sufficient to protect against contents from one renderer process (tab) leaking to another. If that's not working properly then it needs to be fixed.

FYI, the benefit of clearing textures before use instead of when done using them is that if the page is behaving well and initializes the textures before use then we can detect that and avoid clearing them and the performance cost of doing so.

Comment 17 by reve...@chromium.org, Jan 12 2016

Ah, this is actually a different application showing the contents previously displayed by Chrome and the driver failing to provide reasonable process isolation for vram.

Maybe our use of IOSurfaces in more recent versions of Chrome provides better protection against this. Have your tried reproducing this with latest unstable version of Chrome?

Comment 18 by kbr@chromium.org, Jan 12 2016

WebGL never allows uninitialized VRAM to become visible to JavaScript, neither from the readback path (ReadPixels) nor during rendering to the screen.

Comment 19 by ccameron@chromium.org, Jan 12 2016

I suspect that IOSurfaces may be scrambled, due to slightly different memory layout. Try again with Chrome Canary (Chrome 49), and see what happens.

Comment 20 by vmi...@chromium.org, Jan 12 2016

I don't think we want to ignore this issue.  My concern is how to effectively deal with it.

Clearing textures before release may reduce the frequency of this data leak, but wouldn't guarantee it.  As mentioned, drivers are free to re-allocate and mirror buffers, and often do.

* Driver can reallocate a texture on initialization

  load 'porn' to texture_xxx     => load @ 0x1000000
  draw with texture_xxx
  load 'kittens' to texture_xxx  => load @ 0x2000000 and defer deletion of 0x1000000

* Driver can ignore texture initialization as an optimization

  load 'porn' to texture_xxx     => load @ 0x1000000
  draw with texture_xxx
  load 'black' to texture_xxx    => ignored, because no visual effect
  delete texture_xxx

With the latter, we would have to take steps to thwart these optimizations in drivers.

Regarding window surfaces, we would have to clear all back-buffers.  Would make window re-sizing without visual corruption an interesting problem.  Also there isn't a hard rule that swapping a surface always returns the same buffers [for us to clear].

Comment 21 by labobol...@gmail.com, Jan 14 2016

I have this issue on windows sporadically when turning on fullscreen for youtube or media players. Sometimes I see a background chrome window flash by or something else. Don't think it's related but I mention it just in case.
Nothing reproducible but happens when the computer is slow.

Sounds like you need a SecureZeroMemory function for gpu. Password managers use that and similar functions for clearing sensitive memory before releasing the memory. Odd that chrome's incognito mode doesn't do that for gpu.
Hope you at least use it for your internal password manager.

Comment 22 by vmi...@chromium.org, Jan 16 2016

laboboLink: The issue you're describing sounds like a back-grounded window is revealed while going to full screen.

Memory zeroing in this case is expected of the OS.  We're still investigating the details.  User may need to update from OSX 10.8.5 (Mavericks) to a newer version.

Comment 23 by ccameron@chromium.org, Jan 16 2016

Attaching a simple application (<100 lines) that reproduces the issue as well. Also attaching a screenshot showing Safari's memory leaking into the another application's window while using the Intel integrated GPU.

This bug is not specific to Chrome and it's not specific to NVIDIA.
Screen Shot 2016-01-16 at 5.33.11 AM.png
908 KB View Download

Comment 24 by ccameron@chromium.org, Jan 16 2016

Attaching another application which will keep cycling through memory every time you press space. The screenshot shows the "Favorites" page and the "Poster Circle" page.
gl_texture_leak.mm
2.7 KB Download
Screen Shot 2016-01-16 at 5.54.48 AM.png
2.7 MB View Download

Comment 25 by xste...@gmail.com, Jan 28 2016

Confirmed happens between Win10 and Fedora/Gnome also. Rebooted from Windows to Fedora. Logged in via GDM. Screen flashed before desktop loaded with image of Windows10 chrome window. Rebooted, got another remnant on login.

Comment 26 by vasi...@chromium.org, Feb 24 2016

Cc: engedy@chromium.org
Components: Privacy

Comment 27 Deleted

Comment 28 by rhalavati@chromium.org, Apr 20 2018

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

Comment 29 by rhalavati@chromium.org, Apr 24 2018

Hi,

Is this issue fixed, or being worked on?

Comment 30 by rhalavati@chromium.org, May 4 2018

Based on offline discussion with Victor:

Wiping allocated memory before releasing it in incognito is an option, however it would still be difficult to guarantee additional privacy. Texture and display memory is managed by OS and graphics drivers, and they can take ownership of buffers or keep copies of memory, so clearing all known buffers wouldn't be able to clear all traces.  Further if our processes crashed it would also leave buffers uncleared.

Comment 31 by rhalavati@chromium.org, May 4 2018

I think although the sand boxing is something that should be expected from OS and graphics driver, it would still be good that we do some preliminary clean up in incognito.

Comment 32 by benhenry@google.com, Jan 11

Labels: Pri-2
Setting defect without priority to Pri-2.

Sign in to add a comment