An organization called "eEyes Digital Security Research" has issued an advisory for 14 vulnerabilities found in the .FLAC file format.

More details here and here.

ok，goto see

Issues were resolved in Flac 1.2.1. Non-story for people who upgrade.

As I understand it, that's not completely true. If you're using a media player that uses, say, 1.1.2 to decode your files, then you're still at risk. Since 1.2.1 was only released Sept 17, it is quite possible that 1.) your media player hasn't incorporated 1.2.1 yet and/or 2.) your media player only has 1.2.1 in the development trunk and has not yet released it to the public.

Also, many people aren't Gentoo users living on the bleeding edge; I haven't installed new versions of Quod Libet or VLC in over six months. So the story is probably quite relevant to most users (I think my upgrade habits are probably somewhat representative).

Okay, so what happens if you are using a player which decodes using FLAC 1.2.1, but the files you are trying to play were encoded using FLAC 1.1.4?

Does it mean that your system is still compromised? If yes, then this might be a very good reason to transcode all my FLAC 1.1.4 files to 1.2.1.

Since it's security issues we're talking about, I'm sure distributions will be quick to upgrade.

Afaik, only libFLAC (the decoding library) < v1.2.1 had this security issues, so FLAC files, regardless which version, don't have any problems.

I wonder if anyone has actually encountered a crafted FLAC file which tries to exploit the found vulnerabilities.

What actually can happen in the worst case? Is there a simple way to determine if a FLAC file contains malicious code?

Some sites provide legal downloads in FLAC format. Is it technically possible that a virus like code could alter FLAC files on the provider's side?

If I have understood correctly the found vulnerabilities are related to the metadata storing system.

I searched for similar issues with Vorbis and found this page:

"libvorbis: Multiple vulnerabilities"

http://www.gentoo.org/security/en/glsa/glsa-200710-03.xml

The FLAC vulnerability is related to the code to read the metadata (meaning things like stream info in addition to vorbis comments). It is not an inherent flaw in the format, only in the decoding library.

It has been fixed in FLAC CVS since early September.

Thanks for notifying, I missed this probably because it was not given much attention compared to all other security vulnerabilities.
A good reason to move to foobar2000 0.9.5 (beta) just beware that the user interface has been changed.

it just occurred to me that it would be pretty simple to make a scanner to check FLAC files for most if not all of the vulnerabilities. basically just parse the vorbis comment looking for any length field of 0xffffffff and chances are it's got a payload. I probably will do something like that.

My questions remain unanswered. The linked documents and the replies here fail to explain the real risk.

Are there any known cases? What can happen? Which programs are affected - players, converters, taggers? How about hardware devices? Can a virus like program alter FLAC files secretly? Can maliciously formatted FLAC files do something secretly? Do the same vulnerabilities exist on all operating systems? Etc...

It's a heap overflow issue. Exploiting it depends on layout of the application in memory, timing, and behaviour of malloc(). Exploitation is extremely unlikely, and the payload would have to be specific to one application. Smaller tools with predictable memory allocation behaviour like the commandline FLAC tools are far more vulnerable than large chaotic applications like Winamp or FB2K.

I feel pretty safe with the old 1.1.1 or 1.1.2 decoders. Nobody will go through all the hassle to craft these specific vorbis tags when it's far more easier to distribute viruses using Outhouse Express or simply executables with fake names.

There was a major vulnerability with winamp loading crafted M3U's or something like that a while ago. Did the world came to an end? My Opera is still loading all m3u's as text for the only purpose of getting the actual URL of the streaming broadcaster.

Thanks, benski.

That explains it a bit more. However, it is still a programmer's answer, which goes way over the most FLAC users' heads. I am not a programmer, but I have used AV programs for years in my work and before asking anything I kind of guessed that the problem is mainly theoretical and it would be unlikely to encounter it in real life.

However, I would like to be able to give a fact-based understandable answer if my client asks about the rumored security vulnerabilities of the FLAC format.

I'm no expert, but here goes.

First off: http://en.wikipedia.org/wiki/Heap_overflow

OK. Computers deal with data, and instructions. The difference between the two are somewhat arbitrary, since instructions come from data.

Normally, the computer keeps track of the difference. But if you can trick the computer into treating data as instructions, you can do things that you usually can't.

So if the tags of FLAC files contain mallicious bits, then the tag reading software can be exploited.

Was that close enough?

It's hard to understand without a good understanding of how machine code works.

Basically, a malicious FLAC file would have to be crafted to target a specific version of a specific program (even one extra plugin could throw it off). It would also (likely) have to play the file back immediately upon loading (this is why I say that commandline utils are more vulnerable). Many (if not most) programs would avoid the vulnerability due to dumb luck ; there might not be any interesting data to overwrite before you run into an unallocated page of memory. Writing to unallocated pages of memory results in a program crash (Access Violation) which puts a quick stop to the party.

Heap overflows (And stack buffer overflows) happen when a program lets you, as the saying goes, put 10 pounds in a 5 pound sack.