Alan Coopersmith of Oracle and X.Org veteran publicly shared the discovered security problems today:
Ilja van Sprundel, a security researcher with IOActive, has discovered a large number of issues in the way various X client libraries handle the responses they receive from servers, and has worked with X.Org's security team to analyze, confirm, and fix these issues.The noted security vulnerabilities come down to integer overflows calculating memory needs for replies, sign extension issues, buffer overflows from not validating length or offset values, integer overflows parsing user-specified files, and memory corruption due to unchecked return values.
Most of these issues stem from the client libraries trusting the server to send correct protocol data, and not verifying that the values will not overflow or cause other damage. Most of the time X clients & servers are run by the same user, with the server more privileged from the clients, so this is not a problem, but there are scenarios in which a privileged client can be connected to an unprivileged server, for instance, connecting a setuid X client (such as a screen lock program) to a virtual X server (such as Xvfb or Xephyr) which the user has modified to return invalid data, potentially allowing the user to escalate their privileges.
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.
There are issues concerning libX11, libXext, libXfices, LibXi, libXinerama, LibXp, libXrandr, libXrender, libXRes, libXtst, libXv, libXvMC, libXxf86dga, libdmx, libxcb, libGLX, libchromeXvMC, libFS, libXcursor, and libXt. Fortunately, X.Org developers are preparing new packages for all of these X.Org libraries to mitigate these security vulnerabilities.