Security issues

Duflot Loic loic.duflot at
Fri Apr 21 01:47:19 PDT 2006

Hi Carsten,

I really don't see why it should be considered that once an attacker
gets to root privileges game is over! The securelevel on OpenBSD has
exactly been designed so that even in case of a compromission of the
root account, game is not over.
The trouble is that the proof of concept schemes shows that the
securelevel can be circumvented if their is a possibility for superuser
processes to access PIO ports. On OpenBSD, the only standard application
requiring PIO accesses is the X server. Should it not require that,
their would be no need for the iopl or ioperm call. And we would be safe
even in case of compromission of the root account.

My opinion is that the fact that the X server requires too many
privileges is basically one of the reasons why game is over once
somebody gets to root privileges. ;-)
I hope you'll understand my point,

Loïc Duflot

Carsten Haitzler (The Rasterman) a écrit :
> On Fri, 21 Apr 2006 09:37:22 +0200 Duflot Loic <loic.duflot at>
> 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?
>> 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
>> _______________________________________________
>> xorg mailing list
>> xorg at

More information about the xorg mailing list