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? Brian
Brian Willoughby wrote:> 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?I think you are underestimating what a motivated cracker can do starting with a simple heap overflow. See: http://en.wikipedia.org/wiki/Heap_overflow Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
On Wed, Nov 26, 2014 at 01:40:13AM -0800, Erik de Castro Lopo wrote:> Brian Willoughby wrote: > > > 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? > > I think you are underestimating what a motivated cracker can do starting > with a simple heap overflow. See:In this case the minimum amount of data that the attacker can write to the buffer seems to be nearly 16GB (4 * (INT_MAX - 31)), so I think most libFLAC applications will just crash. But I could very well be missing something. -- Miroslav Lichvar
On Nov 26, 2014, at 1:40 AM, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote:> > Brian Willoughby wrote: > >> 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? > > I think you are underestimating what a motivated cracker can do starting > with a simple heap overflow. See: > > http://en.wikipedia.org/wiki/Heap_overflow > > ErikMy point was specifically about embedded FLAC running on a device like a player. I should have pointed out that I meant that there is no Linux or other operating system, there is no 'root' account, and there are no other programs running. The only data structures that exist besides the playback engine would be the FAT file system for external storage of recordings. Besides pure maliciousness, a hacker has nothing to gain by creating a bad FLAC that will cause a player to crash. Brian