Pondering the X client vulnerabilities

Certain projects are known for disclosing a large number of vulnerabilities at once; such behavior is especially common in company-owned projects where fixes are released in batches. Even those projects, though, rarely turn up with 30 new CVE numbers in a single day. But, on May 23, the X.org project did exactly that when it disclosed a large number of security vulnerabilities in various X client libraries — some of which could be more than two decades old.

The vulnerabilities

The X Window System has a classic client/server architecture, with the X server providing display and input services for a range of client applications. The two sides communicate via a well-defined (if much extended) protocol that, in theory, provides for network-transparent operation. In any protocol implementation, developers must take into account the possibility that one of the participants is compromised or overtly hostile. In short, that is what did not happen in the X client libraries.

In particular, the client libraries contained many assumptions about the trustworthiness of the data coming from the X server. Keymap indexes were not checked to verify that they fell in the range of known keys. Very large buffer size values from the server could cause integer overflows on the client side; that, in turn, could lead to the allocation of undersized buffers that could subsequently be overflowed. File-processing code could be forced into unbounded recursion by hostile input. And so on. The bottom line is that an attacker who controls an X server has a long list of possible ways to compromise the clients connected to that server.

Despite the seemingly scary nature of most of these vulnerabilities, the impact on most users should be minimal. Most of the time, the user is in control of the server, which is usually running in a privileged mode. Any remote attacker who can compromise such a server will not need to be concerned with client library exploits; the game will have already been lost. The biggest threat, arguably, is attacks against setuid programs by a local user. If the user can control the server (perhaps by using one of the virtual X server applications), it may be possible to subvert a privileged program, enabling privilege escalation on the local machine. For this reason, applying the updates makes sense in many situations, but it may not be a matter of immediate urgency.

Many of these vulnerabilities have been around for a long time; the advisory states that "X.Org believes all prior versions of these libraries contain these flaws, dating back to their introduction." That introduction, for the bulk of the libraries involved, was in the 1990's. That is a long time for some (in retrospect) fairly obvious errors to go undetected in code that is this widely used.

Some thoughts

One can certainly make excuses for the developers who implemented those libraries 20 years or so ago. The net was not so hostile — or so pervasive — and it hadn't yet occurred to developers that their code might have to interact with overly hostile peers. A lot of code written in those days has needed refurbishing since. It is a bit more interesting to ponder why that refurbishing took so long to happen in this case. X has long inspired fears of security issues, after all. But, traditionally, those fears have been centered around the server, since that is where the privilege lies. If you operate under the assumption that the server is the line of defense, there is little reason to be concerned about the prospect of the server attacking its clients. It undoubtedly seemed better to focus on reinforcing the server itself.

Even so, one might think that somebody would have gotten around to looking at the X library code before Ilja van Sprundel took on the task in 2013. After all, if vulnerable code exists, somebody, somewhere will figure out a way to exploit it, and attackers have no qualms about looking for problems in ancient code. The X libraries are widely used and, for better or worse, they do often get linked into privileged programs that, arguably, should not be mixing interface and privilege in this way. It seems fairly likely that at least some of these vulnerabilities have been known to attackers for some time.

In the free software community, we tend to take pride in our review processes which, we hope, keep bugs out of our code and vulnerabilities out of our system. In this case, though, it is now clear that some of our most widely used library code has not seen a serious review pass for a long time. Recent kernel vulnerabilities, too, have shown that our code is not as well reviewed as we might like to think. Often, it seems, the black hats are scrutinizing our code more closely than our developers and maintainers are.

Fixing this will not be easy. Deep code review has always been in short supply in our community, and for easily understandable reasons: the work is tedious, painstaking, and often unrewarding. Developers with the skill to perform this kind of review tend to be happier when they are writing code of their own. Getting these developers to volunteer more of their time for code review is always going to be an uphill battle.

The various companies working in this area could help the situation by paying for more security review work. There are some signs that more of this is happening than in the past, but this, too, has tended to be a hard sell. Most companies sponsor development work to help ensure that their own needs are adequately met by the project(s) in question. General security work does not add features or enable more hardware; the rewards from doing this work may seem nebulous at best. So most companies, especially if they do not feel threatened by the current level of security in our code, feel that security work is something they can leave to others.

So we will probably continue to muddle along with code that contains a variety of vulnerabilities, both old and new. Most of the time, it works well enough — at least, as far as we know. And on that cheery note, your editor has to run; there's a whole set of new security updates to apply.

Index entries for this article
Security	X client

---

to post comments