Nvidia Blames Apple For Bug That Exposes Browsing In Chrome's Incognito (venturebeat.com)

An anonymous reader points out this story at VentureBeat about a bug in Chrome's incognito mode that might be a cause for concern for some Apple users. From the story: "If you use Google Chrome's incognito mode to hide what you browse (ahem, porn), this might pique your interest. University of Toronto engineering student Evan Andersen discovered a bug that affects Nvidia graphics cards, exposing content that you thought would be for your eyes only. And because this only happens on Macs, Nvidia is pointing the finger at Apple."

Comments

You're doing it wrong

[xxxJonBoyxxx]

>> I didn’t expect the pornography I had been looking at hours previously to be splashed on the screen

I think you're either doing it wrong or you're not looking at the right stuff. (Hours? Really?)

Re:You're doing it wrong

[WarJolt]

>> I didn’t expect the pornography I had been looking at hours previously to be splashed on the screen

I think you're either doing it wrong or you're not looking at the right stuff. (Hours? Really?)

Not everyone's a minute man, Johnny Boy.

Re:You're doing it wrong

[rsborg]

>> I didn’t expect the pornography I had been looking at hours previously to be splashed on the screen

I think you're either doing it wrong or you're not looking at the right stuff. (Hours? Really?)

"Hours previously" could simply mean "last night" (~8 hrs ago when you wake up).

It's your own fault Apple

[Anonymous Coward]

You insist on having your own slow ass OpenGL implementation for our cards, I guess you fucked up on security too.

Re:It's your own fault Apple

[Anonymous Coward]

You insist on having your own slow ass OpenGL implementation for our cards, I guess you fucked up on security too.

Patches from your proprietary GL implementation donated to the OpenGL Open Source project welcome, nVidia... don't bitch that it's slow when you're able to fix the slow yourselves.

Re:It's your own fault Apple

[Anonymous Coward]

You insist on having your own slow ass OpenGL implementation for our cards, I guess you fucked up on security too.

Patches from your proprietary GL implementation donated to the OpenGL Open Source project welcome, nVidia... don't bitch that it's slow when you're able to fix the slow yourselves.

You don't understand. *Apple* insists on having their own OpenGL implementation for GPUs they use (so they have identical GL api support on intel, amd and nvidia). They don't use Nvidia proprietary driver code, nor Open Source code, and since they don't care about performance (because of metal), their implementation is slow-ass...

Now get off my lawn ;^)

Re: It's your own fault Apple

[Anonymous Coward]

IOS saves screenshots of the applications for the task selector thingy and also for "fast" application switching where the screenshot is used for the zooming effect and as placeholder while the real application is still being (re)loaded. There is a separate screenshot for each orientation. It is possible that you launch or switch to the the browser or some other application and IOS will display a possibly very old screenshot of your private porn browsing session or some other private stuff that you had closed and purged from the logs ages ago. During the application switch effect the old screenshot is visible only momentarily but the same images can also be viewed from the task selector.

1. Device at orientation A: open browser, enter private mode and browse for some pron.
2. Switch to the home screen (screenshot it saved) and change to orientation B
3. Go back to browser and close all pron tabs
4. Switch to the home screen (screenshot is saved but this one is for orientation B)
5. Change back to orientation A and enter the task selector or go back to the application. The old private browsing screenshot should be visible.

Re: It's your own fault Apple

[TheRaven64]

