Multiple FLAC Vulnerabilities Affect Every OS 360
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."
Re:Jailbreak!! (Score:3, Informative)
Re:root listens to audio? (Score:5, Informative)
Yes. Windows.
Re:losslessly compressed (Score:3, Informative)
It's like a zip/bzip/gzip file, once uncompressed, it's binary equal.
Re:losslessly compressed (Score:5, Informative)
Re:losslessly compressed (Score:2, Informative)
FLAC and SHN (shorten) are basically fancy ways of "ziping" a file of audio. So, they are effectively the same thing as the original WAV (what is on the CD).
This of course leaves out any discussion on digital v. analog audio quality, but that is beside the point.
Yes, I over-over-simplified. But it gets the point across.
Re:losslessly compressed (Score:5, Informative)
Fixed in Ubuntu (Score:3, Informative)
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.
Re:root listens to audio? (Score:5, Informative)
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.
guard pages, bit masks, and so on: better (Score:5, Informative)
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)
Fuck no, get a clue (Score:1, Informative)
These are not problems with the FLAC file format. These are problems with libFLAC, the reference implementation, and potentially others that copied code from it. You can't have stack overflows in a file format, that doesn't even make sense.
libavcodec is not affected, Heise is wrong (Score:3, Informative)
don't need root for a rootkit (Score:3, Informative)
echo "export LD_PRELOAD=/home/you/rootkit.so" >>
From there, all your processes contain rootkit.so as a library. It can replace functions in the C library. Your editor won't open /home/you/.bashrc when you ask it to; it will instead open a different file.
You're so pwn3d.
You'd be safe if you had Bitfrost, like the OLPC XO does. There, apps don't get to mess with your files except when you actively hand the file over.
Re:But I thought that this didn't happen with FOSS (Score:3, Informative)
The security impact of open source software is not that it has less bugs, but that they get found because people can analyze the source. Read this article and you'll see that's exactly what happened. It's good news.
You will have bugs in your software, and they will be found. The difference is are they found by 'good guys' that will warn you and help you fix it or are they found by 'bad guys' that root your system?
Re:Some things in life, money can't buy... (Score:3, Informative)
5th gen (or any other) iPods have crappy DACs and poor amps. FLAC support is irrelevant for them.
Also USB sound cards are $40 and usually don't sound better than the cards bundled with most laptops, while also being slower than onboard chips.
USB sound cards that cost $40 don't sound better than the laptop sound cards because they have the same crappy amps and DACs as the laptop sound card. Get a $250 USB sound card like the iBasso D1 or Meier Move that are designed to drive high quality headphones and you are in a whole 'nuther league.
Finally, $200 will get you 750GB, which is adequate for music, assuming, of course, that you are storing lossless.
$100 for a 500 GB drive lets you store about 2000 CD's ripped to FLACs. That is pretty adequate and I think would satisfy most people.
Open your mind and your ears. The world of high fidelity is easy to experience. You won't want to go back to iPods, low bit rate MP3s and earbuds - I assure you.
Re:don't need root for a rootkit (Score:5, Informative)
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.
Re:A lot of these are app flaws, not flac flaws .. (Score:3, Informative)
The code [sourceforge.net] has been fixed. Yes, there really were security bugs in the libFLAC library. Shocking isn't it? Software had bugs in it! People found those bugs! People fixed those bugs!
Re:guard pages, bit masks, and so on: better (Score:5, Informative)
I didn't say you claimed sanity checks weren't needed at all. I said this guy's proposal was a valid thing to add to a program and anything to make sure your program doesn't die by covering multiple bases is a good thing. You do realize all programmers make mistakes, don't you? Good programmers try to minimize the effects of those mistakes.
Was he really saying to do that instead of sanity checks? I didn't see anywhere in his post where he explicitly said to do the "guard page" trick and not ever do any other sanity checks. The way he started off by saying how people get sanity checks wrong, it seems to me he was saying you should do that in addition to normal sanity checks, so if you really screw them up, you will still have some protection... Then again, maybe he was just trying to offer a more simple and efficient solution for those who can't get it right or are worried about wasting CPU cycles.
At any rate, the "guard page" trick coupled with the bitmasking certainly looks like it would be difficult or impossible to write outside the buffer, unless there is some sort of exploit I didn't see. Unlikely since I am quite familiar with assembly language and binary operations. It looked easy and foolproof to me--assuming no one makes a typo or other mistake, but other sanity checks are just as vulnerable to those problems. Just read the strlcpy paper written by Todd C. Miller and Theo De Raadt. Here is a relevant excerpt:
It is difficult to write functions which prevent security flaws. The trick r00t proposed sounds as good as any. You may not catch many bugs with binary masking, but then that is what a debugger and assert() are for.
Your comments about it being "complicated" and a "complex plan" suggest to me you know nothing about boolean algebra or low level programming. Maybe you should learn a bit more before you write inflammatory comments.
Re:the whole point: it's NOT sanity checking (Score:3, Informative)
When only a minority of people is responsible for traffic accidents, the majority is indeed better than average.
'nearly everybody' may be completely right about being a better than average driver...
Re:don't need root for a rootkit (Score:5, Informative)
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.
Many distros/OSs still using FLAC 1.1.2 (Score:1, Informative)
Another annoyance I noticed today is the FreeBSD maintainer is porting fixes from 1.2.1 to 1.1.2 rather than updating the port from 1.1.2 to 1.2.1.
Here's a list of distros and *BSD OSs and the available FLAC package for each:
gentoo 1.2.1
archlinux 1.2.1
opensuse 1.2.1
fedora 1.2.1
debian-testing 1.2.1
debian-unstable 1.2.1
ubuntu 1.1.4
pkgsrc (netbsd, dragonflybsd..) 1.1.3
debian-stable 1.1.2
slackware 1.1.2
openbsd 1.1.2
freebsd 1.1.2
Re:don't need root for a rootkit (Score:3, Informative)
This little trick would change whatever apps you use that is launched from your shell session, which is just unlikely.
In any case, with control of your menu system, I can substitute a look-alike program of my own design. That could be the terminal program. It could just be su or sudo. Heck, I could probably get away with making them mere shell functions.
sanity checks can be exploitable (Score:3, Informative)
I'd not suggest that ALL sanity checks need to go, but... cutting down the complexity of your code is certainly not a bad idea.
For example, if your sanity check code causes a double free, it may be exploitable on MacOS. (shame on Apple)
As a general rule, the more code the more danger.