
Massive Number of Vulnerabilities Found in X.Org - chrisdotcode
http://lists.x.org/archives/xorg-devel/2013-May/036276.html
======
asveikau
The fact that one must watch out for integer overflow on a buffer size
calculation for malloc, realloc, etc. should be no surprise to a thoughtful C
programmer. It sounds like somebody just did an audit of an old code base
looking for bad patterns and this is what came out of it. It sounds like great
work on the part of the people doing audits/fixes but I'm not sure it's
freakout material ("massive" seems a bit sensationalist).

~~~
tptacek
The only reason this isn't worth a freakout is that nobody running Linux in a
graphical desktop configuration could ever have assumed that the machine was
multiuser-safe to begin with. The reality is probably that no Linux (or
FreeBSD) system in any configuration is secure from an attacker that can run
native code in an unprivileged process. But with X11 running, you never had a
chance.

I'm always amused by the dismissive tone programmers take to findings like
this --- "oh, any thoughtful C programmer could avoid these problems". No,
they can't. How many billions of dollars does it take to prove this point? The
very best secure programmers in the world, building C (and C++) codebases from
scratch specifically to address these problems, almost invariably fail to do
so: memory corruption bugs get found in these systems just like they do in
'90s-vintage X11 code.

C is my very favorite language and I'm not saying people shouldn't use it
(well... they should avoid it, actually), but people should work in it with
their eyes open.

~~~
thrownaway2424
At no time has there ever been a Linux kernel release with no local root
exploits. There have been periods of uncertainty when we didn't know the exact
exploit but we always find out eventually. Keep this in mind whenever you
think about Linux security.

~~~
thirsteh
This is true for virtually all software.

That said, Linux users do have an unwarranted confidence in the security of
the operating system. The kernel developers actually don't care that much
about security--but because it was designed with some level of sanity, most
installations are headless, and the non-headless installations aren't used by
very many people, it has been able to tout some apparently obvious superiority
to e.g. Windows (which isn't really the case post-Vista, when Microsoft had
enough of being a punching bag.) Same thing goes for Mac--a whole lot of
confidence, but not a lot to back it up. Curiously, a lot more Mac malware has
shown up after they gained considerable market share.

There is no security in this world, only opportunity.

~~~
tptacek
Careful. I'm not making a "Linux vs. Windows" argument here. I'm making a
_Linux desktop_ vs. _any other computing environment_ argument. Not all
computing environments are equally exposed to attacks. It is for instance much
more annoying to exploit iOS vulnerabilities than it is to pivot from user
"nobody" to root on an Ubuntu desktop system.

That these two environments aren't comparable --- one is a heavily-locked down
and simplified computing environment and one is a general purpose desktop
operating system --- is exactly my point.

~~~
thirsteh
I totally agree. It wouldn't be fair to compare Ubuntu to Chrome OS either.
(My response was aimed more at thrownaway2424's comment, and I didn't mean to
give the impression that everything is equally vulnerable, just that most
software has exploitable bugs that may or may not be known.)

------
vacri
On a parallel note, I remember several years ago seeing Microsoft spruiking
its 'Windows 2008 Server Headless'. Running a windows server without the gui
was mentioned right there in the MS-generated marketing material as reducing
the attack surface, as 70% of all discovered Windows exploits couldn't be done
without the GUI components.

~~~
RandallBrown
spruik [ sprook ]

    
    
        promote: to promote goods, services, or a cause by addressing people in a public place
    

I had no idea that was a word. I thought it was a typo until I couldn't figure
out what it was supposed to be.

Thanks for teaching me something new today!

~~~
thejosh
You know people who have those speakers and a microphone in stores and stand
outside a store and try to sell?

They are known as spruikers.

~~~
marshray
I don't recall ever having seen that in the US.

~~~
kivikakk
Common enough in AU!

------
krakensden
He did a presentation on it that's much better reading:

