LWN: Comments on "Pondering the X client vulnerabilities"

Pondering the X client vulnerabilities

hummassa — Mon, 15 Jul 2013 11:34:52 +0000

While you are kind of right (Windows apps are equally open to each other, etc), the point is moot when the owned part is the display/X11 server. Because it's the server that is sending your client the keystrokes that you type in your keyboard, and your client cannot distinguish real keystrokes from inserted keystrokes (well, using some sophisticated timing techniques, it can *try*, but all bets are off anyway.)

Pondering the X client vulnerabilities

yuhong — Mon, 15 Jul 2013 07:41:54 +0000

10 years ago was before X11R6.7 even existed.

Pondering the X client vulnerabilities

kevinm — Thu, 06 Jun 2013 08:55:38 +0000

Actually, for the restriction you gave ("a pointer assigned an address in array X cannot point outside that array by pointer arithmetic"), you *could* implement pretty much that restriction and still call it C. In C, pointer arithmetic is only defined if it results in a pointer within the original object or one object past the end of an array.

The major obstacle would be that you'd need an ABI change to pass around the necessary object extent data to enforce this everywhere.

Pondering the X client vulnerabilities

kleptog — Wed, 05 Jun 2013 20:31:19 +0000

Interesting, but it looks like it just punted and just created a new language that looks like C but isn't. Which means it's never going to catch on because it would require changing the code.

I mean, valgrind manages to catch all sorts of memory errors without any source with not many false positives. ISTM a compiler should be able to do a similar job but more efficiently (because valgrind slow as molasses, but points out the error to you right away, which is what makes it worth it).

Pondering the X client vulnerabilities

nix — Wed, 05 Jun 2013 20:09:00 +0000

Agreed. Really nothing at all should use the suid/sgid bits to gain privilege. They should use something like d-bus services (or, in an ideal world, userv, but nobody but me and Ian Jackson seems to have heard of that) to request that a process that is already root create a new instance of the appropriate thing on its behalf. Without a parent/child relationship you're free of the unexpected inherited state problems that cause so much trouble for SUID binaries, with the slight additional problem that you have to reflect stdout/stderr for the new process. But a library should be able to handle that (something else which, IIRC, userv does but D-Bus does not...)

Pondering the X client vulnerabilities

epa — Wed, 05 Jun 2013 11:03:50 +0000

I'm not going to pretend that because computers are faster, there is no longer performance-critical code. (Even though it is worth bearing in mind that today's mobile platforms or ARM-based servers are still far more powerful than the high-end workstations for which X was written.) My point is that some code is performance-critical, but not *all of it*. The 80-20 rule applies - actually more like 99-1, where a small part of the code is the inner loop where micro-optimizations like skipping bounds checking make a difference.

By all means profile the code, find the hot sections, and after careful review turn off safety for those. That does not justify running without bounds checking or overflow checking for the rest of the code.

Pondering the X client vulnerabilities

epa — Wed, 05 Jun 2013 10:10:50 +0000

Have you looked at Cyclone?

Pondering the X client vulnerabilities

anselm — Mon, 03 Jun 2013 14:21:36 +0000

Nobody needs to use Qt's threading and networking primitives when running SUID root, which is a completely different ballgame than running as root as a daemon.

There's probably nothing wrong with using the non-GUI parts of Qt to implement a threaded networking daemon, if one doesn't mind the Qt haters' jumping all over one. But such a daemon would not run SUID root; it would be started as root initially (from something like SysV init or systemd) and then drop its root privileges ASAP.

It was actually Cyberax who claimed that »It's actually EXTREMELY common to have networked programs to be SUIDed«. This is apparently so common that so far he hasn't managed to come up with one single example.

Pondering the X client vulnerabilities

nix — Mon, 03 Jun 2013 13:54:25 +0000

It's not, but the thread had drifted to saying that nobody needs to use the threading primitives and the like that Qt provides while running as root. This is tantamount to saying that nobody would want to write threaded code that runs as root, which is ridiculous. (syslog-ng and systemd both use Glib for much the same reason, and Glib provides rather worse facilities in this area than does Qt, IMNSHO.)

