oss-security - CVE request - kernel: drm/radeon: r6xx/r7xx possible security issue, system ram access

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <4B5813E8.3050309@redhat.com>
Date: Thu, 21 Jan 2010 16:44:24 +0800
From: Eugene Teo <eugene@...hat.com>
To: oss-security@...ts.openwall.com
CC: "Steven M. Christey" <coley@...us.mitre.org>
Subject: CVE request - kernel: drm/radeon: r6xx/r7xx possible security issue,
 system ram access

Quoting from the patch description:
"This patch workaround a possible security issue which can allow user to 
abuse drm on r6xx/r7xx hw to access any system ram memory. This patch 
doesn't break userspace, it detect "valid" old use of CB_COLOR[0-7]_FRAG 
& CB_COLOR[0-7]_TILE registers and overwritte the address these 
registers are pointing to with the one of the last color buffer. This 
workaround will work for old mesa & xf86-video-ati and any old user 
which did use similar register programming pattern as those (we expect 
that there is no others user of those ioctl except possibly a malicious 
one). This patch add a warning if it detects such usage, warning 
encourage people to update their mesa & xf86-video-ati. New userspace 
will submit proper relocation.

Fix for xf86-video-ati / mesa (this kernel patch is enough to prevent 
abuse, fix for userspace are to set proper cs stream and avoid kernel 
warning) : 
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=95d63e408cc88b6934bec84a0b1ef94dfe8bee7b
http://cgit.freedesktop.org/mesa/mesa/commit/?id=46dc6fd3ed5ef96cda53641a97bc68c3bc104a9f

Abusing this register to perform system ram memory is not easy, here is 
outline on how it could be achieve. First attacker must have access to 
the drm device and be able to submit command stream throught cs ioctl. 
Then attacker must build a proper command stream for r6xx/r7xx hw which 
will abuse the FRAG or TILE buffer to overwrite the GPU GART which is in 
VRAM. To achieve so attacker as to setup CB_COLOR[0-7]_FRAG or 
CB_COLOR[0-7]_TILE to point to the GPU GART, then it has to find a way 
to write predictable value into those buffer (with little cleverness i 
believe this can be done but this is an hard task). Once attacker have 
such program it can overwritte GPU GART to program GPU gart to point 
anywhere in system memory. It then can reusse same method as he used to 
reprogram GART to overwritte the system ram through the GART mapping. In 
the process the attacker has to be carefull to not overwrite any 
sensitive area of the GART table, like ring or IB gart entry as it will 
more then likely lead to GPU lockup. Bottom line is that i think it's 
very hard to use this flaw to get system ram access but in theory one 
can achieve so.

Side note: I am not aware of anyone ever using the GPU as an attack 
vector, nevertheless we take great care in the opensource driver to try 
to detect and forbid malicious use of GPU. I don't think the closed 
source driver are as cautious as we are."

The attack is theoretical. To exploit this you need access to the drm 
device file which is usually set to 666 to allow users to have 3D 
acceleration.

http://lkml.org/lkml/2010/1/18/106
https://bugzilla.redhat.com/show_bug.cgi?id=556692

Thanks, Eugene
-- 
Eugene Teo / Red Hat Security Response Team

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.