In article <20061109005604.GB5579@nexus.subspacefield.org>,
Travis H. <travis@nexus.subspacefield.org> wrote:
>Just wanted to see if you've seen this
>(sorry, also posted to port-i386, should have prolly been here):
>
>http://www.ssi.gouv.fr/fr/sciences/fichiers/lti/cansecwest2006-duflot-paper.pdf
This is what I replied to Loic a long while ago:
On Mar 7, 2:53pm, loic.duflot@sgdn.pm.gouv.fr (Loic Duflot) wrote:
-- Subject: SMM based privilege escalation
Dear Loic,
Your exploit is using /dev/xf86 (aka the aperture driver). This
driver is not distributed by the base NetBSD operating system. It
only exists in pkgsrc. It is well known that one can get unlimited
access through this driver (although the problem is somewhat
mitigated by having only a single process able to open this at a
time, but even this is easily defeated). You don't even need SMM
to achieve this; you can do it by programming DMA in the graphics
card or make the paint engine on the graphics card write any value
you want anywhere in memory. With securelevel > 0 you cannot access
/dev/mem for that particular reason. The aperture driver is just
a band-aid and a bad one, because it makes you think you are secure,
where in reality you are not.
I will add a note to the aperture driver DESCR file mentioning this.
Thank you,
christos
And here is the MESSAGE file from the aperture driver:
**************************
**** SECURITY WARNING ****
**************************
Please note that use of this driver only raises the bar somewhat
on breaking the securelevel abstraction. Loading this driver provides
the opening process with access to various things that can write
anywhere in memory (such as DMA engines, frame-buffer paint engines,
SMM). While one has to write a little more code to aim these memory
writers at the securelevel variable in kernel memory, it is not really
difficult to do so. Finally the fact that only one process can have
/dev/xf86 open at a time does not win much since root can kill it
at anytime and start another process. This exploit has to do with
root being able to change the security level and do things it could
not do before.
Unfortunately he does not mention any of this in his paper. The
bottom line is that if you run X in its current implementation that
requires access /dev/mem, you can easily bypass the securelevel
restriction, regardless if you are using the aperture driver or
not. This is why at NetBSD we decided not to include the aperture
driver in the base system. We've known about this for years, and
as a matter of fact somebody tried to write/wrote code that would
program the DMA engine to overwrite the securelevel variable
directly.
christos