Development

GStreamer and the state of Linux desktop security

Recently Chris Evans, an IT security expert currently working for Tesla, published a series of blog posts about security vulnerabilities in the GStreamer multimedia framework. A combination of the Chrome browser and GNOME-based desktops creates a particularly scary vulnerability. Evans also made a provocative statement: that vulnerabilities of this severity currently wouldn't happen in Windows 10. Is the state of security on the Linux desktop really that bad — and what can be done about it?

From Chrome via Tracker to GStreamer

The scenario Evans described allows exploiting security vulnerabilities in a wide variety of applications by drive-by downloads by the Chrome browser without any user interaction. By default, Chrome automatically saves downloaded files in the "Downloads" subdirectory of the user's home directory. This particular behavior is unique to Chrome. Other browsers show a dialog on downloads and let the user choose a location to save a file. With this behavior a web page can automatically cause downloads. No user interaction is required, even the click on a download link can be triggered via JavaScript. Chromium, which is the free-software variant of Chrome and is usually the one packaged by Linux distributions, behaves in the same way.

Chrome's behavior isn't unique to Linux, but in combination with another feature it becomes dangerous: on GNOME desktops a service called Tracker automatically indexes all new files. (KDE has an analogous tool called Baloo that has similar problems.) Tracker uses a variety of tools and libraries to extract metadata from files. For media files Tracker uses the GStreamer framework. Images are parsed with ImageMagick and PDF files with Poppler. Thus we end up in a situation where downloads automatically triggered by a potentially malicious web page are directly passed to various parsers of complex file formats. Most of these parsers are written in C, which makes them susceptible to the typical memory-corruption vulnerabilities. Tracker is enabled by default, though it can be controlled by running tracker-preferences.

GStreamer is a multimedia framework that includes support for a wide variety of file formats, including some obscure and rare ones. Evans pointed out bugs in the parsers for Nintendo Sound Files (from NES games), for a VMware screen-capture format, and for FLIC animations, the file format of the DOS Software Autodesk Animator, which had its last release 21 years ago. The codecs for the latter two are part of the default GNOME installations on both Fedora and Debian.

GStreamer plays almost every media file ever created

GStreamer has a noble goal: it tries to allow users to play almost every audio or video file ever created. From a usability perspective, this is certainly valuable and often considered a strength of free and open-source software. For almost every file format out there, there's some software that is able to access it. Having software available to play arcane media files also plays an important role in keeping the history of the digital age accessible. But these projects come with a cost when it comes to security. Parsing complex binary file types in a secure way is an incredibly difficult task. It's not surprising that many parsers have memory-corruption vulnerabilities.

Thus the decision of GNOME's Tracker software to use these parsers is a questionable design choice. GStreamer is not the only problematic software used by Tracker. ImageMagick has a purpose similar to that of GStreamer. It supports reading 177 different image formats and it has seen a constant flow of vulnerability reports over the years. Many other libraries that Tracker uses to identify ISO images, extract MP3 tags, or parse playlists look at least potentially problematic. Again, from a usability perspective, the choices made by Tracker make sense. For a desktop search, being able to parse the metadata of a wide variety of different file types is a desirable feature. But security-wise it looks like a recipe for disaster.

It is no secret that many libraries were never written with security in mind. In the past few years the availability of increasingly powerful fuzz testing tools like american fuzzy lop (afl) has shed a light on this. There's a small number of libraries where security vulnerabilities are relatively rare and hard to find. Usually these are the libraries used by the large browser vendors. The generous bug bounties paid by browser makers give security researchers an incentive to investigate vulnerabilities. Also the browser vendors themselves have an interest in securing the code they are exposing and often use their own infrastructure to test them or fund audits for key libraries.

The situation for other, less exposed libraries is much more dire. When looking at a random library that parses complex file formats, it is likely that one can find crashes caused by memory-corruption vulnerabilities within seconds. To help combat this problem, I started the Fuzzing Project two years ago. The Fuzzing Project is a concentrated effort to wipe out the many bugs that can easily be found with fuzz testing in popular free and open-source software.

