Security issues

[Carsten Haitzler (The Rasterman)]

On Fri, 21 Apr 2006 09:37:22 +0200 Duflot Loic <loic.duflot at sgdn.pm.gouv.fr>
babbled:

> Hi all,
> 
> We recently crafted a proof-of-concept attack scheme on OpenBSD-based
> systems that shows that with the privileges the X server is granted, it
> is pretty easy (less than 10 lines of code indeed) to get to kernel
> privileges. This schemes shows how an attacker with PIO privileges and
> write access on the legacy video RAM range can get to kernel (ring 0
> random code execution) privileges. Details can be found here:

sure - but how can a USERSPACE (non-root) process that has connected to x gain
such privs? sure- it's accepted. x runs as root - game over. nothing new. how
can an X client running as a non-root user gain root (or above) privs?
seriously - i actually would like to know (beyond exploiting a buffer
overflow/bug in x as such). at a glance this only shows that the xserver itself
can gain kernel privs - but that's no stretch of the mind at all to know that.
the important bit - how does an x client get such privs?

> http://www.ssi.gouv.fr/fr/sciences/fichiers/lti/cansecwest2006-duflot-paper.pdf
> http://www.cansecwest.com/slides06/csw06-duflot.ppt
> http://www.ssi.gouv.fr/fr/sciences/fichiers/lti/sstic2006-duflot-papier.pdf
> 
> So, basically, even though the X server appears to be running with ring
> 3 privileges, it can be considered to run with "kernel-like" privileges.
> What our scheme proves is that the X server cannot run in userland
> without it endangering the global security of the system.
> This particular exploit may not be the only one of its kind. In the
> course of the proof-of-concept exploit the attacker uses some
> northbridge functionality to increase his privileges over the system,
> but we recently found out that other PIO-configurable mechanisms could
> be used for the same purpose! We would not be surprised if much more
> hardware mechanisms proved to be usable for similar purposes in the future.
> We find it is time to tackle the root of the problem. We cannot achieve
> true security unless security critical operations (Programmed I/O
> accesses for instance) are moved to kernel space.
> 
> We think the best thing to do now would be to move to a saner security
> model. The X server could be for instance split in two different parts.
> One of them (the one requiring PIO accesses or important privileges on
> the hardware) could run in kernel mode, providing some abstraction to
> the other one (the biggest one hopefully) remaining in userspace. The
> part remaining in userspace would thus no longer require any particular
> privilege.
> 
> Please be aware that this is not an OpenBSD-specific matter. Other
> systems have no protection at all against the attack scheme we display.
> 
> We think it is a very urgent matter for true security will never be
> achieved otherwise. For the time being the only advice we could give to
> OpenBSD users who want their system to be secure is not to use the X
> server. Everybody should work together on this to improve the global
> security of IT systems.
> 
> Loïc
> 
> ------------------------
> Loïc Duflot
> SGDN/DCSSI/SDS
> http://www.ssi.gouv.fr/
> 
> 
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com
裸好多
Tokyo, Japan (東京 日本)