Numerous security issues in X Window System clients

> In the meanwhile, the "fixes" in question are nearly pointless and seriously broken. Nearly pointless because compromised _server_ doesn't need to bugger the memory of client with overflows; usually it can do it either with ptrace (when on the same box) or via ssh + ptrace (when the client runs on remote box). Seriously broken - hell knows why, presumably it didn't get reviewed (embargo?).

What I think you are missing is that it's common to run certain setuid root binaries or run programs via sudo.

I think a large part of that has been mitigated on full-flavored desktops like Gnome, but with the popularity of 'lite'er desktops then a lot of administrative duties is done via sudo and whatnot.

So any sort of flaw in x libraries means local and even remote root exploit.

The point of these is not to protect a user from a compromised server - it's to protect a system from a malicious local unprivileged user compromising a privileged client using their own customized server in order to gain the privileges of that client. For people running Linux on a box in which they're the only user, this is pretty much a non-problem (as long as you're sure no remote attacker could ever break in and then use a bug such as this to break in further), but for sites like schools & businesses using servers with many users, it could be worse.

While the common case of an X server is a privileged process talking directly to the hardware, it's simply a binary protocol - any program that can open a socket and respond in the fashion documented in the X protocol spec can act as an X server if you set your $DISPLAY to point to it. In the process of testing these I was able to corrupt memory in the clients with an “X server” consisting of less than 1000 lines of C code.

> presumably it didn't get reviewed (embargo?).

Yes, the embargo made it difficult to get review for the sheer number of patches involved and you'll note many of the commits missing a “Reviewed-by” tag. We got good coverage of the libX11 & libXi changes, not so much of the rest of the libraries.

Several of us also tested with the libraries on our desktops for a few weeks before release, but I don't think any of us use video players with libXvmc support. (I also missed an XKB bug because I use the default US/English keyboard layout and don't change layouts at runtime - our QA team in Oracle's Prague office found that quite quickly since failing to load a cz layout is much more noticeable to them, and Julien Cristau had developed a fix for Debian at the same time.) We also ran the automated test suites we have, but those mostly cover the libraries from the X11R5/6 timeframe in the mid-90's, not the later extensions, since no one has funded the tedious work of test case writing since then, and few have volunteered much time to work on that.

You can see from the git commit dates we'd been working on these for about 3 months, and finally figured we'd done as much as we could do on the private/embargoed list, so put them out to the world for wider review & testing. I specifically chose not to cut new stable releases of the libraries until this happened, and am glad to see we've gotten better testing and bugs reported via distros such as Debian who put them out to their users quickly.

> this demonstrates a damn good way to insert a hole into some tree - pile up a lot of obvious stuff ("hardening" of that sort, etc.) and bury the backdoor in pages upon pages of that

Yes, code review will never be perfect, and even small changes can introduce security holes - we've found that in X before when a bunch of code reviewers failed to notice a missing pair of parentheses that led to CVE-2006-0745, and only when Coverity pointed them out did we spot the bug and the implications.