The question is where the image is leaking from. It's either from the copy owned Chrome itself, or from the copy owned by the window server. Apple's window server keeps a copy of the frame buffer to allow the system to kill the underlying application (if it advertises support for sudden termination) and have it resurrect in the same state without the user being aware. This is part of the mechanism on Darwin for handling low-memory situations: an application that has no unsaved state is killed and is then restarted when the user attempts to interact with it. This copy of the window contents may last for longer than the attached application (I don't know what the policy is for garbage collecting them).

Except it's not.

[Anonymous Coward]

This isn't just on Apple's OS. While I have nothing like Mr. Andersen's writeup to prove it, I've seen this kind of bug happen on Windows.

Re: Except it's not.

[kthreadd]

I've seen it on GNU/Linux with Nvidia cards and their non-free driver for several years. This is not new and its not just Chrome.

Re:Except it's not.

[tgv]

Me too, and on tablets as well, in "Edge", no less. Usually it's very short lived. According to me the lesson is: applications need to erase all memory before closing a "private" session if the OS doesn't guarantee it.

Re:Except it's not.

[AmiMoJo]

Unlikely, because Windows does enforce clearing of newly allocated memory, including on the GPU. The drivers would fail WHQL certification if they didn't. The probably didn't bother on Mac OS either because of an oversight or to get a little more performance.

It might be possible within specific apps if they mismanage GPU memory, but certainly not across apps as described in TFA. Well, unless there is some unknown bug, but Nvidia are saying there isn't and it is tested for WHQL certification.

Gonna need to see some more evidence than an anecdote I'm afraid. All available evidence says that Windows is unaffected.

Re: Except it's not.

[tibit]

The OS has very little control here, since the memory is not handled as memory, but as graphics resources. What's passed around isn't memory pages but texture buffers etc. These are managed by the graphics driver, and the OS expects the driver to do the right thing. I don't even think it's possible for the OS to handle this properly without there being clear API protocols that give the OS enough knowledge about what resources are passed around, and when they should be zero-initialized.

Simple explanation

[mcrbids]

So, your program allocates some memory. Should it initialize the memory to make sure it's all a bunch of zeros? Apparently, Nvidia doesn't think so.

So, a program running on your OS requests some memory. Should the OS initialize the memory before handing it to the application? Apparently, Apple doesn't think so.

Either answer is right.

Re:Simple explanation

[Anonymous Coward]

It needs to be cleared by the OS 100%. The OS can't expect/assume this is done elsewhere, or stuff like this happens.

Re:Simple explanation

[Kjella]

So, your program allocates some memory. Should it initialize the memory to make sure it's all a bunch of zeros? Apparently, Nvidia doesn't think so. So, a program running on your OS requests some memory. Should the OS initialize the memory before handing it to the application? Apparently, Apple doesn't think so. Either answer is right.

Not really. An application will typically allocate and release memory all the time, being forced to clear it every time is massive overkill and a performance problem. The driver exposes the GPU memory, the OS allocates it to applications just like with RAM. It's the only one that knows when memory switches application context and must be cleared. So there's really only one sane solution.

Re:Simple explanation

[dgatwood]

Not really. An application will typically allocate and release memory all the time, being forced to clear it every time is massive overkill and a performance problem. The driver exposes the GPU memory, the OS allocates it to applications just like with RAM. It's the only one that knows when memory switches application context and must be cleared. So there's really only one sane solution.

The usual solution is basically:

• Whenever you add a new page into an application's address space, you map a zero-filled page as copy-on-write. If the page never gets touched, it is zero-filled, and you take the performance hit only when it ceases to be all zeroes.
• Small allocations are allocated using a pool allocator backed by those pages.

This works well as long as the CPU is in charge, ensuring that any dirty data must have originated in some other part of the app (by reusing a pool region). Where it starts to get hairy is when you have a GPU that has access to all of RAM and uses a separate page table with separate COW flags, etc.

I'm not certain what went wrong in this particular case. However, I do remember a really annoying change in about 10.6 or 10.7 where Apple stopped using a vertical blanking interrupt to control various aspects of the GPU's operation and maybe some other parts of the OS. This improved battery life, IIRC, but the result is that you'll often see the GPU draw a frame of video before the previous contents of VRAM have gotten wiped. I would not be at all surprised if that was what happened here.

As for whose responsibility it is to clear the memory, my gut says that if Chrome wants to guarantee that its video buffers are cleared, Chrome is responsible for doing it. Otherwise, it should assume that VRAM is a shared resource, and anything it puts in VRAM can potentially be accessed by any other app at any time for any reason. With that said, I'm open to other opinions on the matter.

Re:Simple explanation

[BoberFett]

It's not just about a moment of graphical corruption, that's an annoyance. But a process being able to access the RAM leftovers from a previous process is begging for memory based attacks. Even though it's on the GPU, it's a vulnerability. What's to say that GPU wasn't just displaying banking info? The OS should not assume the application is friendly and blanking the VRAM. That security is on the OS.

Re:Simple explanation

[Lonewolf666]

It is nice if the OS does the clearing, but the application programmer should not rely blindly on it.

For the application programmer, it depends on how much a data leak in the application would hurt.
-If the OS specifies that memory is cleared, relying on it it is IMHO OK for low security applications.
-For high security applications, always clear the memory. Don't trust that the OS does it.

Re:Simple explanation

[AmiMoJo]

Clearing allocated memory before handing it to applications is required by POSIX and generally a really, really good idea from a security point of view. The performance hit is minimal (modern CPUs and RAM can write gigabytes per second easily) and can be mitigated, e.g. by using a pre-allocated pool for small allocations.

All modern operating systems clear allocated memory. It's basic security to stop one app stealing data from another, or even worse the kernel. You could do it the other way around and try to remember to always clear sensitive data before deallocation, but aside from the high probability that someone will forget to do it, it is very hard to figure out what is really sensitive. Something seemingly unimportant might be useful for an exploit you didn't anticipate. So clear on allocation is the best, safest solution and has minimal down sides.

Re:Simple explanation

[tibit]

The OS has the responsibility to ensure that there is no unintentional sharing of data between processes.

In general, it's impossible for the OS to guarantee that, since drivers are nominally accessible by multiple processes at once. Say a serial port driver has a bug and doesn't wipe the buffer between closing and reopening of the device: OS can't help here, it's a driver bug that leaks data between processes here. Same goes for graphics drivers.

Here's what happens: GPU memory is allocated in chunks of wildly varying sizes. To maximize the amount of usable GPU memory, the objects (buffers) owned by various clients of the driver can be allocated adjacent to each other. I.e. the driver doesn't (and shouldn't) have higher-level subdivisions, such as pages, that are owned by one process only. The driver bug is that the GPU memory a buffer is using not cleared before being passed to a different process. This is a very performant sidechannel that leaks data between supposedly isolated processes. This is very bad indeed.

The Chrome bug is that it accepts buffers and doesn't clear them before selecting them as textures.

Re:Chrome?

[Anonymous Coward]

No, his reason is that sweet sweet +5 insightful. We don't need your facts around here.

Re:Not cool

[SeaFox]

Does that mean I have to throw away my porn iPad and go back to my porn ChromeBook?

I hate that. Just moving the bookmarks will take forever.

Joke Fail.
You're using Chrome on both, so bookmarks are synced through your Google account.

Easy Fix for the Paranoid: Cold Reboot

[slacka]

I've done some GLSL programming and it's not unreasonable for clearing a GPU buffer to take 1/20 to 1/10 the time as the actual operation on that buffer. How many Nvidia users (read gamers) would prefer to take a 5% performance hit to prevent occasional glitches like this?

This has absolutely nothing to do with Nvidia's drivers. It is a glitch in Diablo III and maybe something Chrome could address for the paranoid out there. Meanwhile, if you're really that worried about someone seeing a glimpse of your porn hours earlier, just turn your computer off/on before allowing anyone to use it next. Problem solved.

Re:Easy Fix for the Paranoid: Cold Reboot

[afourney]

It's not a 5% hit. You only have to clear the buffer once on exit. And, Nvidia is right:This is something the OS should do (just like it closes filehandles, and frees other resources on exit). Why not leave it up to the app? Because, apps don't always exit cleanly.

Re:Easy Fix for the Paranoid: Cold Reboot

[_merlin]

The thing is, for security the operating system should scrub memory before before supplying it to an application. Otherwise you get all kinds of data leakage. The virtual memory system does this when an application requests more pages. SPARC CPUs generate an interrupt when they run out of "clean" register windows. NTFS ensures sectors that are allocated but not written in a files read as zeroes (FAT32 on Windows 95 didn't, you'd read back whatever was there on the disk). By the same token, the OS should scrub GPU resources before supplying them to an application. You don't need to do this on every allocation, only when the allocation comes from RAM that was not previously assigned to that application.

Re: Easy Fix for the Paranoid: Cold Reboot

[Dog-Cow]

There isn't a single OS that doesn't do this. You wrote a bunch of crap that has nothing to do with what the GP wrote.

Blame Chrome

[pushing-robot]

Chrome advertises its Incognito mode as leaving no traces behind. Therefore, it should be responsible for wiping its framebuffer, just as it clears caches, cookies and history. It's like writing a file shredder that doesn't actually overwrite files, then blaming the OS and hard drive manufacturer for the oversight.

It might be nice if framebuffers and such were zeroed on release, but like overwriting files, it's a time/energy/security tradeoff. Besides, the screen isn't really protected anyway; IIRC applications on most OSes can capture the screen without even admin privileges. After apps are sandboxed into seeing only their own windows we can talk about securing the framebuffer.

Re: Blame Chrome

[guruevi]

There are also some limitations to what a program promises vs what it can do. File shredding is an optimal example: modern SSD do not even write to the same physical location every time you write to the same file. Battery backed controllers fool the OS in thinking a certain action was completed while it really wasn't committed to disk yet. If you pull a disk between the shredding event and the cache flush, you could easily read things. Heck, if your magnetic drive says a portion of it's drive are "bad blocks" the data on those blocks doesn't get overwritten, SSD's have cells that can physically go "read-only", with the right tools you can read the data in the "bad blocks" or "read only" cells.

Re:Chrome?

[thegarbz]

Somehow, the idea that people would trust incognito mode in a browser made by a company whose profits mainly come from targeted advertising strikes me as really hilarious.

Why? They are two different and not incompatible processes. The company performs analytics and collects information about you to store on its servers. The incognito mode is designed to ensure a trace of the browsing session is not left on your PC.

There is a very big difference between the form of data collection here as well as the result of it. Mother is not going to know I search for dirty things based on Google's data collection.

incognito starts remembering history

[endangeredcritters]

There is a far simpler way to defeat chromes incognito mode, just use it for awhile. After some unknown (not forever) period of use, it will start to not forget history even after it's been shutdown and restarted. At least in 'Version 44.0.2403.107 (64-bit)' running in Linux Mint.

It doesn't just happen on Apple

[polgair]

I've got an older GTX 760 running on an HP Z820. I run ubuntu on this thing and use nvidia-352 drivers. When I log out of gnome3 and log back in through lightdm, I see the same exact symptoms. I can see what was previously displayed on my framebuffer, including firefox and chromium windows.

This, this, this!

[tlambert]

Chrome advertises its Incognito mode as leaving no traces behind. Therefore, it should be responsible for wiping its framebuffer, just as it clears caches, cookies and history. It's like writing a file shredder that doesn't actually overwrite files, then blaming the OS and hard drive manufacturer for the oversight.

This, this, this!

If it's incognito, it should not trust anyone else to ensure the privacy of the user's data, not even the OS. We already know that it's possible to use CPU cache bugs as a covert channel to snoop on other processes running on your computer; if the application claims to maintain security, it needs to zero the memory itself.

As an aside, a GPU is a better machine for zeroing pages than the main CPU, and won't pipeline stall or time stall the main CPU by doing it, and GPUs are traditionally really good at manipulating large amounts of memory. So one has to wonder: why doesn't nVidia expose a primitive that Chrome can then use to zero the pages of a frame buffer, before or after it is used?

Only part of the problem.

[dlingman]

There are two real issues here.

The first is that malicious programs could open up, grab screen buffers, and get access to stuff that had been on the screen to use for their nefarious purposes.

This is bad, and unless we get decent support to isolate the frame buffers (and other graphic memory) between apps at either the driver or hardware layer, it's not going away anytime soon. Dont want this? Power cycle (all the way off - not just hiberante) between application launches would do it.

The second is sloppy programming on the part of non-malicious applications. That's what is being talked about in the application. Diablo apparently asked for a frame buffer, and then presented it, as is, to the user without putting what it wanted in place, trusting for it to be in a particular state. Which it wasn't.

You want a black screen to show to the user, then write zeros into your buffer before you show it to the user. Decent compilers/languages will tell you if you've tried to read from unitialized variables, and you should never trust that anything you've asked for dynamically is in a safe state, unless you've explicitly requested that it's cleared before being handed to you. Why should a resource from the graphics card be treated any differently?

NVidia is right about one thing here - most of the time, nearly all of the time, the thing you do with that buffer you're given is to write your stuff into it, completely overwriting it, and it would slow things down if they had to guarantee that it was cleared before handing it out to you. If your program doesn't care enough to do so itself, that's not really their fault.

It would be nice if, on program exit, all GPU resources used by that app were flushed, but again, that would involve the OS needing to be told of all the GPU resource allocations and deallocations so it could clean up properly, and that too would probably slow things down. Not a lot, but enough to be annoying when your game stutters.