Security issues

[Carsten Haitzler (The Rasterman)]

On Fri, 21 Apr 2006 10:47:19 +0200 Duflot Loic <loic.duflot at sgdn.pm.gouv.fr>
babbled:

> 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

why not? insmod kernelmodle.ko - don't. io just inserted code into the kernel.
root is allowed to do it. there's /dev/mem for more fun. the list goes on. :)

> 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,

well here is a quote from an x developer - slightly reworded (it's from memory)

"x is the only part of the kernel that's in userspace" :)

ie - it's ACCEPTED that x is a kernel-level "service" and anything inside the
xserver should be treated as such and coded VERY carefully so nothing can
exploit it from outside the xserver (ie an x client for example). as long as i
can remember this has been the general view of x as such. sure - i do see your
point, but i am not entirely sure it's something people haven't known for a
long time and already accepted as "that's how it works - so make it rock solid".

> Loïc
> ------------------------
> Loïc Duflot
> SGDN/DCSSI/SDS
> http://www.ssi.gouv.fr/
> 
> Carsten Haitzler (The Rasterman) a écrit :
> > 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 (東京 日本)