Date: Fri May 12 19:57:52 2006
From: sebastian.rother at jpberlin.de (sebastian.rother@...erlin.de)
Subject: How secure is software X?

Well the same question cam eup also in OpenBSD-mailinglists.
And I angree with Theo de Raadt because he`s completly right.
So I`ll simply paste his mail:

---
> http://marc.theaimsgroup.com/?l=openbsd-misc&m=114657401630096&w=2
>
> If I understand correctly from what I've been told, this is not a
> hardware
> issue but an 'X' issue.

It is the job of the operating system to shield the hardware from
userland processes.  That's what every operating system does.  Some do
a better job of this than others.  But when an operating system fails
to do this shielding, it is almost always a bug in the operating
system.

However, in this case, we cannot solve this in the operating system.

The X developers have created an X server which *REQUIRES* access the
raw hardware.

Therefore all the operating systems developers have given the X server
such access, by creating a "hole" in their operating system, which
permits the X server to access any chip-level registers it wants.

This is called the "device drivers in userland" model.  It violates
all the security models you will hear of in a university class.

Having done so, they place operating system designers in the situation
of choosing between the two options: "Our users cannot run X" or
"there must be a hole in our operating system".  Guess which choice
every vendor makes?

We provide a sysctl to let the user decide -- that is what the
aperture sysctl is for.  And we admit that is a cop-out.  That's
because there is no operating system level solution to the problem.
At least we did not cop out as far as other vendors, who let any root
process play with the any registers.  We only let one root process
play with the registers at a time.  This is not a strong solution, but
it the best we can do.

But let me be clear -- the X developers are a bunch of shameless
vendor-loving lapdogs who sure are taking their time at solving this >
10 year old problem!  They spend way more time chasing the latest
vendor binary loaded device driver, than they do solving this obvious
problem.  (Translation: They don't want to change how X works, because
it would break the vendor binary drivers from ATI and NVIDIA.  That is
part of what happens when X developers get jobs at vendors).

What Loic found is just one example of perhaps 50 other serious &
equivelant security problems.  Or maybe more.  Most modern video
chipsets can DMA all over the address space if requested.  Many have
processors that code could be loaded into, even surviving reboots.
If there is a one bug in the X server, your machine is compromised.

How does this get solved?

If the X server did not require direct hardware access these problem
would go away immediately.

This requires that a proper abstraction be designed, so that a kernel
device driver did the nasty register bits, and then communicated via a
sanitized channel to the X server.  This is the obvious seperation model
that all other Unix things use.  Unix processes use read() and write()
to modify files.  You don't see them talking directly to SATA chipsets
do you?

If they show up and provide a simple specification for such an
abstration layer between a "kernel video driver" and a "X video
driver", and helped us a little bit with the registers, the problem
would go away almost immediately.  That requires them to do some
clever design, but it is clear they know more about past, current, and
future video chipsets.  They know the hardware, and we do not.  They
can solve this for all X-running operating systems today, or they can
cop out and not solve it ever.

They've had 10 years, and yet every year they get more entrenched in
the entirely insecure model of "gigantic process running as root,
which accesses registers like mad".

This problem is ENTIRELY the X group's fault!  They have failed us.
Ten years ago they were laughing at Microsoft for moving their video
subsystem into their kernel, but now the joke is on the X developers,
because what Microsoft did solved all these driver security problems!

This is 100% an X server bug.  It is not a hardware bug, and it is not
an operating system bug.

[Feel free to forward this anywhere; I feel that Loic's original
announcement totally missed at assigning the blame where it lies, and
the result is that it is not being fixed.]
---

The X-Developers do realy a poor job...


Kind regards,
Sebastian

Powered by blists - more mailing lists