[flac-dev] Two new CVEs against FLAC

Brian Willoughby brianw at audiobanshee.com
Wed Nov 26 00:08:20 PST 2014

On Nov 25, 2014, at 8:27 AM, Declan Kelly <flac-dev at groov.ie> wrote:
> On Tue, Nov 25, 2014 at 12:29:33AM -0800, mle+la at mega-nerd.com wrote:
>>    CVE-2014-9028 : Heap buffer write overflow
>>    CVE-2014-8962 : Heap buffer read overflow
> Is it known what other FLAC decoding software or firmware is vulnerable
> to these overflows?
> Any software player that was derived from the official FLAC codebase
> probably is, and most active 3rd party developers will probably get a
> new release out soon anyway, even if their code was not vulnerable.

My impression - which may be out of date - is that many software players embedded the FLAC command line within their GUI app, and then never updated. This was a serious pain when FLAC was actively changing, gaining significant new features, and yet the most popular GUI apps were left behind. Some people were even left with a bad impression of FLAC because they never tried the command line, and thus were stuck with the buggy old versions in their GUI.

You are correct that it is easier for a software player to be updated, but I have my doubts that any will be updated.

> Embedded systems with native FLAC playback, such as DVD players and
> portable devices, may never get updated.

You might be surprised. If the device allows for firmware updates in the field, then the manufacturer may update their device before your favorite Windows GUI FLAC player.

I have the Sound Devices 700 series field recorder that records directly to FLAC, and they've updated the firmware at least 6 or 7 times since I bought the device. I don't think more than one of the updates had anything to do with FLAC, but I don't feel worried that they're unable to correct a vulnerability.

Granted, consumer DVD players might not get a firmware update, but these days even car stereos have a way for users to get the latest updates. Players like the OPPO surely have firmware update capabilities, if needed.

While we're on the topic, what sort of consequences are there, really, with this vulnerability? Worst case, your player stops playing on a file that cannot be played anyway. Yes, it's bad that you have to power-cycle the player to get it to restart, but it's not like you can be doing anything else at the same time you're playing a bad FLAC. Have I missed something?


More information about the flac-dev mailing list