[http://cansecwest.com/slides/2013/Assessing%20the%20Linux%20...](http://cansecwest.com/slides/2013/Assessing%20the%20Linux%20Desktop%20Security%20-%20Ilja%20van%20Sprundel.ppt)

~~~
contingencies
PDF version? I would post one myself but
<https://bugs.gentoo.org/show_bug.cgi?id=471112>

~~~
wooptoo
[https://docs.google.com/viewer?url=http%3A%2F%2Fcansecwest.c...](https://docs.google.com/viewer?url=http%3A%2F%2Fcansecwest.com%2Fslides%2F2013%2FAssessing%2520the%2520Linux%2520Desktop%2520Security%2520-%2520Ilja%2520van%2520Sprundel.ppt)

~~~
contingencies
Cheers. I will use that URL next time. The comments about package managers
ring true; I have a bug open on that right now for Gentoo:
<https://bugs.gentoo.org/show_bug.cgi?id=453620>

------
lysium
Wow, that's huge! I'm wondering how this has not been noticed before.

I know, X11 is pretty old, but still, with the increasing awareness for
security in the past, it's kind of funny nobody has ever checked such a
prominent piece of software, not even in a Master's class.

Glad to see they are responding quickly.

~~~
rbanffy
> Wow, that's huge! I'm wondering how this has not been noticed before.

Most likely it's not huge. If it were, it would have been noticed before.

As to why it's not huge... That's a very interesting question.

~~~
willvarfar
Because usually you trust the x server.

This is saying that most client libraries are exploitable by a malicious x
server.

A vulnerability in the x server itself, allowing a client to take control of
it, would be rather more worrying to most people.

~~~
rbanffy
Yes, but how likely it is for your X server to get compromised? How often do
you connect to your machine using an untrusted X server?

This is like saying your car can be stolen by anyone who has its key. Yes, it
most likely can. Or that your house is vulnerable to anyone who's inside it.

~~~
mwill
This is likely why it's not been noticed before, I'd imagine the practical
consequences of this are sort of moot: If the X Server is untrustworthy,
you've likely got bigger problems.

I'll admit, my first thought was X11 Forwarding, as I understand you could
have a bogus X server to cause junk to happen on clients on a remote server
with X11 Forwarding enabled, which you'd already need credentials for. Again,
if this was viable, the attacker having SSH credentials is a bigger problem.

I can't see any way for this to be really damaging in the wild, but I'm not a
security guy so I could be totally off the mark.

------
AaronFriel
> The X.Org security team would like to take this opportunity to remind

> X client authors that current best practices suggest separating code

> that requires privileges from the GUI, to reduce the attack surface of

> issues like this.

A naïve reading of this statement seems to suggest that no "modern operating
system" built on X can be secure should they follow the X.Org team's advice
because no privileged clients can exist. Perhaps this is a gross
misunderstanding of mine with respect to how distros use X, but is it not
possible to display to the user a privileged password input window that can't
be tampered with? And, if said window can be made, wouldn't it be privileged
and thereby susceptible to this attack unless they displayed it without using
an X server?

Or would the X.Org security team suggest that operating systems run dual X
servers, or many X servers, one for each privilege level, and then render one
on top of another?

This mess has me quite confused as to the security model surrounding X.

~~~
aidenn0
I think the recommendation is to have a non-privileged X client that invokes a
privileged non-X program.

------
peterwwillis
Lame attempt to find setuid/setgid files which link to an X library:

    
    
      find /bin/ /sbin/ /lib* /usr/ /var/ /root /home -type f \( -perm -4000 -o -perm -2000 \) -exec /bin/sh -c 'ldd {} | grep -q X && echo exists in {}' \;
    

Tools that have to read the shadow file (like xlock and xscreensaver) are
sometimes setuid root. Apparently this is not necessary though:
<http://www.shmoo.com/mail/bugtraq/nov98/msg00087.html> (My slack box is set
up this way)

kppp is setuid root to perform operations only root can do, but supposedly
does it in a thread separate from GUI operations. Perhaps Linux Capabilities
could be used instead and setuid can finally be thrown out the window?

------
dlitz
These are actually vulnerabilities in Xlib, which is already well known to be
pretty crufty. X11 security has always been a joke anyway, since basically any
client can keylog the session at any point. There is some X security policy
stuff, but it was never fully developed.

The interesting part here is that there's revived interest in _fixing_ Xlib.

And for the people talking about Wayland being the future: Let's not forget
that client-side window decorations are not exactly going to be a security
improvement.

~~~
VMG
> Let's not forget that client-side window decorations are not exactly going
> to be a security improvement.

Why would it have anything to do with security?

~~~
dlitz
If we care about giving applications _restricted_ access to the display and
input devices, then we need to prevent those applications from fooling the
user. Otherwise, a rogue application can basically do phishing, clickjacking,
etc.

If we don't care about restricting access, then it doesn't make sense to call
these bugs security vulnerabilities at all.

------
epo
The headline is inflammatory and probably misleading, I thought it was
regarded as poor form to editorialize by rewriting headlines.

Yet again, in threads like this there are lots of "never done anything"
armchair quarterbacks pontificating about how to write "massive" (correct use
of the word) software libraries without regard to the age of the software in
question. X is really old, security concerns were different then. X preceded
Linux by a long way and it was the increasing usage of Linux which made X
itself achieve widespread adoption. Yes, it is kind of shocking that no one
has scoured it for vulnerabilities so far but having looked at the code a long
while ago I wouldn't want to have done it, it is _awful_.

------
caf
The original title is clearer, because it's germane that the vulnerabilities
are in the X client libraries rather than the X.Org server.

------
swdunlop
It is easy to dismiss these vulnerabilities from a perspective of a common
desktop user. "I already have privileges on this box" or "any desktop user
already has a way to escalate privileges."

But X11 is also used in process control settings where crappy ancient programs
run on decrepit old machines with modern X.org servers used for displays.
Would we be so dismissive if someone revealed a host of major vulnerabilities
in VNC or RDP clients? (Probably. :))