Qt is not just about GUI stuff, and hasn't been for as long as KDE has been using it, pretty much. (It only got properly separated out in Qt 4, though.)

Pondering the X client vulnerabilities

hummassa — Fri, 31 May 2013 18:58:00 +0000

That was my point:
X screensavers (I have a tonne of them installed, and none is suid) usually do not try to listen to restricted ports. Kppp is usually more secure if used suid, for the reasons described here (*). The "extremely common" thing is way off IMHO.

(*) http://www.oocities.org/margineantm/syspp/murphy.html

Android doesn't really run Java

dvdeug — Fri, 31 May 2013 18:12:23 +0000

Java doesn't need to be interpreted; I presume it makes it easier to limit Android code and it certainly makes MIPS and ARM Androids both possible. In any case, it's not really relevant to the question of use-after-frees and buffer overruns.

The low-level stuff can't be ignored, but I'm a lot more comfortable having the base libraries be written in C, since they're written by someone who presumably knows what they're doing, and having the programs running on that code written in Java.

As for the browser, you're talking about a tool that deals with a sustained barrage of untrusted material, and it's not hard to feed a web browser compromised material. Looking at Chrome's recent vulnerabilities, in May we had 8 use-after-frees and one out-of-bounds read (and four other), and in March we had 6 use-after-frees and 1 out-of-bounds read (and 15 other, including some "memory corruptions"). (Counts of CVEs listed in Debian's changelog.)

As hummassa says, there's other standard security errors that Python and Java as well as C and C++ get up to. But 45% of Chrome's recent CVEs wouldn't have existed in Java or similar systems. Pick the low-hanging fruit first.

Pondering the X client vulnerabilities

jschrod — Fri, 31 May 2013 15:32:18 +0000

X screen savers are sometimes installed suid, too.

FTR: I didn't want to question that there aren't suid X programs. I question that this happens to be "EXTREMELY common" and that access to low network ports is the reason to be so.

Pondering the X client vulnerabilities

hummassa — Fri, 31 May 2013 15:26:39 +0000

well, actually...

in my 5308-packages-installed Kubuntu desktop, I found ONE setuid file linked with X libs: kppp (and none setgid). One moment of googling, and I found this:

> Why is KPPP installed with the setuid bit on?

> There is no need for the setuid bit, if you know a bit of UNIX® systems administration. Simply create a modem group, add all users that you want to give access to the modem to that group and make the modem device read/writable for that group. Also if you want DNS configuration to work with KPPP, then /etc/resolv.conf must be read/writable by the members of that group. The same counts for /etc/ppp/pap-secrets and /etc/ppp/chap-secrets if you want to use the built-in PAP or CHAP support, respectively.

> The KPPP team has lately done a lot of work to make KPPP setuid-safe. But it's up to you to decide if you install and how you install it.

http://docs.kde.org/development/en/kdenetwork/kppp/faq.ht...

I will not bother with it, for now...

Android doesn't really run Java

hummassa — Fri, 31 May 2013 14:01:06 +0000

You are right. And, of course, the performance penalty theoretically, at least, would increase still more when we are talking about performance as battery/energy economy. BTW -- THAT is what I'd like to see measured in this context.

In the same topic, people demonize C mainly because of three things: null pointers, buffer overflows and integer overflows. You can write beautiful and as-efficient-as C++ code without any of those. But PHP/Java-like vulns would persist (data scrubbing/encoding/quoting errors mainly) are a little bit more difficult.

Android doesn't really run Java

alex — Fri, 31 May 2013 11:39:54 +0000

Well obviously I'm being a little trollish ;-)

However an awful lot of the performance critical areas of the code are written in lower level code and exported to Java via JNI (not to mention key components like the browser which is pretty much all C++). There is a debate to be had as to how much can you ameliorate some of the worst areas of C with C++ but once you start up the road to interpreted/JITed higher level languages you will pay a performance penalty. It's fine when they are making fairly simple decisions that result in work for lower down the stack but when you are moving lots of stuff around you really don't to be in even the most efficient JIT code.

Pondering the X client vulnerabilities

jschrod — Fri, 31 May 2013 10:45:59 +0000

Could you please name some of these »EXTREMELY common programs« that are suid and bind to network ports < 1024?

