It's just to point out something you might already know, but you may just not as the forum GLSA last report is date 07/10 and this one is from 08/01 and couldn't find a glsa matching that one (lol a proof i search not one it doesn't exist) I have no info about what version is affected... Reproducible: Always
Thank you for the report, Stéphane. A CVE has been requested: http://seclists.org/oss-sec/2012/q3/157
I should note that like the last vulnerability with the device nodes, Gentoo is slightly more protected than the average since we use 0660 root:video instead of 0666 like the default install that other distros use. However, we still want to get this fixed ASAP.
Upstream's response [1] on Full Disclosure ML: Thank you for reporting this vulnerability. NVIDIA has released an updated driver, version 304.32, which contains a hotfix to block access to the registers involved in this attack, as well as some other registers which we have identified as being susceptible to a similar type of attack. In addition to the updated driver, NVIDIA has released patches for older driver versions. Details about the updated driver and the patches are available at: http://nvidia.custhelp.com/app/answers/detail/a_id/3140 [1] http://seclists.org/fulldisclosure/2012/Aug/76
304.32 runs well: Just copied the ebuild with that version as name and ebuild ... manifest.
(In reply to comment #4) > 304.32 runs well: > Just copied the ebuild with that version as name and ebuild ... manifest. I'm inclined to just fix the 295.59 ebuild with the patch. The 304.x series has needed a little bit more stabilization IMHO. Does 304.32 fix the OpenGL colorkey issue or have you not tested OpenGL?
I've added 295.59-r1 which is stable 295.59 + the patch. I've also added 302.17-r1 which is 302.17 + the patch. I've decided to not add 304.32 since it has not passed NVidia's internal QA based on my understanding of their marking packages. stable target: nvidia-drivers-259.59-r1 target keywords: amd64 x86
- Shouldn't you add a note as the patch gave a lost of functionality for any drivers not => 304.32 "Note that the Linux CUDA debugger will not work with older drivers if the patch is applied, though the Linux CUDA debugger will work properly with 304.32." - I'm not the best at this but looking at the patch this only define some more blacklist to memory range, and v304.32 didn't get this patch but a proper fix instead, else the cuda debugger wouldn't work too with that version. looking at line 371 in src/nv.h from nvidia-173.14.35 you can see the same blacklist range is there as with 195 serie (unpatch). #define IS_BLACKLISTED_REG_OFFSET(nv, offset, length) \ ((IS_REG_RANGE_WITHIN_MAPPING(nv, 0x1000, 0x1000, offset, length)) ||\ (IS_REG_RANGE_WITHIN_MAPPING(nv, 0x700000, 0x100000, offset, length))) This should tell us the "lame" (my point of view) fix nvidia as given for 195 upto 304.31 should also "fix" any version prior to 195 And i see 173.14 and 93.43 (i didn't check the nv.h in it) ebuild in my portage tree, these versions are needed for olders cards and should be patch too as the "fix" is just blacklist memory range (still for my understanding), this in no way tell us the older cards aren't affect. As-is it looks to me like nvidia answered : "don't use older cards or get hack", and they discard their own responsability with a "which can be used to patch older drivers, if necessary." LOL @ "if necessary" Gentoo shouldn't do like nvidia and should : - Remove older ebuild with security issue, dropping support for older cards, and leaving users "fucked" (sorry my english is too weak to find a better word) - Or not applying the fix (if undoable), but telling users with older cards the bomb they have in their computer. Specially because that old cards generally are in old computers ending their life as server. - Or fixing those old serie too (which might not be doable, but would be the best thing to do)
Arches please stabilize.
*** Bug 430328 has been marked as a duplicate of this bug. ***
There are official drivers out now. =x11-drivers/nvidia-drivers-295.71 =x11-drivers/nvidia-drivers-304.32 See bug #430328. Shouldn't we get these in the tree and stable instead?
That's odd. Using the pub.c code attached to the full disclosure message as intended (run by a user in the video group), and using the 96, 173 *and* the (unpatched) 259.59 drivers on matching hardware, I invariably see this: Kernel 3.3.8-gentoo, =x11-drivers/nvidia-drivers-295.59, NV44A jeroen@marga /keeps/gentoo/bugs/429614 $ ./pub32 [*] IDT offset at 0xc0608000 [*] Abusing nVidia... jeroen@marga /keeps/gentoo/bugs/429614 $ echo $? 255 jeroen@marga /keeps/gentoo/bugs/429614 $ Kernel 3.2.21-gentoo, =x11-drivers/nvidia-drivers-96.43.20, NV25 jeroen@astrid ~ $ /keeps/gentoo/bugs/429614/pub32 [*] IDT offset at 0xc05a0000 [*] Abusing nVidia... jeroen@astrid ~ $ echo $? 255 Kernel 3.3.8-gentoo, =x11-drivers/nvidia-drivers-173.14.35, NV34 jeroen@wieneke /keeps/gentoo/bugs/429614 $ ./pub64 [*] IDT offset at 0xffffffff8190b000 [*] Abusing nVidia... jeroen@wieneke /keeps/gentoo/bugs/429614 $ echo $? 255 And that's it. No further messages as evidenced elsewhere on the Internet. And certainly not the "Have root, will travel.." or even the "Failed to get root."
(In reply to comment #10) > There are official drivers out now. > > =x11-drivers/nvidia-drivers-295.71 > =x11-drivers/nvidia-drivers-304.32 > > See bug #430328. > > Shouldn't we get these in the tree and stable instead? Yep. Except 304.32 is a disaster so we'll skip that. I'll get 295.71 added in the morning.
(In reply to comment #11) > That's odd. Using the pub.c code attached to the full disclosure message as > intended (run by a user in the video group), and using the 96, 173 *and* the > (unpatched) 259.59 drivers on matching hardware, I invariably see this: > > Kernel 3.3.8-gentoo, =x11-drivers/nvidia-drivers-295.59, NV44A > jeroen@marga /keeps/gentoo/bugs/429614 $ ./pub32 > [*] IDT offset at 0xc0608000 > [*] Abusing nVidia... > jeroen@marga /keeps/gentoo/bugs/429614 $ echo $? > 255 > jeroen@marga /keeps/gentoo/bugs/429614 $ > > Kernel 3.2.21-gentoo, =x11-drivers/nvidia-drivers-96.43.20, NV25 > jeroen@astrid ~ $ /keeps/gentoo/bugs/429614/pub32 > [*] IDT offset at 0xc05a0000 > [*] Abusing nVidia... > jeroen@astrid ~ $ echo $? > 255 > > Kernel 3.3.8-gentoo, =x11-drivers/nvidia-drivers-173.14.35, NV34 > jeroen@wieneke /keeps/gentoo/bugs/429614 $ ./pub64 > [*] IDT offset at 0xffffffff8190b000 > [*] Abusing nVidia... > jeroen@wieneke /keeps/gentoo/bugs/429614 $ echo $? > 255 > > And that's it. No further messages as evidenced elsewhere on the Internet. > And certainly not the "Have root, will travel.." or even the "Failed to get > root." The exploit code is bad for 32 bit boxes, which is probably why it didn't work there. As for 173.x and 96.x I haven't seen yet that they are affected.
nvidia-drivers-295.71 is in the tree as well.
amd64 has nothing to do here, feel free to do it
stable target: nvidia-drivers-295.59-r1 & nvidia-drivers-295.71 target keywords: amd64 x86
(In reply to comment #15) > amd64 has nothing to do here, feel free to do it A few of us together in #gentoo-dev just now managed to discuss the issue and AxS was able to test on a stable system but has no access to commit right now so I've done it. + 13 Aug 2012; Rick Farina <zerochaos@gentoo.org> + nvidia-drivers-295.59-r1.ebuild, nvidia-drivers-295.71.ebuild: + marking stable per testing by AxS Sorry if I did something wrong but it all looks close enough, marked stable for amd64.
x86 stable, last arch!
Thanks, everyone. GLSA already drafted and ready for review.
CVE-2012-4225 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2012-4225): NVIDIA UNIX graphics driver before 295.71 and before 304.32 allows local users to write to arbitrary physical memory locations and gain privileges by modifying the VGA window using /dev/nvidia0.
(In reply to comment #20) > CVE-2012-4225 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2012-4225): > NVIDIA UNIX graphics driver before 295.71 and before 304.32 allows local > users to write to arbitrary physical memory locations and gain privileges > by > modifying the VGA window using /dev/nvidia0. Its worded a bit ambiguous. That was only the 304 series before 304.32.
This issue was resolved and addressed in GLSA 201304-01 at http://security.gentoo.org/glsa/glsa-201304-01.xml by GLSA coordinator Sean Amoss (ackle).