back to article Nvidia GPUs give smut viewed incognito a second coming

Canadian student hacker Evan Andersen says Nvidia graphics cards retain content users would rather not be preserved, such as the material appearing in web pages viewed in the supposedly-private "incognito mode" offered by Google's Chrome browser. The flaws were reported to Nvidia and Google in 2014; the former did not respond …

  1. Medixstiff

    So basically the guy has admitted to everyone he watches pr0n, I wonder if his bosses requested his browsing history at work be checked?

    1. Anonymous Coward
      Anonymous Coward

      Is there anyone anywhere who doesn't watch the occasional bit of porn? Apart from Teresa May who -I expect- bean flicks while reading Mein Kampf. Porn followed by gaming strongly suggests an at home/off-duty scenario.

      1. stu 4

        Teresa May Porn

        And of course the irony is... search for 'teresa may porn' and you'll find it! - she was a 90's soft porn star in the UK.

        1. Simon Harris

          Re: Teresa May Porn

          That's an image I really don't need at lunch time!

        2. This post has been deleted by its author

      2. Anonymous Coward
        Anonymous Coward

        Is there anyone anywhere who doesn't watch the occasional bit of porn?

        Contrary to popular belief, yes such people do exist. They have quite an active community/cult on a certain subreddit about the evils of porn addiction.

        I would also imagine that asexuals (the orientation, not the method of reproduction) don't indulge in porn. It would, after all, be a little more than a waste of time for someone who is neither capable of being physically attracted to anyone nor at all interested in sex.

      3. Anonymous Coward
        Anonymous Coward

        >Is there anyone anywhere who doesn't watch the occasional bit of porn?

        I don't, since I don't find other people attractive.

        I look at a lot of hentai artwork, though.

    2. Robert Helpmann??
      FAIL

      So basically the guy has admitted to everyone he watches pr0n...

      Yes, and he can stand proud for having seen it twice and realizing what that meant. NVIDIA and Google are the ones who should be ashamed of their limp performance, though. Google puts out an application that it says will clear all evidence of itself, is informed this is not in fact the case and then blows it off as someone else's problem. And what does NVIDIA say concerning a flaw in their memory management that makes it trivial to do a side-channel (I so wanted to say "back door" here, but it really isn't) attack to take screen shots of whatever their cards put up on the screen? .... Anyone? No? It appears to be at least misleading in the first case and negligent in the second.

      1. webfox

        This is why Google tossed it back to nVidia. The information was stored on the video card. nVidia is responsible for the content stored on its hardware. Google is not at fault. (Can't believe I wrote that last sentence...)

        1. Charles 9

          But Google created the content AND presented it on an OS with GPU compositing, meaning they KNEW their stuff would show up on the GPU's RAM. As as saying goes, "You made the mess. You clean it up." There's not much Google can do with active Incognito pages in GPU RAM since it must be in an accessible state for the GPU to put it on the screen. But once the page closes, Google should assume the memory won't be cleaned up on its own, so it should zero or otherwise blank the page before releasing it.

          1. Olius

            "Google should assume the memory won't be cleaned up on its own, so it should zero or otherwise blank the page before releasing it."

            With main memory, the physical ram is constantly allocated and reallocated. Pages are swapped to disk and back. The physical ram is a fluid object. This means that when a page of physical ram is allocated to a process, it may be a reallocation of a page used a second ago by a running process. If the VM subsystem didn't clear it before page allocation, the second process would see what is currently in it - SSH keys, for instance. The first app has no idea that the page will be reallocated and therefore cannot clean it. In any case, "cleaning" it would mean deleting data necessary for the process to continue running.

            This is why memory should always be zero'd before allocation - you literally have no idea what just used it or how, and the only thing that can zero it effectively is the OS's allocation subsystem.

      2. dmacleo

        limp performance,

        ****

        heh heh bad thing to have when dealing with pr0n

      3. Anonymous Coward
        Anonymous Coward

        fnarr fnarr! "Stand proud"

        Oooerrrr "Limp performance"

        FNARRR FNNNAAARRR!!! "Back door!!!!"

    3. DropBear

      Now I'm kinda wondering if there ever was a video driver from any manufacturer who went to the trouble of actually cleaning memory - to be honest, I remember seeing this sort of "flash something at video resolution change" quite a few times in the past; I always considered it shoddy and inelegant programming (wait, is there any other kind left?) but didn't quite realize the privacy implications...

      1. P. Lee

        Driver issue surely?

        If it's a privacy problem, it should be up to the os or driver to clear it. Don't rely on apps to do the right thing. That said, privacy-concerned apps should double check if they can.

        1. TheVogon

          Re: Driver issue surely?

          "If it's a privacy problem, it should be up to the os or driver to clear it"

          No, it should be up to the app that's doing something privacy sensitive to clear it before closing it. Zeroing a large buffer has a performance hit, and it's not needed most of the time. I would also expect an app to ensure a newly requested buffer was initialised with the desired content before displaying it to screen.

        2. Crazy Operations Guy

          "it should be up to the os or driver to clear it"

          No, its clearly a hardware issue. The MMU being used seems to not be doing its job. A proper MMU should, at the very least, clear the contents of any memory that is to be assigned for use. Nowadays, it should be clearing memory as soon as its been freed. At the very least, it should be part of routine house-keeping on the part of the MMU.

          Although a part of me suspects that there isn't even an MMU present at all, which is quite troubling...

      2. Stoneshop
        Facepalm

        Video driver clearing memory

        Usually, a driver has routines for 'change video mode' and 'clear screen' (== zero framebuffer); the most obvious thing to do is clearing after mode change, but it depends on the application writers to do both in sequence. Zeroing a large buffer might take a while, and if the next thing you do is loading a full-screen bitmap anyway, clearing the screen first might be considered a waste of time. You could even figure out the new framebuffer first, load the bitmap and then switch modes, in which case you obviously don't want to clear after switching. Or it's simply a bug in the application.

        IMO in this case the bug lies squarely with Chrome: if you go out of private mode, you erase ALL of the stuff you did until then.

        1. A Non e-mouse Silver badge

          Re: Video driver clearing memory

          Zeroing a large buffer might take a while

          But doesn't an O/S kernel zero out regular memory before handing it to an application? And aren't there specific CPU instructions for doing this to make it as efficient as possible?

          GPUs are often touted as having large memory bandwidth, so surely they can use a bit of that to zero out a newly allocated region? Surely a new framebuffer allocation isn't going to be in the "hot" path of drawing an image on the screen but in the initalisation code path?

          1. Charles 9

            Re: Video driver clearing memory

            "But doesn't an O/S kernel zero out regular memory before handing it to an application?"

            Why should it? The memory you get from an allocation should be considered to be "undefined", and therefore it should be the applications' responsibility to handle it accordingly, using as you said common memory-fill techniques if necessary.

            "GPUs are often touted as having large memory bandwidth, so surely they can use a bit of that to zero out a newly allocated region?"

            Again, that's if they WANT that. If you're allocating the framebuffer to say play a video, then zeroing is redundant. You let the video take care of that.

            I'm agreeing with the point that if an application is touting a low-trace operating mode, the onus is on the application to ensure low-trace operation.

            1. maffski

              Re: Video driver clearing memory

              Why should it? The memory you get from an allocation should be considered to be "undefined", and therefore it should be the applications' responsibility to handle it accordingly, using as you said common memory-fill techniques if necessary.

              Unless of course the application wants to see what was in the memory previously...

              It's basic defensive programming. You always assume the things you can't control were written by idiots*. So, whose fault was it that the memory wasn't cleared - the browser, the OS or the driver? All of them. They didn't know another part of the stack had cleared it, so they should have assumed it was their job. The only one not to blame is Diablo, as they don't care what was there previously, although it would have been neater to blank the frame buffer.

              * - It's also best to assume the code you wrote was written by an idiot as well

              1. Charles 9

                Re: Video driver clearing memory

                Basic defensive SECURITY programming says Don't Trust ANYONE. That goes backwards AND forwards. In other words, don't make assumptions of inputs AND don't release anything you don't want seen since anything you release COULD be seen. So like I said, Chrome should wipe any Incognito pages before releasing their framebuffers on the assumption that they don't want the contents to be visible to anything else.

                There's also the matter of the KISS principle. Assume the least work was done on your request, and do yourself the least amount to accomplish your goal since you may be subject to delays or repetition that result in small delays adding up. Why should Diablo blank their framebuffer if they're just going to immediately overwrite it anyway?

                1. Cynic_999

                  Re: Video driver clearing memory

                  "

                  Why should Diablo blank their framebuffer if they're just going to immediately overwrite it anyway?

                  "

                  Immediately? The contents remained without overwrite long enough for the user to recognise the image it contained. Which is one heck of a long time in CPU cycles - consider that the entire buffer can be completely overwritten within 1/30th second at the very least (otherwise it would be incapable of displaying standard NTSC videos).

            2. Saigua

              Re: Video driver clearing memory

              As reported it seems like the video replayed. If it's Flash, won't fix deprecated things seems to apply, but if it's incognito mode and HTML5, seems pretty significant to issue, commit and execute the GPU cache and data (otherwise frustrated by OpenCL, which I thought we liked.)

              Contrawise, if there were a link that broke out bugzilla or git so:

              -Reproduced with 4K HSVC 3D Gay pr0n; 2 hour video plays during aggravated Just Cause 5 Load (parameters at link, etc.) Came twice anyhow like always with loading screens.

              -Reproduced with Hatsune Miku while falling at 7000' in an updraft 3:40.2. Came twice. Peckish.

              -Reproduced with locals. Came four times. 5:13:11 according to FitBit. More worried than anything I can't remember seeing them.

              -Cannot reproduce; it's video not actual fecundity. [Don't want to know.]

            3. Suricou Raven

              Re: Video driver clearing memory

              "Why should it?"

              Security. An application could malloc() a big chunk of memory and there's a good chance of extracting cryptographic secrets or other things it should not have from memory recently free()ed from another process, or from a process that terminated.

              It's a compile-time option for the linux kernel. The default is to zero, but you can disable that to slightly improve performance in very resource-tight embedded environments.

            4. patrickstar

              Re: Video driver clearing memory

              The OS most certainly does. Otherwise you'd be in for a world of hurt in any multi-user environment.

              malloc generally doesn't however, so you can expect to see old data from the _current_ process. However, if the kernel ever hands you a page (eg via sbrk/mmap on *ix) without clearing it from the previous owner , it's a (potentially severe) security issue, not normal or intended behavior.

              For some details on this in Windows, see http://blogs.msdn.com/b/tims/archive/2010/10/29/pdc10-mysteries-of-windows-memory-management-revealed-part-two.aspx and mm\zeropage.c in the Windows kernel source.

              On *ix it's frequently implemented somewhat differently, with zero-fill-on-demand (i.e. pages aren't actually zeroed out until they are accessed under new ownership for the first time).

          2. Dazed and Confused

            Re: Video driver clearing memory

            This should be a C2 security failure, reusable resources should be cleaned before reuse.

            Imaging if the GPU was doing the whole video session, it could have the credentials including passwords etc in it's memory, these could then be picked out by another app on the same box.

            This is a major security snafu.

        2. Ken Hagan Gold badge

          Re: Video driver clearing memory

          "IMO in this case the bug lies squarely with Chrome: if you go out of private mode, you erase ALL of the stuff you did until then."

          Chrome probably did. If the OS (driver land) lies to you about having wiped and discarded frame buffers, there's not much an app can do. Drivers should never give a buffer to a new app without wiping it first. Apps should not have to write code to work around the possibility of the OS not doing its job. I put the blame entirely on the GPU driver.

      3. Voland's right hand Silver badge

        Now I'm kinda wondering if there ever was a video driver from any manufacturer who went to the trouble of actually cleaning memory

        This is more of a bug in Diablo - not initializing memory correctly before enabling display.

        1. Charles 9

          Why is it a bug in Diablo? They initialize the memory with their first frame of rendering. What happened to the framebuffer before them is, frankly, none of their business. It should fall on Google to ensure that when a Incognito page is closed, it's blanked BEFORE it's released. In security terms, this is a memory leak on THEIR part.

        2. Anonymous Coward
          Anonymous Coward

          Of all the parties involved I'd say Diablo is least to blame. Chrome is the one offering privacy and not deleting records.

          1. TheVogon

            "I'd say Diablo is least to blame"

            It's still crap programming to display the frame buffer before initialising the desired content.

            1. Dr. Mouse

              There is blame on all sides here, I think.

              Chrome holds the majority of the blame: They are specifically stating that incognito mode keeps your session private. It should wipe anything which could be used to discover information about the session as soon as it is no longer needed. This would include the frame buffer.

              Diablo holds some blame, as it should not be displaying the frame buffer until it has initialised it. It is not their fault that the data was leaked, but it is their fault that it was visible through their application.

              NVidia should (although they may, I don't know) offer easy-to-use privacy hooks and APIs to ensure data is not leaked, triggering a zeroing of the frame buffer on release.

              The OS (and applications) should use those hooks and APIs to ensure data is not leaked (e.g. on logoff or user switching).

              1. BinkyTheMagicPaperclip Silver badge

                ..and if the application playing the pr0n dies with no exception handler, what happens then?

                This is the OS and driver's responsibility. Whether it can do it given the current architecture is an interesting question.

        3. Olius

          "This is more of a bug in Diablo - not initializing memory correctly before enabling display."

          It isn't. On any multi-user, multi-tasking system, the OS* should always zero or otherwise scramble memory before allocating to another app. This is otherwise a well-trodden attack vector. The OS should not trust the apps running on it, and apps should not trust each other. On a well designed OS, the apps should not even be aware that other apps are running and each app should be able to consider its own memory space private and secure. We're not quite there yet, but it's a good aspiration ;-)

          (* By OS, I actually mean "OS downwards", depending on what is appropriate - the OS itself, or the video driver, or the specific card driver, or the card itself)

          "Zeroing a large framebuffer could take some time"

          A video card is designed so that the framebuffer can be filled with data quickly enough to satisfy a decent framerate - hopefully well in excess of 25 frames per second. So zeroing the framebuffer should take a lot less than 1/25th of a second, which is a tiny price to pay on app startup.

          1. Charles 9

            "On a well designed OS, the apps should not even be aware that other apps are running and each app should be able to consider its own memory space private and secure. We're not quite there yet, but it's a good aspiration ;-)"

            Can't. There are times when an app NEEDS to know another app or module is running. Example, what good is a web browser without an Internet connection, which means knowing the socket driver is available, which may or may not be in Userland (depends on the OS, but microkernels by design would put everything non-essential into Userland). And there are such things as "ethical" process snoopers like anti-malware and anti-cheat programs.

            1. Olius

              "There are times when an app NEEDS to know another app or module is running. Example, what good is a web browser without an Internet connection [...snip...]"

              Indeed, but this is handled in an OS by IPC, not by asking the OS to hand you blocks of another process's private memory space to sniff. Let's not get off-topic here ;-)

              When designing an OS, one starts by creating an environment whereby each process thinks it is a single task running exclusively on the hardware, and then solve the issue you speak of by providing communication APIs. If you do it in reverse, you end up with very weak sandboxing and highly dangerous inter-process privacy issues. This is why memory allocation by the OS - whether main memory or graphics memory - is meant to provide "clean" blocks. Imagine if it didn't, and you could trigger the OS to allocate to you a memory block which contains SSH private keys used by another process?

              1. Bronek Kozicki

                If you do it in reverse, you end up with very weak sandboxing and highly dangerous inter-process privacy issues

                ... nah, you end up with DOS, no wait with Windows 3.11 for Workgroups, no wait with Windows Me (and I really want to stop here, but should I ?)

            2. Simon Harris

              "Example, what good is a web browser without an Internet connection"

              Most browsers are just as good at rendering locally sourced content as they are content from the web, so still useful in some circumstances. If the OS is well designed, wouldn't the browser just pass it the URL and the OS sort out where to get it from, and whether it could?

              Probably mobile apps need to be more aware of other stuff going on as they will need to hibernate gracefully when, for example, a call comes in.

              1. Olius

                "Probably mobile apps need to be more aware of other stuff going on as they will need to hibernate gracefully when, for example, a call comes in."

                Yep - but they don't do this by being aware of or monitoring or sharing memory of other processes running on the device. They do it by registering a signal handler which is called by the OS when a call comes in.

    4. Rol

      "So basically the guy has admitted to everyone he watches pr0n, I wonder if his bosses requested his browsing history at work be checked?"

      Says MeDixStiff...Mmm...I'm guessing you're having a laugh?

    5. fajensen

      I wonder if his bosses requested his browsing history at work be checked?

      It's good to know that bosses have the priorities of the organisation right (and no-one has anything better to do) - especially if one wants to short the stock.

    6. Anonymous Coward
      Anonymous Coward

      Yeah.. Like when you get a kid, everyone realises that you have had sex, and perhaps it's best that the boss checks that you don't have sex at work.

    7. PassiveSmoking

      Do you need bottled oxygen atop that high horse you're riding around on? The air must be awfully thin up there.

    8. Anonymous Coward
      Anonymous Coward

      Watching porn

      >So basically the guy has admitted to everyone he watches pr0n

      Why is this somehow shameful?

      1. werdsmith Silver badge

        Re: Watching porn

        ">So basically the guy has admitted to everyone he watches pr0n

        Why is this somehow shameful?"

        It's not. I've no idea why he felt he needed to use the incognito mode.

        What is very shameful, however, is that he has admitted to everyone that he uses Chrome.

    9. John Bailey

      Yep.

      Yet somehow, you come of as a bigger wanker.

  2. Anonymous Coward
    Anonymous Coward

    I imagine NVIDIA are in the clear

    and the consuming applications should clear up after themselves and/or initialise their allocated buffers.

    I cant see any reason why the NVIDIA drivers should go round randomly clearing frame buffers just in case.

    I would propose this issue is not limited to google solutions, indeed the video framebuffer may well be from another player applicaion. Chrome can't go round flushing buffers of other services either.

    Risk, yes,

    fixable by one vendor, no

    ...

    1. anonymous boring coward Silver badge

      Re: I imagine NVIDIA are in the clear

      Ultimately it should be the operating system's responsibility, just like making sure RAM content doesn't leak across independent processes.

      In the meantime, it's the responsibility of the application that offers security, i.e. Chrome in this case.

      1. Dan 55 Silver badge

        Re: I imagine NVIDIA are in the clear

        What would malloc do?

        I've assumed it's uninitialised on all platforms which could mean you get some passwords or certificates if a password manager didn't zero the memory before freeing it.

        This is the same thing isn't it?

        1. Jon 37

          Re: I imagine NVIDIA are in the clear

          No, on any sane OS the memory is cleared (typically zeroed) between one app releasing it and another app allocating it.

          However, malloc() is not an OS function, it's a C library function, and it will reuse free()'d blocks of memory from the same application without clearing them, and only get more memory from the OS if there are no free()'d blocks available. So if you are using malloc() you have to assume that the block is uninitialized.

          There's a big difference between "app X can see data from the same app" and "app X can see data from other apps, that may be run by other users or contain more sensitive information". In the "same app" case we need the performance boost from not zeroing the memory, in the "different app" case we need the security benefits of zeroing.

          The OS & drivers SHOULD have applied the same principles to graphics memory, but they obviously didn't. This is clearly an OS or drivers bug.

        2. Phil O'Sophical Silver badge

          Re: I imagine NVIDIA are in the clear

          What would malloc do?

          malloc() is a library function that returns memory whose contents are explicitly undefined.

          If you want zero-filled memory, use calloc().

          Neither will cleanup memory after release.

    2. Ken Hagan Gold badge

      Re: I imagine NVIDIA are in the clear

      "I cant see any reason why the NVIDIA drivers should go round randomly clearing frame buffers just in case."

      Because if they don't, someone can write a low privilege application that just goes around allocating frame buffers and saving the "uninitialised" contents as a bitmap and posting the bitmaps off to the NSA. For the OS (or driver) not to wipe memory before passing it to a new process is a COLLOSAL security failure that has been LAUGHABLE since the 1960s.

      All modern operating systems handle this problem for RAM by maintaining lists of dirty pages and having a "zero fill" task that wipes them clean before transferring them to the free list. It happens whenever there is free time (waiting for I/O perhaps) or, as a last resort, at the point of allocation. Since the last resort is hardly ever reached, the cost to the interactive end-user is effectively zero.

      A GPU driver could use a similar scheme and (as already mentioned) certainly has the bandwidth to make it affordable.

      1. Charles 9

        Re: I imagine NVIDIA are in the clear

        "A GPU driver could use a similar scheme and (as already mentioned) certainly has the bandwidth to make it affordable."

        But not the TIME. GPUs are normally built for high performance, so there are frequently zero-time context switches (a freed buffer has to immediately go to another application, with no chance to wait because, like I said, performance is demanded). Now you're in a security-vs-speed dilemma, and people why buy performance GPUs will demand the latter.

  3. Valeyard

    been like this for years

    If i restart my opensuse PC the first screen has grub loading etc, the 2nd monitor has recent buffer images. if someone's in the same room I just don't reboot but i reported it years back, could be bad on a shared family PC..

    1. Charles 9

      Re: been like this for years

      This has been a known exploit since the earliest days of personal computing. It was quite common to quickly reboot a machine and discover troves of information left by the last program running (I used to do this quite a bit in the latter days of using my Commodore 128). I recall very few programs have the know-how to interrupt the warm boot sequence to erase their code to block this (I think Lenslok-protected games actually cared).

  4. allthecoolshortnamesweretaken

    My gripe with this is the private mode of Chrome not being private. It's not just used for viewing porn, you now.

    1. Anonymous Coward
      Anonymous Coward

      I did not know that.

      1. Anonymous Coward
        Anonymous Coward

        Yeah, it's also for buying anniversary presents without your other half seeing what you bought them in the browser history.

        1. Simon Harris

          That's why your other half tells you they're in incognito mode anyway!

          1. Anonymous Coward
            Anonymous Coward

            Just remember not to buy using the same computer you use for facebook or it will start advertising the present to your other half.

        2. sisk

          Yeah, it's also for buying anniversary presents without your other half seeing what you bought them in the browser history.

          No worries here. My other half doesn't know what browser history is....and besides, we have separate computers. For.....you know.....reasons.

          (No, not porn. It's because when we briefly shared a computer - long, long ago - we were constantly fighting over it. Plus I prefer Linux and she prefers Windows so the thing ended up getting rebooted every time one of us sat down. It was easier just to get separate computers.)

          1. Anonymous Coward
            Anonymous Coward

            @sisk

            "Plus I prefer Linux and she prefers Windows"

            Irreconcilable differences if I ever heard them.

  5. Anonymous Coward
    Anonymous Coward

    I predict we'll see more of this sort of thing

    as the old paradigm of disk and volatile memory is blurred with SSDs and more and more NVRAM. In fact I would go as far as to suspect that the current crop of "coders" (i.e people who use DreamWeaver for 5 minutes and call themselves "web programmers") haven't the faintest clue about the differences.

    The future looks interesting ....

  6. Anonymous Coward
    Anonymous Coward

    just use your phablet to watch fleshy shows...

    1. Lamont Cranston
      Joke

      [something something] holding it wrong [something something]

      Needs to be a jab at Apple, somewhere, surely?

    2. Anonymous Coward
      Anonymous Coward

      IOS had a shaming bug, where a private browsing tab's content showed up somehow. I think it was in the tabs-zoom-out thumbnails, which showed no-longer existing tabs. Or so I have heard from an third party.

  7. Anonymous Coward
    Anonymous Coward

    It's definitely diablos bug. They are displaying random video memory to the user. The fact that it managed to get some image bytes from a private chrome tab is kinda irrelevant. They could display literally anything because they are incorrectly initializing their rendering process.

    If you wrote a program to scan every accessible byte of RAM i would expect you'd find all the strings associated with your smut pages too. You'd also find strings associated with every other application you ran in the recent past (assuming nothing overwrote that memory).

    Most modern operating systems do not guarantee memory is zeroed before the OS hands it to you. That's why you have calloc and malloc. It's a pointless performance penalty in the vast majority of cases.

    1. Dan 55 Silver badge

      Actually, reading up it this, it seems they do if the memory previously belonged to a different process. If it previously belonged to the same process, they don't.

      So if this is to be done the same way then nVidia should zero all video memory which belonged to a process when it exits.

    2. GrumpenKraut

      > Most modern operating systems do not guarantee memory is zeroed before the OS hands it to you.

      The O/S certainly should clear memory that has been owned by a different process. Otherwise, as has been said above, there are at least privacy issues. It absolutely has to clear memory previously owned by a process with a different UID.

      IIRC there was one such (leaking other's memory) bug with memory mapped via mmap().

      For a program leaving contents in the framebuffer is IMO bad style as well.

      1. Charles 9

        "The O/S certainly should clear memory that has been owned by a different process. Otherwise, as has been said above, there are at least privacy issues. It absolutely has to clear memory previously owned by a process with a different UID."

        But what if the program in question is a recovery tool that NEEDS to see that memory? One size can't fit all here, and the principle of DTA dictates that ultimate responsibility falls to the program that made the data (the origin point, if you will, the point of first responsibility). If you don't trust another program to see their data, it should be wiped before you release it. And before you say the OS should do this (maybe not wipe on the alloc but on the free instead), remember that bulk memory operations mean an unavoidable performance hit, and if the OS is designed for high performance, such a hit may not be desired.

        1. GrumpenKraut

          > But what if the program in question is a recovery tool that NEEDS to see that memory?

          If any program (let's restrict that to non-root UID) can see another's memory then privacy and security is gone.

          It's a design decision. Except possibly for systems where the is essentially no user, and only for VERY compelling reason I'd accept leaked memory contents.

          By he way, if a program unexpectedly terminates (say, by SIGKILL) it cannot by any means do any cleanup.

          1. Charles 9

            "If any program (let's restrict that to non-root UID) can see another's memory then privacy and security is gone."

            Then we're essentially doomed. Anti-malware, anti-cheat, basically any defensive program worth its salt MUST be able to see into other processes to make sure they're not malicious, and if THEY have to do this to be able to function, any other program can pretend to be this, too. We've gone into a Quis custodiet ipsos custodes? situation, and there's no easy answers to that.

            1. GrumpenKraut

              The kernel can always peek 8^)

              One can also check an executable before it becomes a process (pretty sure scanners do this) and by watching the _actions_ of a process: You want to open SMTP? Sorry Dave! (again, pretty sure those "protection" programs are doing this). Whatever else they do to completely drain your resources, I don't know.

              In other news a certain system where security was an afterthought has been found "fucking hopeless anyway".

              1. Charles 9

                "One can also check an executable before it becomes a process (pretty sure scanners do this) and by watching the _actions_ of a process: You want to open SMTP?"

                But what if the malware waits until it becomes a process AND disguises its malware act as a legitimate act (Yes, I have to open SMTP--I'm an e-mail client!)? Then you need more sophisticated sniffing that can also work outside an encryption envelope, meaning it has to be able to see the process while running.

      2. Saigua

        See OpenCL, any other buffer mechanism at hand

        Openfb had this problem only 12 and 15 years ago, so it's understandable that OpenCL, which doesn't allocate specific memory (only something free on the scoreboard) and which can have quite a long callback in being asked to clear the buffer used would have a hitch or so coughing up a callback for a clear displaylist. Or, your OS might use Persistent Mapped Buffers (OpenGL) and not be compiled to worry horribly about data load determinacy (v. callbacks w. new pointer optional) and reusing them. Quite normal if you're not running signboards in a government building! (Flying dockets! Tripletake defense-state!)

        Either you want a fuzzer or active padding daemon competing (maybe with some determinism) with your power scheme to prevent leaks on displays of the same machine...reproduce it with lvm and you've earned an educational use case to ponder...or you really want to save power and noise.

  8. goldcd

    Same can be see with other software

    If I play Rocket League, the last photo I've viewed flashes up on the screen immediately before the Rocket League splash screen. Can't swear to it, but think I'm using the Picassa photo viewer.

    Very strange the first time it happened. Only comes up for less than a second and thought I was seeing things.

  9. skswales

    Persistence

    Twas even better in ye olden days of SRAM framebuffers. Turned off Ohio Sci. Superboard one day in middle of working (playing Tiger Tank ISTR) to go out. Many hours later, turned on again - 99% kosher display of what I'd been working on. Don't make 'em like that any more...

  10. Anonymous Coward
    Anonymous Coward

    To be fair, even my dumb TV does this

    switch on and the last HD frame comes up briefly as the channel is recaptured.

    Never mind the device producing the image.

    ...

    1. Simon Harris

      Re: To be fair, even my dumb TV does this

      at least it's not permanently burnt into the phosphor!

  11. Mario Becroft
    FAIL

    I've been waiting for someone to notice this vulnerability

    This bug is common in graphics drivers... not familiar enough with the inner workings of OpenGL to know but I'd assume the driver could zero framebuffer and texture memory when deallocated/no longer used. Maybe this is hard or non-performant.

    Either way it needs fixing as this represents a serious security hole for things like web browsers' "incognito" mode or in fact anyone working on sensitive information displayed by GPU. Which, with many recent window system implementations using texture memory for window pixmap store, could mean every application you use.

    Sure, main memory suffers the same issue, but secure operating systems already zero memory on allocation, and highly sensitive applications will mlock memory and zero it when finished with cryptographic keys etc.

    1. Charles 9

      Re: I've been waiting for someone to notice this vulnerability

      "This bug is common in graphics drivers... not familiar enough with the inner workings of OpenGL to know but I'd assume the driver could zero framebuffer and texture memory when deallocated/no longer used. Maybe this is hard or non-performant."

      The problem is that memory wipes take time, and GPUs are typically built for high performance, meaning it's a trade-off. Speed frequently clashes with security, unfortunately. And in a paranoid system, one should assume their mess won't be cleaned up for them.

      PS. Why should the memory be wiped on the alloc? Shouldn't it be wiped on the free instead?

      1. GrumpenKraut

        Re: I've been waiting for someone to notice this vulnerability

        > Shouldn't it be wiped on the free instead?

        It could be alloced again by the same process. No need to zero it then. And that is the _only_ reasonable situation to skip zeroing for the O/S. And it's a common situation.

        1. Charles 9

          Re: I've been waiting for someone to notice this vulnerability

          Then it should be an option on the free() call, unless it's a free called by the program's termination (in which case it can an automatic wipe; performance becomes less of an issue in the graceful termination phase). That way, the program can judge if the memory needs to be wiped (for example, because sensitive memory is involved--they'll want to clean it regardless and doing it this way minimizes the chances of a read by elevated code). As for abnormal termination (essentially "nuking" an app), then perhaps only then should the OS intervene and wipe the program's memory space as it's performing an intervention. Any other method should leave it the program's responsibility.

  12. Blitterbug
    Happy

    The nVidia Tug Bug

    Can I be the first to name it? Oh, go on...

  13. Zot

    A couple of lines of C will fix this

    Clear back buffer and swap buffers, then clear back buffer and swap buffers. This game should have done that anyway, as it could have been any old crap in the video RAM. It's not down to Nvidia, at the very least, it's Chrome's issue with privacy.

    1. Charles 9

      Re: A couple of lines of C will fix this

      Unless the program is performance-sensitive and needs to hand off quickly. That's the thing with GPUs; they're built for high performance, and things like memory wipes are time-consuming. How do you reconcile the two?

  14. Primus Secundus Tertius

    Used to happen with disks

    I remember demonstrating to a government research place in the 1980s that on their VAX computer one could grab a few megabytes of disk space and dump out the contents. A lucky dip, really. I could see it was interesting stuff; but the government people were appalled.

    It still is a problem with disks, of course. All the arguments above about whose fault it is apply equally. But little has been done. Yes, there is SATA secure erase if you really want to clean up a disk. But countless second hand machines are full of titbits, in every sense of the word.

    Equally, it seems nothing will be done about graphics memory.

  15. Alistair
    Windows

    both nvidia and radeon drivers have this issue.

    Linux laptop -

    Currently on nvidia drivers, but if I were to stop and restart xdm, when I log in again, I can see in the map space between my two screens (one is 1600x900 the other 1920x1080) - the bottom edge of the larger screen has tiles and textures from the previous state of the X display. This is far from new. The GPU memory has never been cleared on either set of drivers. And I'm not going to comment on the issues with the Intel drivers - even on single screen display setup they leak textures and image data from *the current* session....

    I'm not sure why *anyone* has ever had the idea that data on the GPU memory was cleared out before reuse. I recall from a *very* long time ago that the routine to wipe the page allocation table was the only thing done on a recycle in the rageII drivers to clean out memory on the card, it was considered sufficient since the memory would be reused *and reloaded* with data before re-reading it. I somehow doubt that that basic concept has been changed anywhere.

    <shudder. 30 years. I've been doing this crap for 30 years.>

  16. Hans Neeson-Bumpsadese Silver badge

    Well done

    I think he should be congratulated for uncovering this issue single-handled

    1. Crisp

      Re: Well done

      He pulled it off quite nicely.

  17. Gannettt

    But I thought incognito mode/private browsing was so you could order your wife presents online without her knowing about it?

    See this article from August 2008!

  18. Gordon Pryra

    Lotgs of hot air in this thread

    Who here actually believes that any of these incognito type settings from ANY of the browsers actually hides anything from anyone apart from the wife?

    Goolge even give themselves a get out clause when you start Chrome up

    "Going incognito doesn’t hide your browsing from your employer"

    They promise nothing

    1. Charles 9

      Re: Lotgs of hot air in this thread

      "Going incognito doesn’t hide your browsing from your employer"

      That copout is due to hypervisor capabilities in enterprise settings. Basically, Incognito can do squat against an agent that can snoop at all programs actively running. Basically, that scenario is like getting caught with a salacious book wide open. You can't do much against that kind of eye.

      Nevertheless, Chrome should be obligated to perform due diligence when handling incognito windows. It should, as standard security procedure, retain the information for no more than is absolutely necessary to function, meaning any information it no longer needs should be immediately wiped clean to minimize administrative/hypervisor/root-class malware spying.

  19. EPurpl3

    Buy ATI if you want to fap, lol

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like