I'm using Linux and Unix since many decades, and I'm not aware of them, but willing to learn more. (I've got daemons that bind to ports, but they are not suid, they are started by root. Even an X server is most often not suid nowadays, with xdm and friends.)

Pondering the X client vulnerabilities

anselm — Thu, 30 May 2013 23:15:08 +0000

Programs that need to open ports below 1024 for listening are not usually X clients. They are servers/daemons that are commonly run as root to begin with (and drop their privileges as soon as they can), rather than SUID-root programs. This is a completely different ball game.

Pondering the X client vulnerabilities

anselm — Thu, 30 May 2013 23:12:10 +0000

Since when is BIND a SUID-root X11 client?

Pondering the X client vulnerabilities

nix — Thu, 30 May 2013 22:27:30 +0000

BIND is a classic example of something which needs just that privilege (though it switches user after startup) and also happens to be threaded.

Pondering the X client vulnerabilities

dvdeug — Thu, 30 May 2013 21:17:09 +0000

Android runs Java. The first Power Mac G4 in 1999 had problems with export because it was classified as a super computer; every smart phone on the planet is faster then those systems running at 400 MHz.

I've never understood why an increase in speed is worth having to tell your customers that their credit card numbers are in the hands of hackers, or having your website hosting child porn. Taking the website down for a week while your IT department (getting massive overtime) is trying to recover what it can from your compromised systems is bloody expensive. It's a classic surcharge on day-to-day operations to prevent possible disaster.

Pondering the X client vulnerabilities

kleptog — Thu, 30 May 2013 20:48:17 +0000

The amount of code written in C is so vast that trying to fiddle with basic features of the language (like pointer arithmetic) will simply lead to vast swathes of C code failing to compile. To get people to advance to newer versions of the language requires not leaving a huge percentage of people behind. Witness Python 2 vs 3.

In any case, C doesn't need to become a safe language. There are plenty of safe languages to code in, you need at least one unsafe language to code all the safe languages in. It may as well be C.

What I think would really make a difference is if someone actually implemented a working C-like language (you couldn't call it C) that had a few extra restrictions, like: 'a pointer assigned an address in array X cannot point outside that array by pointer arithmetic'. And then demonstrated that it (a) performed ok and (b) ran >99% of existing C code.

I think the easiest way to achieve this would be code a C interpreter in PyPy where you could implement the restrictions, and you get a JIT to make it perform. If you could make this work, my guess is you could convince a lot of people run most C programs under such an interpreter and you would have solved the problems for a significant portion of the codebase.

But whether its actually achievable....

Pondering the X client vulnerabilities

richmoore — Thu, 30 May 2013 19:41:54 +0000

Find a problem in the core networking code, for example a problem that might lead to code execution due to incorrectly parsing responses and sure, we'd regard that as a problem and would fix it straight away.

The problem reported against Qt was simply someone using something incorrectly, and being told they've done so, then complaining it doesn't work. A couple of the issues spotted were genuine bugs, and should be addressed (I'm not aware that they actually filed them btw) but they aren't security holes in Qt.

Pondering the X client vulnerabilities

krakensden — Thu, 30 May 2013 17:52:25 +0000

I would be interested in an investigation of the non-X related problems he reported, like bad dbus configuration. The freedesktop.org, gnome, and kde layers of the stack are frankly a mystery to me (and others- google for 'disable networkmanager'), and there is a great deal of churn...

Pondering the X client vulnerabilities

Cyberax — Thu, 30 May 2013 17:48:50 +0000

It's actually EXTREMELY common to have networked programs to be SUIDed because of the @#$@#(@ requirement to be root to bind to ports <1024 (yeah, you can use caps, but they are not present on all OSes).

So you need at least have the code to parse config files to be run as root.

Pondering the X client vulnerabilities

anselm — Thu, 30 May 2013 17:45:50 +0000

There's nothing wrong with Qt in general.

I would however be very suspicious of any SUID program that required the use of »network support and threading primitives«, whether it is based on Qt or anything else. (The X server comes to mind but that's another story.) If nothing else it should be possible to structure one's X client program such that any code that needs special privileges is put into a minimal separate executable that can then be SUID – and nowadays there are various other approaches one could take that may make SUID completely unnecessary in this context.

Pondering the X client vulnerabilities

tjc — Thu, 30 May 2013 17:15:11 +0000

The "thick pointer" size problem could be solved by defining a thick pointer with just one additional member, an index (generated by the compiler or run-time code) into a global run-time data structure that includes the remaining information about the pointer. This way all thick pointers have the same size, and the remaining information doesn't have to be passed around on the stack.

Pondering the X client vulnerabilities

Cyberax — Thu, 30 May 2013 16:54:36 +0000

Except that Qt also has quite good network support and threading primitives. Some people might want to use it just because of them. Is it bad?

Pondering the X client vulnerabilities

richmoore — Thu, 30 May 2013 16:24:28 +0000

The comments about GTK there largely apply to Qt too. Writing setuid Qt applications is stupid. I'm the person being quoted in the presentation, and I stand by what I said - if people are writing setuid binaries that do this sort of thing then that's the buggy program not Qt. People writing setuid binaries have to learn how to make them secure if they want to make them for general use, there are many ways people can screw them up.

Any distro daft enough to package a setuid binary that links a GUI needs to buck their ideas up too.

Pondering the X client vulnerabilities

mpr22 — Thu, 30 May 2013 12:20:46 +0000

I say the following as someone who loves C and codes in it for a hobby and for a living: As footguns go, the C-style (let's not use the word "thin", since it appears to have caused confusion) pointer is a Single Action Army with six in the cylinder.

Safer-than-C pointers have stricter semantics. You can't just casually toss them into, and fish them back out of, the semantics-free abyss that is void *. You can't use safe_pointer_to_foo as if it was safe_pointer_to_array_of_foo; if you want a mutable handle to an entry in an array_of_foo, you create an iterator_on_array_of_foo, which consists of a safe_pointer_to_array_of_foo and an index.

And the principle of defensive design indicates that since language and library safety features exist to protect the user from the effects of the programmer's idiocy, the syntax that is quick and easy to use should be the one that has all the safeties enabled, and if the compiler can't sufficiently intelligently optimize away redundant safeties then there should be an unsafe syntax carrying a significant dose of syntactic salt. Unfortunately, because people tend to resist even those changes from which they would get real benefits, getting such a change of outlook past the standards committee is very hard.

Pondering the X client vulnerabilities

hummassa — Thu, 30 May 2013 11:22:49 +0000

in the late 1990's and early 2000's it was somewhat true that we had lots of space for non-performance-critical code... But these days, what we have are lots of mobile platforms and high-power-efficiency server platforms, where performance and cost-to-benefit-ratio are measured not only in "operations per second", but also in "operations per milliwatt-hour"... so, unless the other languages made great strides in things like "not wasting a lot of RAM space and CPU cycles to achieve the same end result" (and yes, some did...) C/C++ (esp. the latter) seems like a good solution in many cases.

Pondering the X client vulnerabilities

etienne — Thu, 30 May 2013 11:18:40 +0000

> Unchecked 'thin pointers' ought to be only for performance-critical code by now.

Please define 'thick pointers', the opposite of 'thin pointers'.
An address plus a size? The size of what?
OK, for a structure, a thick pointer to that structure is { pointer + size of structure}.
For an array of structures, a thick pointer to that array is { pointer + size of complete array}. To get a thick pointer to an element of that array, you now need the size of that element - possible.
Now you want to scan through an array, you do not want a thick pointer to an element of the array (because you will not be able to increment this thick pointer to point to the next element), you want a thick pointer to an array of element, each times you increment the thick pointer you decrement the size of this thick pointer by the size of the structure of the array.
Now someone wants to search something in the array from the end of the array, each times you decrement the thick pointer you increment this thick pointer size by the size of the structure of the array. But then what stops you to go below the start of the array? You need to include a minimum base address into the thick pointer?
Now imagine all this is about chars and array of chars - your thick pointer is bigger than the string you are manipulating, and you code initially only prints an hexadecimal value into an array of 256 bytes, you know it will not overflow.
You think the compiler will be able to optimise and remove a field of a structure (thick pointer size) when it is obvious there will not be any problem? It is not going to happen if the function is not static inside the C file.
The "thick pointer size" can also be a variable inside the compiler (range analysis) instead of inside the compiled function, but that has its limits.

Pondering the X client vulnerabilities

mpr22 — Thu, 30 May 2013 09:27:32 +0000

If someone is coding in C (or C++, for that matter), there's a decent chance they already believe all their code is performance-critical.

Pondering the X client vulnerabilities

epa — Wed, 29 May 2013 21:29:18 +0000

Yes, absolutely, I was referring to the social environment that makes C a common language despite it being far too easy to make dangerous mistakes. It's not as if safer ways of programming didn't exist even back in 1984 - but then, the choice of C was more understandable since alternatives were equally flawed in various ways. Why, though, doesn't the C language become a bit safer with each new version (C89, C99, C11) with code gradually being moved across? Unchecked 'thin pointers' ought to be only for performance-critical code by now.

Pondering the X client vulnerabilities

jg — Wed, 29 May 2013 21:13:13 +0000

Key pieces of X were written by individuals, not teams. I did the original Xlib (under extreme time pressure for X11); Bob did the device independent part of the X server up until X11, and so on.

The code base in that era was very much smaller.

A community large enough to provide useful code reviews did not exist in the early years of X... And security problems in that era were very small: the bad guys weren't out to get us in the 1980's and early 1990's, so there was little incentive to go find them or do such code reviews once there was a viable community.

And then things stagnated, particularly after the X Consortium closed. Long, long, long story there....

Unfortunately, many mistakes of my era were cut and pasted into later X extension libraries, replicating bugs. And other people created new bugs as X continued to evolve over the decades as well. Creativity is found everywhere ;-).

Pondering the X client vulnerabilities

smoogen — Wed, 29 May 2013 21:08:10 +0000

Those things are controlled by more on social pressure than code advances. It doesn't matter if you figured out how much Esperanto is better than every other European language out there.. if no one else around you uses it then you are pretty much talking to yourself. And while you can code yourself a nice program in Cyclone.. you aren't going to get a lot of help when you want to make it big.

That social inertia is what keeps certain languages in place even after you would think they should have been put away 20-30 years ago.

Pondering the X client vulnerabilities

jg — Wed, 29 May 2013 21:05:10 +0000

Well, there are still a few lines of code from W (in a few header files): those date from 1982 and 1083.

Bob Scheifler and I started working on X1 in June of 1984.

X11's (the protocol framework version used today) was shipped in 1987, IIRC.

There were precious few options available to us.

One of the early X Window managers and a terminal emulator were written in Clu, however. http://en.wikipedia.org/wiki/CLU_(programming_language) Bob Scheifler worked for Barbara Liskov.

But Clu wasn't available on other platforms (Project Athena, where I worked at the time as a Digital employee, was a joint project with IBM, and what became the IBM RT/PC was known to be in our future. Sun's were also widespread. So we needed a language that was cross platform. C++ wasn't yet an option either.

So we "knew better", but there just wasn't any actually viable alternative to C in that era.

Pondering the X client vulnerabilities

epa — Wed, 29 May 2013 20:12:29 +0000

I went along with the article's statement that this code was from the early 90s (though the first versions of X were much older). But really my comment is not a criticism of the developers as of the glacial pace at which programming environments improve for general use. You'd think that safer C variants such as Cyclone would have displaced plain C by now, or better that the standards committees would have incorporated most of their safety features into newer C standards - with a way to turn them off on a case by case basis.

Pondering the X client vulnerabilities

Cyberax — Wed, 29 May 2013 18:47:44 +0000

It's supported in X, but kinda pointless (given the huge attack surface). Also XAce by itself doesn't define any ACL protocol, it just provides hooks for third-party modules.

Pondering the X client vulnerabilities

dtlin — Wed, 29 May 2013 18:20:55 +0000

Did XAce not happen? (I don't really know how well it works or if there's any users…)

Pondering the X client vulnerabilities

nirbheek — Wed, 29 May 2013 09:02:03 +0000

This is something that most people do not realise about the X server. There's almost no access control inside it. Any app can do almost anything to any other app. It's ridiculous.