Anatomy of a 22-year-old X Window bug: Get root with newly uncovered flaw

Grab a patch today if you share your Unix-flavoured desktop with other people


The X Window System, which today underpins Linux desktops the world over, has been around for more than two decades – and so have its bugs.

Sysadmins have a few days to patch libXfont to remove a newly discovered, 22-year-old privilege-escalation bug in the code before any tiresome users whip out an exploit. The flaw allows someone logged into a vulnerable machine to crash the X server, or possibly execute injected code as a superuser.

Hard on the heels of a Chaos Communication Congress presentation that found “hundreds” of bugs (discussed at the X.org mailing list here), the newly found bug is a textbook stack buffer overflow that dates back to 1991 – and is present in all versions of X11.

The bug is very straightforward, and will impact shared computers, but it is ideal to dissect to reveal how this sort of security blunder happens.

As the X.org advisory states: “A BDF font file containing a longer than expected string could overflow the buffer on the stack. Testing in X servers built with Stack Protector resulted in an immediate crash when reading a user-provided specially crafted font.”

The guilty party is this block of code in bdfReadCharacters() in libXfont/tree/src/bitmap/bdfread.c:

char charName[100];

if (sscanf((char *) line, "STARTCHAR %s", charName) != 1) {
   bdfError("bad character name in BDF file\n");
   goto BAILOUT; /* bottom of function, free and return error */
}

If you can't already see the bug then we'll explain. On-screen fonts can be stored in Glyph Bitmap Distribution Format (BDF) [PDF] files, which start with the following line to declare the format version the font is adhering to:

STARTCHAR 2.1

That's all well and good if the loaded font has a short version number, expressed as a string, which in this case is "2.1". That information is copied into the string variable charName by the sscanf() call in bdfread.c. The problem is, sscanf() is not told to limit the number of bytes read for the version number and will keep copying data from the file until it hits a white-space character.

The charName variable is declared as having a length of 100 bytes, so feeding it a crafted BDF font with a "STARTCHAR" version number longer than that will punch through the boundary of the variable's allotted space in memory and into other data on the stack. This means an attacker could overwrite the memory that controls the processor's instruction pointer on leaving the bdfReadCharacters() function, effectively hijacking the program.

And since the X server is usually run with superuser privileges, the normal user can start running code to take control of the machine if the attack is successful. Much more in-depth explanations on how stack buffer overflows can be exploited, despite some of the protections in place on modern systems, can be found here and here.

The fix for the bug is simple; you simply tell sscanf() to read at most 99 bytes, leaving one for the terminating NULL:

if (sscanf((char *) line, "STARTCHAR %99s", charName) != 1) {

As the X.org announcement states:

As libXfont is used to read user-specified font files in all X servers distributed by X.Org, including the Xorg server which is often run with root privileges or as setuid-root in order to access hardware, this bug may lead to an unprivileged user acquiring root privileges in some systems.

In the December Chaos Communication Congress presentation, Ilja van Sprundel said he'd able to find 120 bugs in a couple of months, “and I'm not close to done”. Van Sprundel had already triggered a major X.org security update in May 2013, with tens of fixes needed because client libraries trusted servers to send valid data, and not sanity-tested what was sent.

The latest bug, discovered using the cppcheck static analyzer, is designated CVE-2013-6462; security updates should be available from all good package managers and repositories. ®

Similar topics


Other stories you might like

  • Cisco warns of security holes in its security appliances
    Bugs potentially useful for rogue insiders, admin account hijackers

    Cisco has alerted customers to another four vulnerabilities in its products, including a high-severity flaw in its email and web security appliances. 

    The networking giant has issued a patch for that bug, tracked as CVE-2022-20664. The flaw is present in the web management interface of Cisco's Secure Email and Web Manager and Email Security Appliance in both the virtual and hardware appliances. Some earlier versions of both products, we note, have reached end of life, and so the manufacturer won't release fixes; it instead told customers to migrate to a newer version and dump the old.

    This bug received a 7.7 out of 10 CVSS severity score, and Cisco noted that its security team is not aware of any in-the-wild exploitation, so far. That said, given the speed of reverse engineering, that day is likely to come. 

    Continue reading
  • Google battles bots, puts Workspace admins on alert
    No security alert fatigue here

    Google has added API security tools and Workspace (formerly G-Suite) admin alerts about potentially risky configuration changes such as super admin passwords resets.

    The API capabilities – aptly named "Advanced API Security" – are built on top of Apigee, the API management platform that the web giant bought for $625 million six years ago.

    As API data makes up an increasing amount of internet traffic – Cloudflare says more than 50 percent of all of the traffic it processes is API based, and it's growing twice as fast as traditional web traffic – API security becomes more important to enterprises. Malicious actors can use API calls to bypass network security measures and connect directly to backend systems or launch DDoS attacks.

    Continue reading
  • Zero Trust: What does it actually mean – and why would you want it?
    'Narrow and specific access rights after authentication' wasn't catchy enough

    Systems Approach Since publishing our article and video on APIs, I’ve talked with a few people on the API topic, and one aspect that keeps coming up is the importance of security for APIs.

    In particular, I hear the term “zero trust” increasingly being applied to APIs, which led to the idea for this post. At the same time, I’ve also noticed what might be called a zero trust backlash, as it becomes apparent that you can’t wave a zero trust wand and instantly solve all your security concerns.

    Zero trust has been on my radar for almost a decade, as it was part of the environment that enabled network virtualization to take off. We’ve told that story briefly in our SDN book – the rise of microsegmentation as a widespread use-case was arguably the critical step that took network virtualization from a niche technology to the mainstream.

    Continue reading

Biting the hand that feeds IT © 1998–2022