Remote execution in the GNOME tracker

While the vulnerability itself is pretty run-of-the-mill, the recently disclosed GNOME vulnerability has a number of interesting facets. The problem lies in a library that reads files in a fairly obscure format, but it turns out that files in that format are routinely—automatically—processed by GNOME if they are downloaded to the local system. That turns a vulnerability in a largely unknown library into a one-click remote-code-execution flaw for the GNOME desktop.

libcue vulnerability

The bug was found by Kevin Backhouse, who reported it in an admirably detailed disclosure on the GitHub blog; Backhouse is a security researcher at GitHub. The cue sheet format, which stores information about the tracks on a compact disc (CD), is at the heart of the problem. The actual flaw was found and fixed in the libcue parsing library for the format. Its bison-based parser uses the venerable (and problematic) atoi() function to convert a string to an integer—without any kind of integer overflow check.

That means that an entry in the cue file, which could be coming from an untrusted source, can produce a negative number in an unexpected place. In and of itself that is not a security problem, but the value is used (as i) in the track_set_index() function without a proper sanity check:

    if (i > MAXINDEX) {
	fprintf(stderr, "too many indexes\n");
	return;
    }

    track->index[i] = ind;

Normally, though, one would not really expect to use either the file format or libcue except in applications that are dealing with CDs in various ways: rippers, music players, and the like. If those applications use libcue and processed a malicious cue file, they were vulnerable, but the scope of the problem would have been far more limited. There is another user of the library that operates in a less-obvious fashion, however: the GNOME desktop tracker search engine automatically parses files that get stored in certain directories.

Tracker makes it easier for users to search for things on their desktop, but it also exposes the parsing process to potentially malicious content. Clicking a link in a browser that results in downloading a cue file will result in the tracker miner running a tracker-extract process for the cue format, which uses libcue. Beyond just that format, though, there may be vulnerabilities lurking in parsers and libraries for other formats that are automatically parsed by tracker.

But, as reported by Backhouse, the GNOME tracker developers were at first surprised that his exploit (which he shows in a video, but the code is not yet released) was able to escape the sandbox that is being used for the tracker miners. He had encountered the sandbox while working on his exploit, but did not recognize what it was; he hit an error message about a disallowed system call, but tried another path that avoided the call, which worked. The biggest problem he needed to solve was how to route around the address-space layout randomization (ASLR) applied to the tracker-extract program.

Sandbox weakness

It turns out that the sandbox used by tracker-extract had a known weakness, as tracker developer Carlos Garnacho reported on his blog. It is based on seccomp() filters and is quite restrictive in what it allows:

Tracker took the most restrictive approach, making every system call fail with SIGSYS by default, and carving the holes necessary for correct operation of the many dependencies within the operational parameters established by yours truly (no outside network access, no filesystem write access, no execution of subprocesses). The list of rules is quite readable in the source code, every syscall there has been individually and painstakingly collected, evaluated, and pondered for inclusion.

But those policies were not applied throughout, unfortunately; there were things that the tracker needed to be able to do that could not easily be allowed while still maintaining tight restrictions on the rest. So the tracker developers took a shortcut and only applied the seccomp() restrictions to the thread that did the actual parsing and not to the main dispatcher thread. That way, the main thread could still perform the other system calls, but, of course, all of the threads share the same address space. So, the vulnerability in libcue overwrote memory in a way that caused the main thread to misbehave. As Garnacho noted, rather apologetically, that led to this highly visible vulnerability:

While not perfectly airtight, the sandbox in this case is already a defense in depth measure, only applicable after other vulnerabilities (most likely, in 3rd party libraries) were already successfully exploited, all that can be done at that point is to deter and limit the extent of the damage, so the sandbox role is to make it not immediately obvious to make something harmful without needle precision. While the "1-click exploit in GNOME" headline is surely juicy, it had not happened for these 7 years the sandbox existed, despite our uncontrollable hose of dependencies (hi, GStreamer), or our other dependencies with a history of CVEs (hi Poppler, libXML et al), so the sandbox has at least seemed to fulfill the deterrence role.

But there is that, I knew about the potential of a case like this and didn't act in time. I personally am not sure this is a much better defense than "I didn't know better!".

Garnacho has since made a series of changes to include the main thread in the seccomp()-protected sandbox. He recognizes that there will be fallout from that change: "one does not go willy-nilly adding paranoid sandbox restrictions to a behemoth like GStreamer and call it an early evening". He is hopeful that, after a release or two, the reports of problems will "settle back to relatively boring"; he also has some ideas for future security enhancements and suggests that the "rewrite it in Rust" folks consider working on some of the tracker-extract dependencies.

While this is a serious vulnerability that has put a lot of systems at risk, it seems to have been handled well by the libcue and tracker developers; the bug was also managed well by Backhouse, according to Garnacho. There are no reports of it being exploited in the wild and fixes should be available "everywhere" at this point, so the community has largely dodged a bullet. The reports by Backhouse and Garnacho are useful for understanding the bugs, and for hopefully avoiding some of these kinds of problems in the future. An upcoming post from Backhouse, which will include the proof-of-concept exploit and some additional information about his efforts, should prove instructive as well.

There is a lot of noise about rewriting the world in memory-safe languages, which is certainly a noble goal. But, in the meantime, we are all running lots of code from non-memory-safe languages on our systems. In order for that to change, these rewrites are going to have to integrate well with the existing infrastructure—or we are going to have to wait for all of that infrastructure to be rewritten as well. Finding ways to work in memory-safe replacements for existing components in the interim may well prove to be a larger challenge than the already-huge job of doing the rewrites.

Something that should be considered, perhaps, is scrutinizing all of these "convenient" things that our desktops do behind the scenes. Those actions may be buying security headaches that are worse than the convenience being gained—at least for some users. Desktops that automatically mount USB devices, potentially leading to kernel crashes or compromises, are a case in point. Even with proper sandboxes, or replacement with memory-safe equivalents, there are probably more surprises of an unpleasant variety awaiting processes that auto-parse untrusted input. There is a balance to be struck between security and convenience, for sure, but one wonders at times if the pendulum has moved too far in the convenience direction.