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
How often does root listen to audio, esp. considering the new and improved root-like access Ubuntu and Fedora have set up?
Oh, you mean that a USER could compromise THEIR PERSONAL FILES... well, that does suck, but you have backups, right?
I want to delete my account but Slashdot doesn't allow it.
HAW HAW HAW.
How we know is more important than what we know.
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.
Is that they're still lossless.
Maybe I don't fully understand compression theory and this may very well be off topic, but this doesn't sound possible:
"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?
) Human Kind Vs Human Creation
) It'd be interesting to see how many humans would survive to serve us.
Whatever you take out of it is exactly as you put it. Flac is just optimized more for audio then zip.
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
This isn't possible.. for an arbitrary input - but we're not dealing with arbitrary inputs - we're dealing with inputs that are, in many ways, very similar - music.
How we know is more important than what we know.
Comment removed based on user account deletion
He works for them, check his webpage.
The difference between this and a closed-source product is that now that the holes have been discovered, anybody can fix them. It's not going to be me, however, as I am far too lazy.
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.
Why don't they switch to something more secure, like an open-source alternati- ...oh. Right.
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 distro.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
Or his comment where he said he was a Microsoft Developer, either/or.
Good thing no one uses this esoteric "FLAC" format.
Well, except C.
Try Haskell, Erlang, Common Lisp, Smalltalk, even Java.
I'm not incredibly worried, though -- most of my FLAC files are converted WAVs or CDs.
Don't thank God, thank a doctor!
> Not that I like feeding trolls...
His "criticisms" were light, if existent. If he's a troll, what does that make the hundreds of "Free software" promoters who bash Microsoft at every turn?
It's fine to have your favorites, but you don't need to play into the double standard.
This author takes full ownership and responsibility for the unpopular opinions outlined above.
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)
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 if you disclose the bug (not sure on the last bit, but you never know). With FOSS, worst-case, you can fix it yourself, or hire someone else to fix it.
This means that there are likely to be fewer bugs that get ignored for months or years. With Ubuntu, there's a chance a quick fix will be in my apt-get the next day, and a permanent fix in a week or two.
That's a non-feature. It's great for a company to have a CYA on this -- cover-your-ass -- but it's really useless if your goal is creating good software. All it's really useful for is so you don't get fired, because you can blame someone else's shipping/tests/reviews/modeling.
Don't thank God, thank a doctor!
The fact you are an MS developer pretty much explains why you are that stupid.
The phrase "more better" is acceptable English. suck it grammar Nazis
of my private keys, finance data, NDA-protected stuff, etc.
No problem?
Heck, the attacker will be making extra backups! For free!
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.
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.
I thought they were just being rude. Now I know why.
These posts express my own personal views, not those of my employer
Come on you retards with mod points, here's a guy making a completely non-sense statement on Slashdot. Mod him up! Geez, what's taking you so long?
Hmm.. maybe "ComputerPhreak" really is the stupidest person here.
How we know is more important than what we know.
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.
Vulnerability #3: VORBIS Comment String Size Length Stack Overflow
This is due to predetermined buffer sizes in applications when handling data in the VORBIS Comment Metadata block. By inserting an overly long VORBIS Comment data string along with an large VORBIS Comment data string size value (such as 0x000061A8 followed by 25,050 A's), applications that do not properly apply boundary checks will result in a stack-based buffer overflow. This is due to most applications reading data until they encounter a NULL byte.
This is nothing to do with flac - it's a buggy application. Ditto many others.
Nobody's perfect - mistakes happen, and holes are found, including within FOSS. The differences are:
* Any competent programmer can download the code, fix the hole and submit a patch
* We don't have to install spyware to get the update (if you ask me, unless you can demonstrate that installing WGA actually gives the user a "genuine advantage", it's false advertising)
* Anyone can review the patch if they wish to
* Running software as a user with default security settings isn't likely to hose a *nix/*BSD/OSX install
Yet despite this, the next Microsoft sponsored Windows vs Linux security comparison will no doubt list each of these vulnerabilities separately for each distribution, counting them as core code holes.
I also note that most FOSS devs aren't in the habit of making you wait 1-6 months for a fix...
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. 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 processes can bring software closer to perfection, only a fool (or Daniel Bernstein, but he's in a class by himself) labours under the illusion that bug-free software is attainable.
How software bugs get addressed, and how we make informed decisions about our exposure to security risks is what allows FOSS projects to really shine. FOSS doesn't make you safer necessarily, but it gives you the opportunity to evaluate how safe you are. In the hands of a healthy development community, this transparency does result in more secure software.
eEye has been able to do a thorough analysis of the FLAC format, and has found 14 vulnerabilities. To my knowledge, none of these vulnerabilities have yet been exploited on any scale. If - and I'll grant you that this is a big if - the FLAC team responds well and quickly to the security review, then we can expect to sleep better at night than we might using J. Random Company's binary blobs.
While we're on the subject, perhaps you could provide similar information about Microsoft's development projects? Mind if I take a peek at your CVS? Or would you rather I just take your word that your code is problem-free?
Crumb's Corollary: Never bring a knife to a bun fight.
libavcodec never ever used libFLAC, it has its own FLAC encoding & decoding code, hence not affected. Lousy journalism on Heise part.
Never learn by your mistakes, if you do you may never dare to try again
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.
undesired/unauthorized phone home
undesired/unauthorized upgrades, like the one you bastards forced on me DESPITE my having set XP updates to download **only** for later manual install
Digital Restriction Management -- need I say more? From the user's viewpoint, it's a bug.
sudden failure of the OS because some defective algorithm thinks Windows isn't "genuine"
Vulnerability #6: Picture Dimension Size Heap Overflow
By modifying the width and height values in the PICTURE Metadata block, a heap-based overflow could be achieved. When a vulnerable application that supports FLAC images attempts to render the excessively large image, the application allocates memory based on the dimension fields, which could be used to overwrite memory values and pointers with arbitrary values that could lead to code execution.
This isn't a libFLAC problem - it's the application which tries to ender the excessively large image.
Same goes for many of the other bugs. Application, not library.
From your post I suggest you are throwing a party tonight to celebrate this event?
You make this sound like a once-in-a-lifetime oppertunity.
If you mod this up, your slashdot background will turn into a beautiful sunset!
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.
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 where the national motto is: "Flurbistan: Who cares about the murder rate, we have a 100% conviction rate!" As if patching bugs quickly is somehow a consolation for people who have been compromised by them. Better idea: Don't release buggy shit in the first place.
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.
Audio codec's security FLACking
Idiot.
How we know is more important than what we know.
Word on the street is Apple's lawyers took a look at FLAC and decided it wasn't possible to support it without infringing on patents, so they made their own.
Software vulnerabilities crop up frequently, it's inherent in complex systems. The question comes to how users are treated and what freedoms they have to help one another and help themselves. With proprietary software, users must wait for the proprietor to supply a fix. All users of proprietary software are trapped in a monopoly. With free software users have the freedom to inspect, share, and modify the software at any time (or get someone else to do this work for them). Users don't have to wait to discover bugs or wait to get them fixed.
There are also related benefits when it comes to adding features users want and keeping prices low through competition and doing favors for friends.
I don't champion "open source" because I'm not particularly interested in making a business-first argument about developer efficiency (which is a bit of a myth) or going on about the latest twist on 'many hands make light work' (many eyes do help reduce bugs, but some bugs will apparently escape a lot of programmers). Instead I'd rather focus on how freedom places the control of my computer in my hands, leaving it to me to decide how much time and effort I want to put into improving my software. I've come to expect these freedoms with my house, my car, my plumbing, my electricity, and other things despite that I'm not a carpenter, mechanic, plumber, or electrician. I wouldn't trade away the freedom to criticize my government despite not being a great writer. So too I should cherish software freedom for its own sake. So it seems entirely right and proper to focus on this freedom and stress free software's inherently better way of treating users over proprietary software. Tossing aside this concern means treating freedom the same way as being trapped by monopolists.
Digital Citizen
Not to sound trollish - but what imaginary world do you live in? Buggy software is a fact of life for the most part - it is created by humans and we all make mistakes. So, what software do you use that has never had to be updated or had a bug fix?
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...
How do you know that the security auditors identified the vulnerability by looking at the source? I think it's completely possible this was done by fuzzing, just as a lot of the proprietary MP3 codec vulnerabilities have been found.
If i had one dollar for every brain you dont have, i would have $1.
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 you?
When's the last time you saw a piece of software crash?
It's true. Humans aren't perfect. And yet we somehow design bridges (for the most part) that DON'T fail, cars that DON'T explode, appliances that DON'T electrocute us, and televisions that DON'T shoot laser beams. When these things do, rarely, occur, we hold the engineers LEGALLY RESPONSIBLE for the consequences.
We programmers are used to working under a "fog of wizardom" where our actions are taken as mysterious, inexplicable, incomprehensible, and genius. We coasted for decades by pulling the wool over the world's eyes this way. But the reality is, writing code is no more complicated than building a bridge or putting together a car engine. We consider these sorts of workers "blue collar." Most programmers today don't even design the code they write -- they write to a specification written by somebody who is probably only marginally more competent than they are. The world is waking up to the reality that most programmers, like most people in general, absolutely suck at what they do. And this "fog of wizardom" is going to dissipate. Rapidly.
The day is coming where software writers will be held accountable for the flaws they create, at least those which result in actual harm, whether human or financial. I suspect that a great many programmers will simply drop out of the workforce rather than face legal consequences for their failures.
Thanks though, for the quality full disclosure at the bottom of your statement.
How does the code get access to anything but the *executing user's* files? It gets the same privileges as the program has been granted by the user/admin, but unless something is really wonky in the system, it does not have an avenue of getting more rights.
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.
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
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?
As reported in the article, libFLAC is fixed already.
http://ask.slashdot.org/askslashdot/07/11/19/2121226.shtml
An infinite time, apparently.
Who doesn't?
From the parent's website: This page was last updated on Thursday December 25'th, 2003 . Yep, he's a MS developer all right.
I didn't believe it until I listened to some jazz Vorbis files over an M-Audio 5.1 Revolution card with Sennheiser HD 540 Open-Aire headphones (neither of which are expensive enough to be truly "audiophile"), and I noticed some distortion in the high frequency sounds. Playing the same song from the original CD was significantly better, and I assume that playing a FLAC (or Apple or MS equivalent) would sound near identical.
You are kidding? Did you play the CD on the same computer as the FLAC? The PCM stream is identical in both. How would they sound anyway other than identical? I have a couple reasons the sound from playing the CD and playing the FLAC is not identical on your computer.
1 Some cheap sound cards pick up noise on the system power supply. I know the cheap Dell provided at work makes noise in the headphones when moving the mouse. You have have had degraded experiance simply from CPU noise from processing the FLAC file.
2 The sound from the CD drive is analog. This means the CD drive decodes the PCM and uses it's internal anit-alising filter and send the analog result to the sound card. The FLAC file does not get to use this D/A decoder and filter, but uses the one on the sound card instead. The poorly filtered D/A conversion would have more artifacts and be of lower quality because the filter on the sound card is not optimised for the CD datarate.
A sound card which is immune to this noise would produce identical results if it was fed the decoded PCM stream from both the CD DAO and FLAC file as it is exactly the same to the bit from the FLAC and CD.
The truth shall set you free!
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.
libavcodec does indeed have its own FLAC decoder, which is not dependent on libFLAC. It may have (optionally) supported using libFLAC at some point in the past, but my subversion checkout from a couple weeks ago doesn't even seem to support that anymore, instead preferring their own FLAC implementation.
The eEye Security advisory doesn't mention libavcodec at all. That seems to have been (incorrectly) added by heise security.
God, is this like the retard thread on Slashdot now?
The code 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!
How we know is more important than what we know.
Sorry for the second post, but I have an additonal thing to mention regarding my other reply. I posted and thought, for a fair comparison, the FLAC would need to play back on the same hardware as the CD.. This means it needs to playback on the CD drive with the built in CD drive A/D decoder and anit-alising filter.
Here is how to do it. Rip a CD to FLAC. Take the FLAC file and burn an Audio CD from the FLAC. Play both in the CD Drive. They will both use the CD A/D converter. Playing the FLAC on the sound card A/D converter will probably sound worse simply due to the lack of a proper anti-alising filter.
The original CD and the burned CD audio tracks should be bit for bit identical and play back the same.
The truth shall set you free!
That's irrelevant, since you don't need the source code to find buffer overflows. It just reduces the time needed to find them.
And a patch has been applied by... everyone?
You don't need root access to turn a machine into a spam zombie, which is the growth market for trojans nowadays.
We all know users don't install plugins or take actions. Stupid actions, even.
Just like Microsoft security alerts, which apparently do nothing to stem the infection rates from emailed and zipped executables that arrive via email and require all sorts of gyrations to install.
This doesn't seem vage to me.
Kernel space? Hardly. Read the exploit description. It's a bad exploit though.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
Gold shielded power, speaker, and headphone cables to avoid picking up noise that masks the differences between MP3/AAC and FLAC: $2000. I call bullshit. Looks like someone's never heard of Monster Cable. Seriously, they try to advertise a "clearer digital signal" and charge you a fucking premium.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
It doesn't have to do with open source so much as it has to do with a lot of people having the attitude of 'well, it doesn't even matter if open source has more vulnerabilities, because they are fixed faster since anyone can provide a patch'. In the case of a flaw in hardware, this kind of attitude along with 'release early, release often' can potentially lead to issues like this one.
Its my understating from reading hundreds and hundreds of /. posts that this isn't supposed to happen with FOSS. Only Micro$oft developers are supposed to have security bugs like this.
Then I question your reading comprehension.
FOSS apps, like proprietary apps, are only as good as their programmers. But with FOSS, far more programmers can review the code, and fix vulnerabilities like this when they arise.
"If it's real, then it gets more interesting the closer you examine it. If it's not real, just the opposite is true." -
Before writing a huge rant, try to actually read the post you're responding to, maybe? They were comparing the sound of an vorbis file to the sound of a CD. They never claimed to have done a listening comparison between FLAC and a CD, unlike the imaginary post you seem to be so outraged by. :)
They never claimed to have done a listening comparison between FLAC and a CD
Did I miss something in reading this?
Playing the same song from the original CD was significantly better,
The truth shall set you free!
Compare this article and one posted earlier (http://ask.slashdot.org/article.pl?sid=07/11/19/2121226) to see the difference FOSS makes.
I didn't believe it until I listened to some jazz Vorbis files
Somehow I was on a FLAC track and missed the lane change.. sorry.
The truth shall set you free!
Yeah, my girlfriend's been giving me FLAC, so I walked up to the pharmacy counter and said "TROJANIZE ME!" The guy just looked at me funny...
Mmm ponies, delicious.
There is no environment safe enough for programmers who write code that works out to:
malloc(user_supplied_unchecked_value);
You may as well consign them to documenting the work of people who don't do that. An error that basic isn't going to remediate with counseling, nor with fancy new programmer proof technologies, no matter what the salesman told you.
Help stamp out iliturcy.
You know if this was a flaw in WMV we'd see tags like "defectivebydesign", "m$sucks", etc. Where's the (lack of) love for Xiph.org?
First of all, the obligitory remark: shame on you for supporting that abusive monopolist.
Allocate pages with VirtualAlloc.
Protect pages with VirtualProtect. Use PAGE_NOACCESS, not the ever-so-tempting PAGE_GUARD which isn't persistant.
Now, you'll of course abstract this so that your code still works on MacOS and Linux, right? It'll work on 64-bit MacOS and Linux too, where a "long" is 64 bits, right? Of course you will, out of gratitude to a Linux user who helped you, and because you might need MacOS or Linux support when you reuse that code for some non-PC platform.
I have the feeling that Linux security is going down. I got the feeling about 5 years ago. It probably has been going down for maybe 10 years. I see no end to it, quite contrary.
The reason? You nailed it. Nobody gives a damn when an essential Linux library has huge security hole.
Making up jargon to sound erudite actually makes you sound stupid.
I don't know why. It's a perfectly cromulent word.
Turing complete languages aren't very amenable to engineering -- simply because it's impossible to have a compiler prove desirable properties of programs in any of your favorite TC languages. Static structures in the real world behave very predictably due their very physical nature -- programs do not. Again, that's because most programming languages are Turing complete -- if they aren't you can mostly only write very uninteresting programs (though this doesn't always apply).
There are of course differences between languages that make it either easier or harder to screw up, but that's about as far as it goes. You can never get rid of bugs.
>When is the last time you were driving and the road just COLLAPSED?
1979. Half the highway just washed away, and I avoided driving into the resulting gully.
>The bridge fell down?
Happened to my grandfather in 1956. Happened to some people this year in Minnesota.
>Your car spontaneously burst into flames?
Happened twice, once in my Rabbit (Someone helped me put the fire out) and once in my AMC Spirit (car burned to a hulk)
>When's the last time you plugged an electrical appliance into a wall and got shocked?
1986. I've been really sketchy about electrical cords ever since.
>Last time your plasma television went nuts and shot laser beams at your cat?
I've never even seen a plasma television, but if I had one, my cat would probably find a way to mess it up.
>When's the last time the case of your box fan failed and the blades went flying through the air, decapitating you?
I've had a ceiling fan liberate itself from the ceiling, and I've been slapped by the belt breaking loose from a large
industrial squirrel-cage fan in a barn I was working in.
Except for your more extreme examples, that stuff *does* happen, albeit infrequently.
-fb Everything not expressly forbidden is now mandatory.
>this kind of attitude along with 'release early, release often' can potentially lead to issues like this one.
1. The lib was fixed before the article was written.
2. Very few implementations actually use the reference library in the first place.
The reference implementation is supposed to be taken as "the implementation of this spec is left as an exercise for the reader."
There's no end of really bad code in programming texts (since bullet-proofing it would detract from the educational value). Are we going there?
-fb Everything not expressly forbidden is now mandatory.
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.
The difference is that (1) no one is willing to pay the price of a bridge (or the development of a major physical product) for similarly secure or bug-free software because it's rarely worthwhile in terms of time and money (whether open source or no) and (2) every piece of a bridge is worked over by different people in different roles (architect, different types of engineers, the people that build it, etc.), each of which has a chance to notice critical problems. As the bridge goes through various stages of development many types of critical problems become more obvious, not less; as software goes through various stages of development bugs not affecting the user experience become harder to spot. (Despite this, buildings can from time to time be found to have critical engineering flaws after they are built, requiring them to be reinforced or even rebuilt)
When you really need software to be secure or bug-free you can almost get it there, but you have to pay exponentially more to get an exponentially smaller increase in security or decrease in bugs, and it will also take a very long time no matter how many people you throw at it. Would you be willing to pay a factor of 10 more and double the length of your project in order to go from 95% secure to 99% secure?
This is NOT some no-exec thing.
:-)
The guard page sits right at the end of the buffer. Both read and write permission is blocked; the OS may implement this as an unmapped page. That stops an overflow from anything with a stride length smaller than the page size. Add more pages as desired; with 64 K of guard area you can stop a 16-bit stride.
For the rest, masking will constrain the result to be within the buffer.
Memory containing the GOT should never be returned for a fresh allocation; that would mean you had screwed the memory allocator before even looking at the untrusted data.
When an engineer designs a bridge, the intended environment of the bridge is examined. A detailed set of specifications is drawn up. And, perhaps most importantly, a budget commensurate with the time and effort taken is supplied.
Software doesn't run in a fixed environment. Even on a single OS, third party software is installed, different drivers are installed, etc. Commercial software has to be able to run in innumerable slightly different environments. In your analogy, it would be like telling the engineer that his bridge would have to work no matter where it was placed.
Most of the software I develop has had no formal specification. Clients with no formal training in software development provide vague outlines, and are unwilling or unable to further nail it down. They make lousy decisions in terms of their interface which carry throughout the project. In your analogy, it would be like telling the engineer to "just build a bridge". Don't mention how long it needs to be, how much load it needs to bear, how frequently it should need to be maintained, or what materials are available. Oh, and you probably want to change your mind when the bridge is half-built.
Secure software can be built. It is. It's built for things like medical and aeronautical applications. It relies on being run on a completely known environment. It relies on being given tight specifications. And it's damn expensive, because every line of code in the whole system (the OS, the drivers, the applications, the whole thing) needs to be audited, usually multiple times. Nobody is willing to front that money for commercial development, even if the other constraints were somehow met.
Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face
Yes there are trolls that put that in everytime MS screws up, but those tags originate from stories where it was the DRM part that introduced problems. This is just sloppy coding, it happens all the time, only because this is opensource it will be fixed or has already. Unlike MS who has a story just a bit down how they won't fix a major error in one of their own products because they don't want you to use it anymore and damn you if you still need it.
That is why MS sucks, not because they produce buggy software, but because they have a lousy history of fixing them and keep introducing new unwanted crud that just piles on the bugs.
If opensource starts doing that, let me know.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
I have excellent Karma and I am not afraid to Troll it.
libavcodec, and thus ffmpeg, mplayer and cousins, have had a native decoder since 2004:
http://svn.mplayerhq.hu/ffmpeg/trunk/libavcodec/flac.c?view=log
Besides, it's the svn version, but I don't see any configure option to use FLAC library...
Maybe heise could have more accurately pointed out which version are affected, because flac support from an external library must be an out-of-tree patch that I doubt most distros would apply.
...unless you have a habit of manually auditing every line of code that goes into your favorite Linux distro.
well, it looks like someone does, otherwise this would never have been found.
i wonder how many people independently audit closed-source windows code.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
How can a file format have vulnerabilities?
It can, if the format specifies "this section contains a pointer to code that MUST be executed"...
No, this is not what happened here. Yes, it does actually happen. The WMF flaw a couple of years ago was something like that.
Have you stopped beating your wife(/husband/girlfriend/boyfriend/so) yet? Please answer YES or NO.
God: An invisible friend for grown-ups.
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, that is the only account they ever bother to set up, and it is the only account they use.
To use Vista properly, you have to then set up a normal user account (something you are -not- guided through by the setup wizard) and use that account. It is not obvious to the typical user, and even as an experienced user I had to navigate a fairly unintuitive interface to do it.
IOW, I really had to -want- to create a normal user -and- go out of my way to do that.
MS had the opportunity to fix their wizard so that it creates -both- an admin and non-admin user and tell the user to use the non-admin account, but for some unfathomable reason they didn't.
A house divided against itself cannot stand.
his UID is an order of magnitude lowers than yours, so suck my shit fucktard
But these aren't bugs at all. All they're saying is if you parse/handle the file incorrectly you COULD get hosed. How is that any different from me putting random garbage in a gzip file? Or .mp3 or etc ...
He didn't find any bugs in actual software. Just a list of header entries which could lead to problems.
How hard is it to sanity check an input "chunk size == 4GB? I don't think so," etc. etc.
This article is bullshit and just trying to grab attention for someone who couldn't find a real bug/exploit.
You haven't got the first fucking clue about what you're saying, and you've just humiliated yourself in front of the entire slashdot community by saying something so ignorant and retarded.
Fuck Slashdot. Is there an algorithm for choosing the most stupid people to moderate or what?
How we know is more important than what we know.
Yeah, and with infinite time a monkey can also be as good as Shakespeare.
Pretty much. Most distros make it easy to update, and most people do it often because it is common to have that bug that is annoying you fixed by just doing it. If the bug was on a library used by servers, we'd have a longer delay, but most servers don't use libFlac.
Well, it is better than the computer taking stupid actions automaticaly...
Rethinking email
Actually, quite a lot of software in embedded devices I use has never been updated (and doesn't need to be updated, because it works as intended). This includes things like my washing machine, or the fuel injection controller in my car. Writing bug-free software is possible - it's just takes longer and costs a lot more.
When was the last time you saw a bridge standing up after a willfull, informed, and competent attempt to put it down?
Rethinking email
I know it's a bit off-topic, but thanks for those links!
Well, since you're counting, I don't. So that's at least one person.
I don't think it's an essential library either. I mean, I probably wouldn't install it on a server. Unless it was some kind of media server, but even then, the clients would be the one decoding the flac, and I'd probably want whatever was supposed to be in flac to already be encoded, lest I wanted to bring my server to its knees.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
If he's a troll, what does that make the hundreds of "Free software" promoters who bash Microsoft at every turn? It's fine to have your favorites, but you don't need to play into the double standard.
Trolls require context. Saying "i love teh xb0x!!1 it r0xx0rs!" is not a troll at an XBox site, but is at a Playstation site. Saying "I support the troops!" is a troll at dailykos, but not at freerepublic or something. And bashing FOSS here is more of a troll than bashing Microsoft here, but the opposite would be true on a MS developer blog. It's not a double standard; the whole point of trolling (from the troller's view) is to generate angry responses, and the statements required to do that vary based on the audience.
Quidquid latine dictum sit, altum sonatur.
I am NOT going to your house for Thanksgiving.
I can't believe there are GNU/Linux distros and *BSD OSs still shipping with FLAC 1.1.2. FLAC 1.1.3 was released over a year ago. Since then we've had FLAC 1.1.4, 1.2.0 and 1.2.1. I would be embarrassed being a package maintainer for FLAC and it wasn't up-to-date. There's been some rather good improvements to FLAC since 1.1.2.
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
"Gold shielded power, speaker, and headphone cables to avoid picking up noise that masks the differences between MP3/AAC and FLAC: $2000."
Stop using crappy cheap cables. Now these are some good cables.
https://www.virtualdynamics.ca/content.php?id=201&secondary_id=45
Once you listen to them you will never use cheap cables again!
And don't forget demagnetize you CDs it makes all the difference!
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
That's an interesting point. I've never looked at the software reliability issue this way. Another point to keep in mind is that we've had a LOT of practice making roads, bridges and buildings. Whereas there are a lot of changes to operating systems over time, which act as "world changing events." It's definitely a bigger issue than simply programmer laziness/ineptitude.
...exactly what a hacker would do with my Xbox once he's taken control of it.
I only buy pepper spray that's been tested on anti-vivisectionists.
Your goal is NOT to validate the input.
Your goal is to render/play/whatever the valid input, while not corrupting yourself on invalid input. Exact behavior on invalid input is unimportant.
You thus can simply force invalid input to be valid, essentially running it through a filter that mangles invalid input.
There are many ways. A few of them:
Bit masking is great for this. Suppose you deal with an value that should only range from 1 to 13. You could round that up to a power of two, so 16 choices with 3 being invalid. A bit mask of 0xf will force the data to be among those 16. (0 to 15) The 3 remaining invalid choices can be mapped onto valid choices. Valid data is unmangled, while invalid data is forced to become valid.
You can OR bits into things as well.
You can remap values, such as characters. Do a table lookup.
I'm pretty sure that, contrary to the summary, libavcodec doesn't link against libflac - libflac requires an event-driven programming methodology to use which doesn't really fit with libavcodec's design. So, which is the flaw in?
I am trolling
One should consider that sanity checks can themselves be security holes. At the very least, you have lots of extra code that can make regular old bugs more difficult to find.
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.
When was the last time you drove down a road where a single flaw in a lone molecule would render the entire 1,000 mile stretch impassible?
Dewey, what part of this looks like authorities should be involved?
Just One. Windows.
Fortunately not many people use FLAC, but I think we can see more and more of the these large cross platform security lapses. No worry, MS will bare the brunt of any attacks.
How do you know that the security auditors identified the vulnerability by looking at the source?
Because it's approximately a zillion times easier to audit the source code of an application than the binaries. If you have the source available and you decide to just look at the binary anyway, then you're probably nuts. Unless you're looking for compiler induced security bugs.
And yet these bugs have been there for years and years. What happened to the peer-review by "one million eyes"?
BTW, you know how many people "audit" the typical OSS project as SourceForge? ONE ( or however many active developers there are on the project). So get off of it.
-- "I never gave these stories much credence." - HAL 9000
I guess an interesting question is why iDefense decided that only AOL deserved to know about this vulnerability, and not the numberous other guys. They put out their advisory a little while back, but there were no details and only AOL/Winamp was listed as vulnerable. Maybe AOL is a customer? That would suck...we'd all have to pay for their goofy vulnerability brokering service in order to know what people could attack us with.
I guess that's what happens when iDefense buys the vulnerabilities from someone else like Sean de Regge. The people at iDesense don't have their own research team to deal with the vulnerability since they're literally just a couple of cyber-security ticket scalpers not real researchers.
Makes sense why iDefense is on the chopping block: http://www.scmagazine.com/uk/news/article/767733/verisign-sell-non-security-business-units/
It looks like eeye has a service like that too. I probably can't afford it, but this slew of vulnerabilities is free advertising for eeye's service.
finally got a workin wimamp exploit after being up all damn night. not sure if its as hard as it was for me because i am new at writing exploits. its pretty damn funny though click on flac from a website and b00m soon as winamp tries to play it i get a shell hahaha so tempting not to us ethis sort of stuff. i'd post the exploit but i'm sure that RIAA will find some way to say my exploit helps people steal music and sue me into oblivion. so whatever email me if you are trying to write one and hit any hurdles. eeye if your reading, hire me! It was damn funny when I first ran my exploit it didnt work because i'm using your free blink personal security product, ran the exploit and bam some generic buffer overflow thing kicked in and stopped it hahaha
do you deny that the peer-review happened and the bugs were found?
That doesn't mean that you *shouldn't* check your input also, because of course you should. (One of the first lessons my college CS100 class taught thirty+ years ago was "Never trust any input that you haven't validated", and you had to run any homework programs against the professor's data sets which had values deliberately chosen to trigger off-by-one errors, bad data types, etc. Apparently that wasn't common practice in computer science courses, based on how often I see software that's vulnerable to malicious input.) For some of the inputs to FLAC, it's pretty obvious what ranges of values are sane and what aren't, e.g. album art that's too big, or overly long URLs or comment strings.
I don't know enough about the seek-table behaviour to know if those vulnerabilities are realistic or not - freeing already-freed or never-malloc()ed memory is in bad taste, but I don't know if that's the library's problem or the application's problem, and of course there are languages where the issue doesn't come up.
Meanwhile, I guess you should avoid listening to malicious files... or contract with RIAA to spread them around.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
The article doesn't say the bugs were found by going through the code. They could've been found using the tried and true techniques that have been used to find bugs in closed-source codecs.
It's interesting that it took years longer to find the bugs in a FOSS codec. The FOSS propaganda implies that such bugs would be found more quickly than in closed-source codecs. But in this case, I'd *guess* that nobody really bothered to do security tests on FLAC until now, and that's the reason it took so long to find the bugs. Whatever the case, the fact that FLAC is OSS didn't lead to the bugs being found quickly.
-- "I never gave these stories much credence." - HAL 9000
you do not understand this. having the right to read and modify the source code allows new, more powerful methods of finding bugs. as we have seen in many cases, this has allowed bugs to be found and corrected.
So I have Flac installed in C:\Program Files\FLAC and I dutifully installed the new version, which DIDN'T seem to install a new libFLAC anywhere, just a new flac.exe
;-)
But I also have copies of libFLAC.dll in C:\Program Files\guliverkli\oggcodecs, and C:\Program Files\VideoLAN\VLC\plugins. The web sites for Media Player Classic ("guliverkli") and VideoLAN indicate I have the latest Windows version and neither mentions this vulnerability.
This is probably cruft that I accumulated trying to play various media files from the IntarWubwubwub. "Just click to _download this plugin_ and play this format!" Great, now it's a year later and I don't know where they all came from. I think one came from http://www.illiminable.com/ogg/ , but that was last updated 2006-02-24 (and again, no mention of this vulnerability).
F*** it, I'll just delete every file matching libflac*.dll and see what happens. But the various Windows free media players could sure do a better job with all the money I give them
Linux package management seems *better* than random untracked installs and downloads in Windows.
=S