In the case of GStreamer, it is likely that before Evans's reports nobody ever tried to use modern coverage-based fuzzing tools on the code base. After Evans's post, though, I ran afl on GStreamer and found several bugs that the GStreamer team quickly fixed. But even if the GStreamer code base could be secured, which itself is a huge challenge, the problem goes deeper: GStreamer doesn't only contain its own parser, it makes use of a wide variety of libraries for different file formats. Properly testing and fixing all of them is an enormous task.

Prevention techniques

The prevalence of memory-corruption vulnerabilities in software written in C and C++ has recently fueled a debate on whether a switch to safer programming languages could avoid many of these problems. The programming language Rust, which is developed by Mozilla, is often cited as the most likely alternative to C. GStreamer has recently started to investigate the ability to write plugins in Rust. While these are worthy efforts, rewriting software in another programming language takes time. Realistically, most of the software underpinning the Linux desktop will stay as C code for a very long time.

In the IT security world, most people agree that it's not realistic to avoid all security bugs. Therefore a lot of effort has been put into mitigation techniques that make it hard or impossible to exploit security vulnerabilities. Various sandboxing efforts try to separate processes from each other and limit the impact of security vulnerabilities.

According to Evans, a tool like Tracker is an almost ideal target for sandboxing:

On Linux, the generic sandboxing framework provided by the kernel is seccomp. There's an open bug in the GNOME bug tracker about sandboxing the Tracker data collection process. A preliminary patch using libseccomp to sandbox that process has been posted in the bug.

Operating systems and compilers also try to make exploitation harder with mitigation techniques that avoid typical exploit paths for memory-corruption vulnerabilities. Stack canaries and non-executable memory pages are widely used on all modern operating systems. However the Linux community has been slow in adopting one of the strongest mitigation techniques available: address space layout randomization or ASLR. Exploitation techniques like return-oriented programming (ROP) rely on the fact that an attacker can jump to existing code in memory. However, in order to do that the attacker needs to know the address of that code. Thus modern operating systems can place code at randomized addresses in memory.

ASLR was originally invented by the PaX project as a patch to the Linux kernel in 2001. The mainstream kernel got ASLR support in version 2.6.12, released in 2005. However, to properly randomize all of the code, the executable files need to be compiled as position-independent executables using the -pie compiler flag. For a long time, most Linux distributions didn't use position-independent executables by default. Fedora started switching on -pie by default in version 23, released in 2015. Both Debian and Ubuntu still enable -pie only for selected packages. [Update: As pointed out in the comments, Ubuntu 16.10 does enable -pie by default for several architectures, including amd64.] However, recently there have been some efforts to push enabling the flag by default in Debian. Recent GCC versions will make the transition to position-independent executables easier. Since version 6, GCC's configure script has an option --enable-default-pie that allows changing the compiler's default. While this is welcome news, ASLR is no panacea: Evans was able to write multiple exploits ([1], [2]) for GStreamer bugs that work even on Fedora systems with ASLR enabled.

More advanced exploit mitigations are currently being discussed under the umbrella term of "control-flow integrity". Modern versions of the clang compiler support such features, but they haven't been widely adopted.

Has Linux desktop security rotted?

Evans had some unpleasant thoughts for the Linux community:

The free-software community is often proud that switching to a Linux desktop is an almost surefire way to avoid many of the security issues that plague users of the Windows operating system. Malware for Linux desktops practically doesn't exist. However a lot of that added security may simply be attributable to the fact that fewer people use Linux and thus it is a less attractive target for malware authors. If the Linux desktop wants to stay a secure choice for users it needs to strengthen its security. Bug finding techniques, safer programming languages, sandboxes, and additional exploit mitigation techniques can all play a role in this.

Comments (80 posted)

Development quotes of the week

Comments (6 posted)

Ardour 5.5 released

Comments (none posted)

WordPress 4.7

Comments (3 posted)

What’s New with Xen Project Hypervisor 4.8?

Comments (none posted)

Development newsletters

• What's cooking in git.git (December 6)
• This week in GTK+ (December 5)
• Koha Community Newsletter (November)
• OCaml Weekly News (December 6)
• Perl Weekly (December 5)
• PostgreSQL Weekly News (December 4)
• Python Weekly (December 1)
• Ruby Weekly (December 1)
• This Week in Rust (December 6)
• Wikimedia Tech News (December 5)

Comments (none posted)