Slashdot Mirror
Multiple FLAC Vulnerabilities Affect Every OS
Enon writes "eEye Digital Security has discovered 14 vulnerabilities in the FLAC file format that affect a huge range of media players on every supported operating system (Windows, Mac OS, Linux, Unix, BSD, Solaris, and even some hardware players are vulnerable). Heise points out a number of vulnerable apps that use the open source libavcodec audio codec library, which in turn relies on the flawed libFLAC library. These vulnerabilities could allow a person of ill will to trojanize FLAC files that could compromise your computer if they are played on a vulnerable media player. eEye worked with US-CERT to notify vulnerable vendors."
It's time that we start writing libraries like these in OCaml. Audio processing libraries, for instance, need to be quite performant. So C has typically been used. But now we run into problems like this, where the insecurity of C becomes a serious issue.
The solution is likely the use of OCaml. With OCaml, we get a native code compiler that generates very performant code. But best of all, we get a far greater degree of safety. OCaml efficient memory management takes care of the dangerous C memory management that leads to vulnerabilities like these found with FLAC.
Possibly another way to jailbreak your iPhone or install Linux on your iPod.
If that really is your understanding, then you could benefit from either spending a bit of time improving your comprehension skills, or paying less attention to the trolls.
The difference between the development models and philosophies usually becomes apparent when the flaws are discovered. How long will it take for the libFLAC flaws to be fixed? How does this compare to closed-source applications with similar flaws? How long will it take for companies using libFLAC within their proprietary players take to incorporate the fixes and release them to their customers?
Many closed-source companies sit on vulnerabilities until they're publically reported, and even then take their sweet time addressing them. The time between discovery of problems and fixes being available is generally pretty good in open source projects. Microsoft is no exception to this <troll>although they do respond remarkably quickly when flaws in their DRM measures are discovered</troll>.
One interesting issue this raises though is the number of programs and devices which are affected. If libFLAC wasn't available for everyone to use, then we'd likely have multiple implementations of it and a flaw in libFLAC wouldn't affect so many devices. For example, if the Fraunhoffer decoder had similar problems, it wouldn't effect most mp3 players because there's so many different decoder implementations. So even though libFLAC being open source does make it technically easier to produce a competing implementation, it also reduces the incentive to do so. So does open source potentially contribute to creating a software monoculture?
Also some nitpicking of the article summary:
eEye Digital Security has discovered 14 vulnerabilities in the FLAC file formatHow can a file format have vulnerabilities? Surely the vulnerability exists in code that reads and interprets the bytestream, not in the format itself.
The big thing is reliability. You have less to screw up.
But yes, it is faster.
The guard pages are essentially free. They have a minor one-time start-up cost, like doing a memory allocation. As long as you keep reusing that buffer, you don't have any extra overhead.
Bit masking is a very cheap math operation. It does not need to involve the branch predictor. There is no "else" code to bloat things up and even contain more bugs; the mask simply forces the data to be good. (well, "good" as in "good enough for security" -- it won't turn an attempted buffer overflow exploit into beautiful music!)
BTW, some Linux kernels also provide a "seccomp" mechanism. It's a severe sandbox, limiting you to about 4 system calls. If you can make your code tolerate that, remembering to close any unneeded file descriptors before you switch it on, you'll be damn secure.
it's a bunch of bugs in the libFLAC that is used in a heck of a lot of apps.
Its an example of a particular implementation becoming the standard. They might as well not even have a file format specification.
How we know is more important than what we know.
The summary inherited the lousy description in the title of the article.
I see nothing to indicate that these vulnerabilities are in FLAC files. They seem to be in the reference implementation of the decoder. An exploit would be in FLAC files.
Come on, guys! You're running a Geek website here!
-Peter
I am not myself an audiophile (though I do exhibit some audiophile tendencies); I thought the idea behind using gold-plated connectors was not that they sounded better, but because they stayed sounding the same for longer due to not corroding?
Aikon-
A brief overview of the linked page leads me to the impression that there aren't even any vulnerabilities found or mentioned, it's just speculated that it's conceivable that implementations of a file format may be overflowable because the file format has, gasp, a length field. Lame. (no pun)
Evidently, the key to understanding recursion is to begin by understanding recursion. The rest is easy.
1. Linux security has been going down since about 2001 (who doesn't have a personal kernel exploit they haven't told Linus?)
2. I hardly think libFLAC counts as an "essential Linux library".
How we know is more important than what we know.
When was the last time you saw a bridge standing up after a willfull, informed, and competent attempt to put it down?
Rethinking email
No!
1. It is trivial to crack a CRC. That is not a crypto checksum.
2. Probably you get exploited before you get a chance to check. This depends on overflow severity, OS, etc.
There is a fix. You mask everything, not just when adding arbitrary untrusted offsets. This sucks.