------
fafner
Ilja van Sprundel, the guy who found these vulnerabilities, gave an
interesting talk about "unusual bugs" at the CCC conference a couple of years
ago. Might be interesting to some of you:

Video [http://media.ccc.de/browse/congress/2006/23C3-1456-en-
unusua...](http://media.ccc.de/browse/congress/2006/23C3-1456-en-
unusual_bugs.html)

Slides
[https://dspace.it.su.se/dspace/bitstream/10102/316/1/Unusual...](https://dspace.it.su.se/dspace/bitstream/10102/316/1/Unusual+bugs+23c3.pdf)

------
DiabloD3
Has anyone done a security analysis on Weyland/Weston yet?

------
tanglesome
X.org? Still vulnerable!? I am shocked, shocked, to see these holes still
there. There's nothing really new here, what needs to be new is the will for
programmers to finally go and fix this stuff.

------
mtgx
Let's bring Mir and Wayland already.

------
EvilLook
These seem like such basic errors. Not validating responses because you trust
the software you interact with to behave is such a basic mistake that you'd
think the people that work on the X server from X.Org would have learned not
to do that long ago.

~~~
jerf
It sounds like these errors predate X.Org _qua_ X.Org. A lot of people have
had some responsibility for this code at some point without noticing this.

Bear in mind X11 is pretty old, and these are some of the oldest libraries in
the whole X constellation. That isn't an "excuse", but it's a reason.

~~~
anonymouz
And when the stuff was originally written, this was probably not considered to
be a "security boundary" in the sense that the client will have higher
privileges than the server. As the email notes, this happens rather rarely.

~~~
lawnchair_larry
Actually it was more common back then. Remember, "client" and "server" are
backwards in the context of X. A "thin client" actually runs an X Server, and
you remotely launch an xterm on the central server as an "x client", exported
to your display.

However, as the email states, this only gets you the same access your user
already had on the remote system, unless it's a setuid program. The canonical
example and only one I can think of off the top of my head is xscreensaver or
xlock. There are now GUI versions of su/sudo that would also be targets, but I
don't think variants of these were used back when this topology was common.

~~~
mprovost
This is a good read about how jwz coded xscreensaver to be secure and the
pitfalls of using GUI toolkits:

<http://www.jwz.org/xscreensaver/toolkits.html>

------
drivebyacct2
Shocker. Protocol issues. Time for another extension! Or to just shoot X.org
in the head and quell the FUD surrounding Wayland.

~~~
_pmf_
> Or to just shoot X.org in the head and quell the FUD surrounding Wayland.

Yes, we should stop being so critical and automatically embrace everything new
as much better than what came before it, due to being developed by agile
superstar developers.

~~~
drivebyacct2
Are you kidding me? Or do you just make assumptions and accusations about
technologies you don't know about?

"Super star agile developers"? That's the best FUD you can put in my mouth? By
the way, you might look up the "superstar" developers behind Wayland: Ctrl+F
"The developers":
[http://en.wikipedia.org/wiki/Wayland_(display_server_protoco...](http://en.wikipedia.org/wiki/Wayland_\(display_server_protocol\))
..... Huh, that's sure interesting.

 _Nowhere_ did I imply that Wayland was better than X simply because it was
newer. That's the _exact_ kind of FUD I'm talking about from the X.org crowd
that fears Mir and Wayland because they don't understand: the current
technologies, the future technologies, the evolution of Wayland, the
__DEVELOPERS __behind Wayland AND the HUGE list of flaws in X.

Stop spreading uninformed FUD, do _not_ put words in my mouth and don't accuse
me of being a hipster.

~~~
pfortuny
This is not helping either of you or any of us. Stay clam, take some time out
and reflect.

------
allenbina
Today's HN is sponsored by MIR

