Serious FLAC Security Bug

[Matthew]

Multiple Vulnerabilities In .FLAC File Format and Various Media Applications
Release Date:
November 15, 2007

Date Reported:
September 28, 2007

Patch Development Time (In Days): 48      

Severity:
High (Remote Code Execution)

Vendor:
Multiple Vendors

Systems Affected:
Applications with FLAC Support

Overview:
eEye Digital Security has discovered 14 vulnerabilities in the processing of FLAC (Free-Lossless Audio Codec) files affecting various applications. Processing a malicious FLAC file within a vulnerable application could result in the execution of arbitrary code at the privileges of the application or the current user (depending on OS).

Technical Details:
The vulnerabilities in the .FLAC format are due to improperly handling metadata values from malformed files. The file format is available here: http://flac.sourceforge.net/format.html.

(Vulnerabilities 1-14)

LMCE generates its own FLAC files (eg by ripping CDs when FLAC is the specified archive format), so the risk to LMCE is minimal, unless users import FLACs generated by a malicious party. However, leaving a vulnerable executable in the system is still a known risk of unknown probability, which is an unnecessary risk.

This vulnerability report also raises the qustion of how LMCE handles the discovery of bugs like this, and how the development project responds to it. Kubuntu's APT system lets its dependency on Ubuntu automatically upgrade to security fix releases. Are we sure that all LMCE components are in that system? How do we respond to ones that are not?

[danielk]

This is not a significant security risk for LinuxMCE. But to answer your general questions..

Right now any security updates need to have LinuxMCE replacement packages built. You can see how this mechanism works by looking at the ubuntu directory in trunk. In the future, I would like to see LinuxMCE move to using the ubuntu update mechanism instead. This involves us mirroring all the ubuntu packages on linuxmce.org and mirrors. Which really means we need to find more mirroring hosts, which is something I've been looking into. Luckily this is something we can switch over to after the 0710 release fairly easily using the LinuxMCE update mechanism.

[Matthew]

This is not a significant security risk for LinuxMCE. But to answer your general questions..

Right now any security updates need to have LinuxMCE replacement packages built. You can see how this mechanism works by looking at the ubuntu directory in trunk. In the future, I would like to see LinuxMCE move to using the ubuntu update mechanism instead. This involves us mirroring all the ubuntu packages on linuxmce.org and mirrors. Which really means we need to find more mirroring hosts, which is something I've been looking into. Luckily this is something we can switch over to after the 0710 release fairly easily using the LinuxMCE update mechanism.

Why do LMCE repos need to host the packages that the Ubuntu project is not only hosting, but also patching, with their larger, more focused staff? Why does a LMCE repo need to host any package other than LMCE-specific ones? The LMCE sources.list file can point at both the Ubuntu and LMCE repos.

[danielk]

<i>Why do LMCE repos need to host the packages that the Ubuntu project is not only hosting, but also patching, with their larger, more focused staff? Why does a LMCE repo need to host any package other than LMCE-specific ones? The LMCE sources.list file can point at both the Ubuntu and LMCE repos.</i>

Say L-1.0 depends on U-1.0, and X depends on U-1.0 as of Nov 21st, 2007
Say the L-1.0 package is installed when LMCE is installed and is a major component of LMCE.

Now on Nov 22nd, someone tries to install X after setting up an Ubuntu source in the sources.list, but X now depends on U-2.0 and won't install without it. Since L-1.0 depends on U-1.0, it won't be installed. Or worse, the user might try to force the installation of X and break L-1.0. (The proper thing for the user to do would be to install an older version of X, but manually satisfying package dependencies quickly gets tiresome.)

By keeping our own mirror of the Ubuntu packages we can make sure that X won't be upgraded to the version requiring U-2.0, until L-2.0 which can use U-2.0 has been compiled and tested. We don't need to touch the Ubuntu packages themselves, just update the LMCE packages in concert with the Ubuntu package changes so that package dependencies can be satisfied.

[Matthew]

But the Ubuntu repositories don't get upgraded in a way that breaks those kinds of dependencies. The entire point of Ubuntu's named releases, like feisty and gutsy, is that they release new versions that could break dependencies (eg. new UI, API, or file formats) only in the new release, which doesn't remove the old versions. The point  of APT is that the dependencies are automatically sorted when a version is upgraded. If package X depends on versioned  package Y.n, package Y.n will still be available, even when a package Y.o is newly available. The entire point of Ubuntu's whole project is to release every six months, and to maintain each release for several years.

Maybe I'm misunderstanding the problem you're describing, but it seems to me that Ubuntu's whole release, package and dependency scheme directly addresses the problem. That might not be true for other LMCE components that aren't part of the Ubuntu distro (and therefore hosted outside of its repos), but Ubuntu should be safe.