Lecture: X Security - It's worse than it looks

Having seen this presentation at 30C3 a/o 2014/12/29 I made my mind not touching xorg anymore until the situation has gotten better. This was expected to be midyear 2014. Although I could not find any information about the state of cleaning up the xorg server mess.
Ilja van Sprundel, the security researcher who reported the pile of
client side security bugs that led to our big advisory in May, has
given another talk on X security, this time at last week's
30th Chaos Communication Congress (30C3) in Hamburg, Germany.

The video has been posted to
http://media.ccc.de/browse/congress/201 ... undel.html

The first half covers those client-side issues, as well as those higher
in the stack in the toolkits. The second half talks about what he's
been looking at on the server side since then. (Key quotes: "GLX is
a horrible demotivator! 80,000 lines of sheer terror." and "In the past
couple of months I've found 120 bugs there, and I'm not close to done." )

I think it's mostly accurate (there's a couple minor details to quibble
with, and there's a bit about 10-15 minutes in everyone can fast forward
through). His point about today's world being much different than when
X was created, and nearly 30 year old hand written binary protocol parsing
code not being the best idea, is much like the rationale for xcb's creation,
but we've not been effective at getting transitioned to it. (We keep
talking about using XCB to generate server-side protocol handling & byte
swapping, but never have, and haven't made it possible for all the clients
to move to XCB, since there's still a couple missing pieces.)
-Alan Coopersmith-
Oracle Solaris Engineering
Tue Dec 31 10:11:29 PST 2013

Does someone have more information about that?
 
X has traditionally been a security nightmare. I don't think this has improved much in the past 15 years I've used it.
 
Here is an update on the Xorg security mess cleanup, done by Ilja van Sprundel, a security researcher with IOActive.
Most of the issues are related to memory management, but Ilja also has some critics to QT- and GTK-developers. The oldest bug he found was from 1987 (!).

For more see http://www.x.org/wiki/Development/Security/Advisory-2014-12-09/

Mitigation

While the fixes cover all the cases currently known to X.Org, these are not the first issues in this area and are unlikely to be the last.

Users can reduce their exposure to issues similar to the ones in this advisory via these methods:

Configure the X server to prohibit X connections from the network by passing the -nolisten tcp command line option to the X server. Many OS distributions already set this option by default, and it will be set by default in the upstream X.Org release starting with Xorg 1.17.

Disable GLX indirect contexts. Some implementations have a configuration option for this. In Xorg 1.16 or newer, this can be achieved by setting the -iglx X server command line option. This option will be the default in Xorg 1.17 and later releases.

Consult your operating system's documentation for details on setting X server command line options, as X servers are started by a variety of different methods on different platforms (startx, gdm, kdm, xdm, etc.).
 
I for one am looking forward to the 31C3, maybe there is a follow up session on this. That could be interesting.
 
The problem is that X interacts with so many things, including the kernel. The FreeBSD X11 team has added members and the rate of change has increased a lot over the last year. For security or other questions, best to ask directly on the freebsd-x11 mailing list.
 
KMS drivers require kernel support. On FreeBSD, this is difficult because we have three different supported operating system branches with differing levels of kernel support for KMS, but only one ports tree that has to work with all of them. Some older drivers no longer work with newer X11 servers. So it's complicated...
 
Back
Top