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."
Sanity checks: (Score:5, Insightful)
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)
Re: (Score:2, Flamebait)
None of what you just described counts as a "sanity check." It's more like putting an immensely complicated band-aid on the problem so that when things do explode they explode in a predictable way. This can be a good thing in certain fields. If failure of your software might cause somebody's death, then yes, you want complete assurance that things cannot silently go wrong. But failing that, this is nothing but a poor substitute for good coding practice.
If you have so much doubt in your own code, why do yo
the whole point: it's NOT sanity checking (Score:5, Insightful)
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...
Re:the whole point: it's NOT sanity checking (Score:5, Insightful)
Studies show that nearly everybody thinks he is a better-than-average driver.
Kind of the same problem, no? Maybe this is why we require safety equipment.
Re: (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: (Score:2, Insightful)
It's like wearing a seat belt because you have no control over what other drivers will do.
There, possibly the finest car related analogy on Slashdot ever.
Re: (Score:3, Insightful)
Aren't we prideful. Do you work for Microsoft or something? Everyone makes mistakes. In the real world, you should program in as many sanity checks as you can. Over compensating for potential problems will usually lead to more secure and stable programs, or at the very least make it fail in a less catastrophic way.
Expecting sanity checks to be done elsewhere and not covering your ass leads to absurdly buggy programs and security compromises, which is happening all too often in so called "professonal" soft
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.
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.
Re: (Score:3, Insightful)
sanity checks have to go at each point writing to the buffer.
Answer 1: Yeah, writing good software requires effort.
Answer 2: Centralize the code which accesses the buffer, and put sanity checks there. Then just call this code. I know this "structured programming" concept is pretty bleeding-edge stuff, being only 40 years or so old, but hey. Sometimes you just gotta learn something new.
Re: (Score:3, Interesting)
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.
Re:guard pages, bit masks, and so on: better (Score:5, Interesting)
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.
Re:A lot of these are app flaws, not flac flaws .. (Score:5, Interesting)
Its an example of a particular implementation becoming the standard. They might as well not even have a file format specification.
Re: (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: (Score:3, Interesting)
2. I hardly think libFLAC counts as an "essential Linux library".
root listens to audio? (Score:2, Funny)
Oh, you mean that a USER could compromise THEIR PERSONAL FILES... well, that does suck, but you have backups, right?
Re:root listens to audio? (Score:5, Informative)
Yes. Windows.
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.
Re: (Score:2, Funny)
We don' like yo' type 'roun' 'ere, yew best keep moving.
Man, I hope I got my punctuation of the accent correct, or I am going to get reamed by Grammar Nazi's.
OT Vista security (Score:3, Insightful)
Vista has some security improvements if Vista is used correctly, but MS still missed the boat in a big way.
The fundamental problem is people running under an admin account. Vista does not solve this basic problem.
When you install Vista (or run for the first time), it guides you through creating an account. If you actually read the dialog (hint: most people won't), it tells you that this first account is an admin account. The problem is that for most folks
Re: (Score:3)
Re: (Score:3)
More importantly, most Linux install programs guide the user through making both a root and regular user account as part of the install process.
That's where MS really dropped the ball. Their install wizard doesn't make sure that important step is taken care of.
When they are starting their computer for the first time, typical users just want to start using the system, so if you don't force them to create a regular user account, it's not going to happen.
The release of Vista provided MS with a golden oppo
Re:root listens to audio? (Score:5, Funny)
right.
especially if it plays silence on a transparent pixel.
MAN THIS SUCKS.
Re: (Score:2)
Re:root listens to audio? (Score:4, Funny)
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.
Re: (Score:3, Funny)
Re: (Score:2)
2. see my page on jumping su and sudo [insomnia.org].
I think you misunderstand the post (Score:2)
Please, instead of assuming that you have parsed other people's thoughts correctly and hastily call them ignorant fools, try to see it from their side. It adds nothing positive to a debate.
Re: (Score:2)
Someone getting the ability to run arbitrary code on your machine is a security issue..
Re: (Score:3, Funny)
Re: (Score:2)
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
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: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.
Re: (Score:3, Informative)
No it doesn't !!! At least as long as you don't launch any xterm from your gnome-terminal/konsole/eterm/whatever.
This little trick would change whatever apps you use that is launched from your shell session, which is just unlikely.
That's a very minor detail. First of all, I can just hit your desktop menu files instead. I can hit .xsessionrc or .xinitrc instead. Second of all, your desktop environment most likely USES THE SHELL to start things, and it is likely that at least some of the shell's files (not all) will still be used.
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.
No, I don't mean injecting into su or sudo. I mean injecting into the terminal program. As part of the push for security, the setuid bit has been removed from many of these programs... eliminating the LD_PRE
Re: (Score:3, Insightful)
I suppose I better expand on my "sudo is a waste of time" comment.
Sudo is generally configured out of the box to allow root access, making it little more than an alias for su. Actually configuring sudo to allow limited access to certain commands is fiddly, and often misses things (try running a root /bin/sh from sudo - works almost every time). Sudo is also a poor alternative to ACLs, or just setting up groups to control access to certain device files (which is often what a presumed need for sudo boils do
right, I have backups... (Score:2)
No problem?
Heck, the attacker will be making extra backups! For free!
Re: (Score:2)
Oh, you mean that a USER could compromise THEIR PERSONAL FILES... well, that does suck, but you have backups, right?
"That hacker stole all my steamy emails between me and my mistress and threatened to tell my wife unless I pay him $10,000! Thank God at least I have backups!"
Re:root listens to audio? (Score:5, Funny)
You are right about the backups, though...
Re: (Score:2)
Because, of course, privilege escalation bugs have never EVER cropped up.
But that's merely a technical argument in an area where psychology reigns supreme. And the moment you assume the attitude of "It's not worth giving a damn because careful users won't have issues", you already lost that game.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
If, on the other hand, your goal is to state what everybody already knows, but in off-putting terms, without any reasonable expectation of effecting change for the better, then consider yourself "mission accomplished." Keep up the good work!
Re: (Score:2)
Re: (Score:2)
you are an idiot, if you spend more time backing up your files than it took to get/replace them.
Actually in a purely economic sense,
TimeToBackup*chance of failure ~= time to recover without THIS backup.
of course you must add in the economics, but backups generally cost significantly less in actuall $ than in time.
this is why smaller organizations only backup securely (off site...) no more than monthly... If I only get one failure every 5 years, and it take
I bet someone will cop some flack for this.. (Score:2, Funny)
Old McDonald Had a Farm (Score:5, Funny)
Jailbreak!! (Score:3, Interesting)
Re: (Score:3, Informative)
Re: (Score:2)
Xiph.Org QuickTime Components [xiph.org]. Should do the trick.
HTH
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
If only Rockbox got half-decent battery life, it would be the perfect replacement for Apple's firmware
Erm, it's pretty half-decent right now. From an old commit message:
:-)"
"6 Aug 17:26 - Jens Arnold - firmware/target/arm/system-pp5002.c - Reduced battery consumption on PP5002 targets (iPod 1st/2nd gen and 3rd gen). Now rockbox battery runtime is better than OF, verified on 2nd gen
Even on targets where it's not quite so optimized, it's typically reasonably comparable.
The best thing about these vulnerabilities (Score:2, Funny)
losslessly compressed (Score:2)
"losslessly compressed" audio file format.
Can someone explain how this compares to the original recording?
And am I confusing the analog to digital information loss with the compression (loss) part?
Re: (Score:3, Informative)
Free Lossless Audio Codec (FLAC) is a file format for audio data compression. Being a lossless compression format, FLAC does not remove information from the audio stream, as lossy compression formats such as MP3, AAC, and Vorbis do. Like other methods of compression, FLAC's main advantage is the reduction of bandwidth or storage requirements, but without sacrificing the integrity of the audio source. For example, a digital recording (such as a CD) encoded to FLAC can be decompressed into an identical copy of the audio data. Audio sources encoded to FLAC are typically reduced in size 40 to 50 percent. (53% according to their own comparison)
It's like a zip/bzip/gzip file, once uncompressed, it's binary equal.
Re:losslessly compressed (Score:5, Informative)
Re: (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: (Score:2)
Re:losslessly compressed (Score:5, Informative)
Re: (Score:2)
http://en.wikipedia.org/wiki/Lossless_data_compression [wikipedia.org]
Re: (Score:2)
A simple way to get an intuitive understanding of why lossless audio compression is possible is to display an audio waveform at a resolution high enough that you can see individual samples. You will notice that adjacent samples are close to each other - the signal doesn't change very rapidly. That's due to the physical nature of music and speech and it is a way in which such signals differ from arbitrary signals. If you display white noise, for example, it won't have this property - samples not very far ap
Re: (Score:2)
Lossless compression works by identifying common features of a particular type
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.
Phew (Score:5, Funny)
Those security tell me to get the FLAC out of here (Score:3, Funny)
libavcodec is not affected, Heise is wrong (Score:3, Informative)
Some things in life, money can't buy... (Score:5, Funny)
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.
Re: (Score:3, Insightful)
More like $100.
Portable audio player that supports FLAC: $300.
I don't mess with these. There are no portable players in production that meet my needs. The only one close are the iRivers with SPDIF, and the models I would be interested in are not in production any more.
High-end headphones and speakers necessary to hear the difference between MP3/AAC and FLAC: $1000.
I was able to hear a big difference on a pair of $69 headphones and $20 sound
Re: (Score:2)
Re: (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 car
Re: (Score:3, Interesting)
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-
Thank you eEye and Devs (Score:5, Insightful)
This is the way things were meant to work, as so eloquently put elsewhere.
In Files? (Score:2, Interesting)
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
Re: (Score:2, Troll)
Performant is not a word.
Efficient is a word.
Making up jargon to sound erudite actually makes you sound stupid.
Thank you and have a nice day.
--
BMO
Re: (Score:2)
Someone please MOD this comment -1 redundant
Re: (Score:2)
Awesome. I only make up jargon to sound baztastic.
Re: (Score:2)
Performant code for audio libraries. I love it!
Worst possible choice. (Score:2)
Try Haskell, Erlang, Common Lisp, Smalltalk, even Java.
I'm not incredibly worried, though -- most of my FLAC files are converted WAVs or CDs.
Re: (Score:2)
Its a chicken and the egg with languages like this. If they don't solve one task much better than a
Re:But I thought that this didn't happen with FOSS (Score:5, Insightful)
Re: (Score:2)
I disagree. There are certainly people here with that type of attitude. Whether they actually believe it or not, who knows. But the various degrees of "this would never happen if you were using free software" or "LOLOL download the patch, it's at www.ubuntu.com" are certainly prevalent.
BTW, that "how do you know Microsoft didn't do X or Y" is rarely productive - unless you have a habit of manually auditing every line of code that goes into your favorite Linux
Re: (Score:2, Insightful)
Re:But I thought that this didn't happen with FOSS (Score:5, Insightful)
Secondly...
Where this is
Re: (Score:2)
Re: (Score:2)
The assumption is that everyone -- or at least everyone stupid enough to program in C/C++, which is, really, everyone -- has some security bugs. The difference is, Microsoft may refuse to fix the bug, or refuse to acknowledge it's a bug (see Vista's performance issues), or even threaten to sue you i
Re:But I thought that this didn't happen with FOSS (Score:5, Insightful)
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.
Re: (Score:3, Interesting)
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
Re: (Score:2)
I'm sure you'll find the answers to these questions, as well as the make-up of the team, the changelog, access to CVS, and links to the development mailing list on the FLAC Project page [sourceforge.net]. If you weren't being facetious, that is.
The point behind FOSS - which you seem to have deliberately misconstrued - is openness, not perfection. While it can be argued that FOSS development proce
Re: (Score:2)
You make this sound like a once-in-a-lifetime oppertunity.
Re: (Score:3, Informative)
So this is really ironic - Its my understating from reading hundreds and hundreds of /. posts that this isn't supposed to happen with FOSS.
Then you misunderstood.
Who did the code reviews?
eEye Digital Security.
Who did the security reviews?
eEye Digital Security.
Who did all the threat modeling?
I'll give you three guesses.
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
Re: (Score:2)
How are you going to patch embedded devices that have hardware vulnerabilities?
What the hell does this argument have to do with Open Source? I'm sorry, was there some memo I missed that explains how embedded closed source software is easier to update than embedded open source software? You want a reasoned debate, how about we exclude the open/closed crap altogether, as it is totally irrelevant?
Having said that, I agree. The "many eyes shallow bugs" argument is absurd. It's like going to a country whe
Re: (Score:2)
Idiot.
Re: (Score:2, Insightful)
Re: (Score:3, Insightful)
Buggy software is a fact of life for the most part - it is created by humans and we all make mistakes.
When is the last time you were driving and the road just COLLAPSED? The bridge fell down? Your car spontaneously burst into flames? When's the last time you plugged an electrical appliance into a wall and got shocked? Last time your plasma television went nuts and shot laser beams at your cat? When's the last time the case of your box fan failed and the blades went flying through the air, decapitating y
Re: (Score:3, Interesting)
When was the last time you saw a bridge standing up after a willfull, informed, and competent attempt to put it down?
Freedom is valuable in its own right. (Score:3, Insightful)
Re: (Score:3, Insightful)
There might be buffer overflow bugs in the FLAC reference software, but I don't think that the bugs are there by design.
(I agree that tags like "Micro$oft" probably aren't the most grown-up thing to post, but what would