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."
Perform them.
proud caffeine whore
Yes. Windows.
It's like a zip/bzip/gzip file, once uncompressed, it's binary equal.
"Knowledge is the only instrument of production that is not subject to diminishing returns" -Journal of Political Econom
It's kind of like running winzip on your wav files. All the data is there, but it fits in a smaller space. Of course, they don't use winzip's compression algorithms because that's really bad at compressing audio. They have special algorithms that are much better at recognizing patterns in wav files. I'm not completely sure how it works, but that's my understanding of it, and the easiest I can explain it.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
This is an example of the term "failure of imagination."
.flac file which can execute arbitrary code when it is run on an affected player.
.flac file to someone else who doesn't know it is maliciously crafted and when they play the file, they have given arbitrary code execution privileges to the malicious crafty person.
Someone malicious can craft a
That someone can give that
I thought everyone got that from the description, but there will always be some ignorant fool who can't help but speak up and, here's the great part, there will always be someone who is even more stupid who mods them up.
That's the magic of Slashdot.
How we know is more important than what we know.
If you rip a Audio CD to MP3,AAC,WMA or OGG that is lossy compression. There is no way of getting the original data back. If you compress it with FLAC, you can get the exact bits present on the original Audio CD. Note that we are talking about only digital conversions. How the CD was mastered from the analog source is a complete different matter and has nothing to do with FLAC.
This space for rent.
Not that I like feeding trolls, but wake up, no one here think's FLOSS == perfect security, that's why both my Ubuntu and Fedora machine get software updates on a regular basis. The primary difference between FLOSS and proprietary security is transparency: do you know how many ten year old bugs are sitting in Windows or IE which Microsoft refuses to fix? Unless you work for them, you likely don't have a clue.
"Knowledge is the only instrument of production that is not subject to diminishing returns" -Journal of Political Econom
Secondly... this isn't supposed to happen with FOSS Actually exactly this IS supposed to happen with FOSS.
Where this is
Visit CryptoGnome in his home.
If you're using Ubuntu, the latest security updates should have fixed this already (for a few days, I believe). The Ubuntu security team has USN-540-1 as a notification. It looks like it's an issue in Ubuntu 6.06 LTS, Ubuntu 6.10, Ubuntu 7.04, and Ubuntu 7.10 (at least), and their respective Kubuntu/Edubuntu/Xubuntu releases.
All you really need to update looks to be libflac7 or libflac8, whichever exists on your system (8 is only for Gutsy, aka 7.10), though it's probably a good idea to update all the security updates anyway.
Good thing no one uses this esoteric "FLAC" format.
No. Vista.
And no you will not get one of them "You want to proceed with blah?" windows because an exploit will not have a manifest. It is difficult to get Vista hosed by malware compared to XP.
Lots of people screw up the sanity checks. C has some interesting properties that people struggle with: signed+unsigned promotes to unsigned, and the compiler is allowed to generate code which assumes that signed wrap-around will never happen. Plus people just plain screw up. I'll bet the FLAC code even had sanity checks, just not correct ones.
Sanity checks are also low-performance.
Suppose you want a 1 MB buffer. Allocate that, plus 2 pages, plus another page if your allocator doesn't give you page alignment. (mmap does, malloc does not -- you should use mmap to be 100% legit here) Round up to a page if you used malloc. Make that page unreadable via the mprotect call. The next page will start your 1 MB buffer. After the end of that buffer is one more page that you also make unreadable. Now you're safe from regular overflows in that buffer.
You still risk jumping out of the buffer when you add a potentially big offset. Here, you use the mask. Take an offset into the buffer, add/subtract the untrusted data, mask with 0xfffff for 1 MB, and now you have a fresh new offset that will be within the buffer.
Regular overflows will hit the unreadable page. If you do nothing extra, the result is a safe crash. You might use the fork call to create a child process that you don't mind losing. Alternately, you can use sigsetjmp and siglongjmp to handle the situation. Set up a signal handler for signal 11 that will call siglongjmp. Call sigsetjmp prior to entering the code which handles untrusted data. If the code takes the exception path (signal and siglongjmp), then you know the untrusted data was bad. (for extra points, verify that the guard page was hit and call _exit if not -- see the sigaction documentation for how to get this info)
You misunderstood. Where FLOSS differs from microsoft is:
a)This bug was discovered by third parties because they had access to the source
b)The bug is already fixed
c)Even on still vulnerable systems it wouldn't give you root access
d)It would have to rely on special plugins or user action
e)The problem is clearly described and documented allowing users to take precautions
Compare this to a vaguely described bug in your rendering engine for animated cursors enabling arbitrary webpages to compromise kernel space, and this not being fixed for days or even weeks despite documented exploits in the wild.
Somehow I don't see the irony.
or play a video with flac as the audio algorithm.
right.
especially if it plays silence on a transparent pixel.
MAN THIS SUCKS.
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.
Subscription to Stereophile magazine: $10.
Additional hard drive to store your lossless music collection: $200.
Portable audio player that supports FLAC: $300.
High-end headphones and speakers necessary to hear the difference between MP3/AAC and FLAC: $1000.
Gold shielded power, speaker, and headphone cables to avoid picking up noise that masks the differences between MP3/AAC and FLAC: $2000.
Watching all that equipment turn into one big zombie spambot as soon as you press "play": priceless.
Visual IRC: Fast. Powerful. Free.
What you just described is a virus, and in fact, has existed nearly as long as computers have. If you don't trust your flac-giving buddy, why take anything he gives you at all? The point is that "flac" cannot compromise your system, only your data. Unless you play the file as root.
I want to delete my account but Slashdot doesn't allow it.
A sincere Thank You for your efforts, identifying the issue and alerting the Devs, and correcting the problem.
This is the way things were meant to work, as so eloquently put elsewhere.
It's well-known that people tend to botch sanity checking. Thus, we should seek alternatives.
My solution is far less complicated in total. Yeah, setting up a guard page isn't taught in Programming for Dummies. It's not a lot of code though, it's easy to test, and it's damn reliable.
People who write secure code try to avoid having to trust themselves to get everything right. People who write insecure code think that somehow, despite decades of failure, they'll get it all right. Look ma, no bugs! Sure...
That code gets injected into your xterm, gnome-terminal, konsole, eterm, screen, emacs, etc.
You'd better not ever do "su" or "sudo" from a shell in any of them. You wouldn't do that, would you?
Do you know what an "input method" is? It's a lovely way to play with your keystrokes, no matter what the app. It's normally used to enter things like Chinese characters... and to pwn you.
BTW, getting into your account is one step closer. Now the attacker is not only inside your firewall, but able to attack setuid binaries and the kernel itself. Any bugs just got exposed. At this point, a local exploit is as good as a remote exploit.
Not that any of this matters. A typical attacker wants your private data, your IP address, and your network bandwidth. Maybe they want your disk space too. Really, they don't need root. That's just for bragging rights.
OK, this is Slashdot. Nobody here here has a wife let alone a mistress
You are right about the backups, though...
-Arthur
Cave ne ante ullas catapultas ambules
This little trick would change whatever apps you use that is launched from your shell session, which is just unlikely.
But wait, there's more
This was fixed like more than 4 years ago !! Your LD_PRELOAD, containing slashes, will just not work at all and be rejected for suid binaries like su or sudo.
And if you don't put slashes, the library will be searched in the trusted paths put in your ld.so.conf.
So sorry to destroy your scary FUD. Not to say a rootkit is not possible, but it requires more than a vulnerability fixed years ago. Do you know what an "input method" is? It's a lovely way to play with your keystrokes, no matter what the app. It's normally used to enter things like Chinese characters... and to pwn you. Except this is not launched from a bash session... at all. This is launched by your desktop environment, itself launched from a desktop manager, itself suid and not launched from your bash session. Just wow at your failed pwn methods though! BTW, getting into your account is one step closer. Now the attacker is not only inside your firewall, but able to attack setuid binaries and the kernel itself. Just no, you're plain wrong. Kernel is safe as long as you're not root, and setuid binaries are safe too. You have to have an exploit on one of them, and no, LD_PRELOAD is not one. Any bugs just got exposed. At this point, a local exploit is as good as a remote exploit. Well, I kind of agree, though it's not as simple as you make it out.