X.Org Security Advisory For X11 Going Back To 1993

An X.Org security advisory was issued this week in regards to authenticated X clients being able to cause the X Server to use memory after it was freed. This particular use-after-free memory issue, which could lead to a system crash and memory corruption, has been present in every X11/X.Org Server release going back to September of 1993.

Alan Coopersmith of Oracle, acting on the behalf of the X.Org Security Team, came out yesterday to publicly make known a security issue reported by Pedro Ribeiro. The issue, officially known as "CVE-2013-4396: Use after free in Xserver handling of ImageText requests", means "an authenticated X client can cause an X server to use memory after it was freed, potentially leading to crash and/or memory corruption."

Use-after-free issues aren't particularly uncommon or as shocking as other security issues in the past like input security problems or the bad screensaver security issue. What makes this security advisory more interesting is how long it's been around.

While this security advisory is of rather low priority, CVE-2013-4396 has been present in the X Server for two decades. The bug was introduced in the RCS version 1.42 on 18 September 1993. Now in October of 2013, this issue was finally patched and will be included as part of the next X.Org Server 1.14 stable point release (1.14.4) and as part of X.Org Server 1.15 -- the next major release due out at the end of the year.

With the appearance of the bug in September 1993, the issue is likely found in every X server release from X11R6.0 up through the modern day X.Org Server 1.14.3 release. While the issue will be addressed in the next X.Org Server updates, there's also a small five-line patch available that takes care of the security advisory.

CVE-2013-4396 can be read on the Xorg mailing list and embedded below is the patch description with additional information on the code issue.

Save a pointer to the passed in closure structure before copying it and overwriting the *c pointer to point to our copy instead of the original. If we hit an error, once we free(c), reset c to point to the original structure before jumping to the cleanup code that references *c.

Since one of the errors being checked for is whether the server was able to malloc(c->nChars * itemSize), the client can potentially pass a number of characters chosen to cause the malloc to fail and the error path to be taken, resulting in the read from freed memory.

Since the memory is accessed almost immediately afterwards, and the X server is mostly single threaded, the odds of the free memory having invalid contents are low with most malloc implementations when not using memory debugging features, but some allocators will definitely overwrite the memory there, leading to a likely crash.