×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Multiple FLAC Vulnerabilities Affect Every OS

kdawson posted more than 6 years ago | from the don't-hit-play dept.

Security 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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

360 comments

I like ponies. (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#21415561)

I like ponies.

Re:I like ponies. (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#21415569)

ok

Re:I like ponies. (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#21415607)

I like ponys more

Re:I like ponies. (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#21415647)

OMG! Ponies!

Sanity checks: (5, Insightful)

andreyvul (1176115) | more than 6 years ago | (#21415581)

Perform them.

guard pages, bit masks, and so on: better (5, Informative)

r00t (33219) | more than 6 years ago | (#21415869)

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)

Re:guard pages, bit masks, and so on: better (1)

Anonymous brave dude (950545) | more than 6 years ago | (#21415925)

I like it. But I don't know if it would be any faster than sanity checks.

Re:guard pages, bit masks, and so on: better (4, Interesting)

r00t (33219) | more than 6 years ago | (#21415991)

The big thing is reliability. You have less to screw up.

But yes, it is faster.

The guard pages are essentially free. They have a minor one-time start-up cost, like doing a memory allocation. As long as you keep reusing that buffer, you don't have any extra overhead.

Bit masking is a very cheap math operation. It does not need to involve the branch predictor. There is no "else" code to bloat things up and even contain more bugs; the mask simply forces the data to be good. (well, "good" as in "good enough for security" -- it won't turn an attempted buffer overflow exploit into beautiful music!)

BTW, some Linux kernels also provide a "seccomp" mechanism. It's a severe sandbox, limiting you to about 4 system calls. If you can make your code tolerate that, remembering to close any unneeded file descriptors before you switch it on, you'll be damn secure.

A lot of these are app flaws, not flac flaws ... (0)

Anonymous Coward | more than 6 years ago | (#21415965)

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.

Re:A lot of these are app flaws, not flac flaws .. (4, Interesting)

QuantumG (50515) | more than 6 years ago | (#21416021)

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.

Re:A lot of these are app flaws, not flac flaws .. (0)

Anonymous Coward | more than 6 years ago | (#21416117)

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.

root listens to audio? (2, Funny)

Gothmolly (148874) | more than 6 years ago | (#21415585)

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?

Re:root listens to audio? (4, Informative)

springbox (853816) | more than 6 years ago | (#21415639)

root listens to audio?

Yes. Windows.

Re:root listens to audio? (4, Informative)

gnuman99 (746007) | more than 6 years ago | (#21415815)

root listens to audio?
Yes. Windows.

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:root listens to audio? (5, Funny)

paulgrant (592593) | more than 6 years ago | (#21415941)

or play a video with flac as the audio algorithm.
right.
especially if it plays silence on a transparent pixel.
MAN THIS SUCKS.

Re:root listens to audio? (0)

Anonymous Coward | more than 6 years ago | (#21415983)

huh? why is anyone who's technically-minded enough to use FLAC still using a pre-NT (root) windows?

Re:root listens to audio? (3, Funny)

QuantumG (50515) | more than 6 years ago | (#21415705)

This is an example of the term "failure of imagination."

Someone malicious can craft a .flac file which can execute arbitrary code when it is run on an affected player.

That someone can give that .flac file to someone else who doesn't know it is maliciously crafted and when they play the file, they have given arbitrary code execution privileges to the malicious crafty person.

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:root listens to audio? (3, Funny)

Gothmolly (148874) | more than 6 years ago | (#21416159)

What you just described is a virus, and in fact, has existed nearly as long as computers have. If you don't trust your flac-giving buddy, why take anything he gives you at all? The point is that "flac" cannot compromise your system, only your data. Unless you play the file as root.

Re:root listens to audio? (2, Funny)

Goaway (82658) | more than 6 years ago | (#21415711)

So what exactly is that that you think malware wants to do that it can do as root but not as a user?

Re:root listens to audio? (1)

Erpo (237853) | more than 6 years ago | (#21416091)

  • nmap -sS
  • insmod rootkit.ko
  • rm -rf /home/roommate
...just off the top of my head.

don't need root for a rootkit (2, Informative)

r00t (33219) | more than 6 years ago | (#21416213)

echo "export LD_PRELOAD=/home/you/rootkit.so" >> /home/you/.bashrc
echo "export LD_PRELOAD=/home/you/rootkit.so" >> /home/you/.bash_profile

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:root listens to audio? (1, Funny)

Anonymous Coward | more than 6 years ago | (#21415741)

Audio just doesn't sound the same if it's not run through a process owned by root.

Re:root listens to audio? (0, Troll)

404 Clue Not Found (763556) | more than 6 years ago | (#21415745)

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?
You mean I would only lose my documents and pictures, not any of the programs my computer came with? Whew! And all this time I thought Windows was dangerous. Good thing I followed my geeky friend's advice. Now I never download any exes and I only listen to high-quality flack music that I get from Torrence. I even regularly back them up on my USB drive alongside my files! So I'm safe, right?

Re:root listens to audio? (1)

Tweekster (949766) | more than 6 years ago | (#21415825)

regardless of OS you are and idiot if you are not backing things up.

Re:root listens to audio? (1)

timeOday (582209) | more than 6 years ago | (#21416031)

Either way you still need computer security. Backups aren't going to save you when a keylogger sends your credit card # to Russia.

Re:root listens to audio? (1)

node 3 (115640) | more than 6 years ago | (#21416077)

"Idiocy" is not the thing that keeps the vast majority of computer users from backing up their files. If your goal is to get people to back up their data, calling them "idiots" is not going to help you with that goal.

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:root listens to audio? (1)

Dare nMc (468959) | more than 6 years ago | (#21416105)

you are and idiot if you are not backing things up.

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 takes me 1/8 day to backup, if I backup monthly I will spend ~ 2 weeks time backing up before a failure. So if it would cost the company no more than 2 man weeks labor, to recover from a typical 1 / 5 year failure, and will, on average, be 2 weeks after the last backup, then my backup schedule is sufficient.

Re:root listens to audio? (1)

Gothmolly (148874) | more than 6 years ago | (#21416187)

Thats correct. The apps your computer runs are only root-writeable, right? Oh, they're NOT? DOS 7.0 is so 90s...

The headline and summary are bogus - malicious code has no more privilege than you do. If you, as nonroot, can hose up your system either maliciously or not, then you have far greater problems than some trickery in an obscure file container format.

Re:root listens to audio? (0)

Anonymous Coward | more than 6 years ago | (#21415823)

I, for one, automatically installed the "compress-all-audio-according-to-UID" kernel module. This essentially means that root with a user id of 0 implies no compression, so it does sound some what better.

right, I have backups... (1)

r00t (33219) | more than 6 years ago | (#21415891)

of my private keys, finance data, NDA-protected stuff, etc.

No problem?

Heck, the attacker will be making extra backups! For free!

I bet someone will cop some flack for this.. (2, Funny)

QuantumG (50515) | more than 6 years ago | (#21415587)

HAW HAW HAW.

Old McDonald Had a Farm (5, Funny)

Lachryma (949694) | more than 6 years ago | (#21415765)

eEye worked with US-CERT to notify vulnerable vendors.
If this happened over email, one could consider it eEye e-I/O.

Time to write libraries like these in OCaml. (1, Interesting)

Anonymous Coward | more than 6 years ago | (#21415611)

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 [ocaml.org]. 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.

Re:Time to write libraries like these in OCaml. (1, Troll)

bmo (77928) | more than 6 years ago | (#21415667)

Just because I have karma to burn and I don't care...

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:Time to write libraries like these in OCaml. (0)

Anonymous Coward | more than 6 years ago | (#21415699)

Based on his proclamations of OCaml's greatness and his poor English grammar, it's reasonable to guess that the grandparent is probably French or at least a non-native English speaker.

Re:Time to write libraries like these in OCaml. (1)

Anonymous Coward | more than 6 years ago | (#21415729)

In a most ironic twist concerning the parent, the word "performant" is actually a french word that translates as "efficient."
Look it up in a french dictionary if you like.

Re:Time to write libraries like these in OCaml. (0, Insightful)

Anonymous Coward | more than 6 years ago | (#21415893)

In a most ironic twist concerning the parent, the word "performant" is actually a french word that translates as "efficient." Look it up in a french dictionary if you like.
I'm sorry, is he writing in French? Is this website in French? No? Didn't think so.

Re:Time to write libraries like these in OCaml. (0)

Anonymous Coward | more than 6 years ago | (#21416071)

Baise mon cul, putain!

Re:Time to write libraries like these in OCaml. (1)

Crypto Gnome (651401) | more than 6 years ago | (#21415843)

Making up jargon to sound erudite actually makes you sound stupid.
Personally I'd have said makes you sound like you are a journalist.

Someone please MOD this comment -1 redundant ;-)

Re:Time to write libraries like these in OCaml. (1)

coolGuyZak (844482) | more than 6 years ago | (#21416079)

Making up jargon to sound erudite actually makes you sound stupid.

Awesome. I only make up jargon to sound baztastic.

Re:Time to write libraries like these in OCaml. (0)

Anonymous Coward | more than 6 years ago | (#21415671)

Why ocaml? it's got really shitty syntax, really bad threading support and the world's worst ambassador (a prolific usenet and blog spammer). We should be writing these sorts of libraries in Haskell or ML proper (you know, the one that isn't barfed up with the "O" misfeatures).

Re:Time to write libraries like these in OCaml. (1)

Bill, Shooter of Bul (629286) | more than 6 years ago | (#21416075)

because its fast as heckfire. Much much faster than ML or haskell. Its often faster than c. Although, I'd agree about the syntax. It has many small problems that really stand in the way of mass adoption. Modern Fortran is also pretty cool ( good by karma) its also fast and has some parallel features. I'd just like any of the functional languages to take off. Ocamel looks tempting because of the performance.

Its a chicken and the egg with languages like this. If they don't solve one task much better than anything else, no one adopts it even if it is "promising".

Re:Time to write libraries like these in OCaml. (0)

Anonymous Coward | more than 6 years ago | (#21415767)

Dear god the functional language idiots from reddit have invaded my beloved /.

Worst possible choice. (1)

SanityInAnarchy (655584) | more than 6 years ago | (#21415821)

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.

Jailbreak!! (2, Interesting)

evw (172810) | more than 6 years ago | (#21415621)

Possibly another way to jailbreak your iPhone or install Linux on your iPod.

Re:Jailbreak!! (2, Informative)

Winckle (870180) | more than 6 years ago | (#21415633)

Apple doesn't support FLAC, they want people to use the Apple lossless codec. Which annoys me tbh, there's no technical reason why they can't play both.

Re:Jailbreak!! (1)

larry bagina (561269) | more than 6 years ago | (#21415905)

how much processing power is needed to decode FLAC? Is the decoder integer or floating point based? the iPhone surely has enough speed if it's integer based, but last I knew (quite a while ago), the linux ipod port couldn't even play ogg vorbis at full speed.

Re:Jailbreak!! (1)

tuffy (10202) | more than 6 years ago | (#21416011)

FLAC decoding is purely integer-based. In addition, it is one of the least CPU intensive lossless audio codecs available in terms of decoding. Any iPod has enough power to decode them. Apple has simply chosen not to support it.

Re:Jailbreak!! (1)

QRDeNameland (873957) | more than 6 years ago | (#21416087)

FLAC is designed for low-power decoding...from what I've seen it is comparable to mp3 in terms of processing for decoding. It also entirely integer-based, a feature touted as superior for both portability and performance.

Re:Jailbreak!! (1)

despisethesun (880261) | more than 6 years ago | (#21416145)

I think that says more about iPod Linux than the iPod. As far as I know, iPod Rockbox users have no problems with ogg or flac files. If only Rockbox got half-decent battery life, it would be the perfect replacement for Apple's firmware. As it stands, it's a reasonable substitute if one is willing to make a few compromises.

Re:Jailbreak!! (0)

Anonymous Coward | more than 6 years ago | (#21416147)

I figure Apple didn't want to risk supporting a codec which they couldn't (or wouldn't bother taking the time to) verify as being bug-free.

The best thing about these vulnerabilities (2, Funny)

Anonymous Coward | more than 6 years ago | (#21415623)

Is that they're still lossless.

losslessly compressed (1)

Romancer (19668) | more than 6 years ago | (#21415643)

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?

Think like a .zip file (1)

samwh (921444) | more than 6 years ago | (#21415669)

Whatever you take out of it is exactly as you put it. Flac is just optimized more for audio then zip.

Re:losslessly compressed (3, Informative)

Locklin (1074657) | more than 6 years ago | (#21415677)

http://en.wikipedia.org/wiki/Flac [wikipedia.org]

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 (4, Informative)

CastrTroy (595695) | more than 6 years ago | (#21415685)

It's kind of like running winzip on your wav files. All the data is there, but it fits in a smaller space. Of course, they don't use winzip's compression algorithms because that's really bad at compressing audio. They have special algorithms that are much better at recognizing patterns in wav files. I'm not completely sure how it works, but that's my understanding of it, and the easiest I can explain it.

Re:losslessly compressed (2, Informative)

Phlegethon_River (1136619) | more than 6 years ago | (#21415687)

Just think about "ziping" a text file. It is smaller than the original file ("compressed") yet when you "unzip" it ALL of the information is still there ("lossless").

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 (1)

tuffy (10202) | more than 6 years ago | (#21415695)

Lossless audio compression means that any PCM data fed to it can be restored later, without loss of any kind. The amount of compression varies depending on the PCM data itself. Any loss incurred before getting that PCM stream (such as sampling the original analog audio) can't be helped. It's not magic, after all.

Re:losslessly compressed (4, Informative)

recoiledsnake (879048) | more than 6 years ago | (#21415707)

If you rip a Audio CD to MP3,AAC,WMA or OGG that is lossy compression. There is no way of getting the original data back. If you compress it with FLAC, you can get the exact bits present on the original Audio CD. Note that we are talking about only digital conversions. How the CD was mastered from the analog source is a complete different matter and has nothing to do with FLAC.

Re:losslessly compressed (1)

sseaman (931799) | more than 6 years ago | (#21415715)

Can someone explain how this compares to the original recording?

It compares to the individual recording in the same way that the compressed contents of a .zip compare to the uncompressed contents.

Like a .zip, it takes more processing power to access its contents in real time - it must be decoded into PCM data in order to be played - but all the information is there. Of course, the compression ratio pales to that of lossy codecs (like MP3), but with good equipment and the right song you can notice a difference - 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're right (0)

QuantumG (50515) | more than 6 years ago | (#21415737)

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.

Re:losslessly compressed (1)

belmolis (702863) | more than 6 years ago | (#21415953)

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 apart in time may have very different values. Now, given that adjacent values aren't very different, one simple way to compress audio is to replace the original signal with the differences between adjacent samples, which will usually be small in comparison to the sample values. For example,if the uncompressed audio has 16 bit resolution, you might use only one byte to represent the differences. (This is a real compression technique, though in practice you need to provide for cases in which the differences are larger than what you can represent in the smaller number of bits you're using for most of them.)

Re:losslessly compressed (1)

BlueParrot (965239) | more than 6 years ago | (#21415987)

To use an analogy, if all your images consist of a doussin lines, then storing them as an XML encoded list of lines will occupy a lot less space than using a 1280x1024 bitmap. However, if you try to use the same XML format to store images of grainy materials, like sand, concrete etc... then you will end up storing a complicated list of lines for every single point, leading to a much larger files than if you had just used a bitmap.

Lossless compression works by identifying common features of a particular type of data ( in this case sound corresponding to music or converastion ) and optimising the storage algorithm after that. If you tried to use FLAC to record a sound that wasn't music or conversation, such as white noise or 30 minutes of machine gun fire, then you would probably end up with a larger file size.

But I thought that this didn't happen with FOSS (-1, Flamebait)

Foredecker (161844) | more than 6 years ago | (#21415681)

So this is really ironic - 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.

Now, how did this ship? Who tested it? Who did the code reviews? Who did the security reviews? Who did all the threat modeling?

Irony aside, (and I am a Microsoft developer) getting security right is hard. FOSS folks are not any better, or worse, than Microsoft, Apple, Sun or IBM developers.

Re:But I thought that this didn't happen with FOSS (5, Insightful)

Locklin (1074657) | more than 6 years ago | (#21415733)

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.

Re:But I thought that this didn't happen with FOSS (1)

dedazo (737510) | more than 6 years ago | (#21415795)

no one here think's FLOSS == perfect security

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.

Re:But I thought that this didn't happen with FOSS (1)

onefriedrice (1171917) | more than 6 years ago | (#21415861)

> 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.

DoucheBag Shut Your Fucking Mouth (-1, Troll)

Anonymous Coward | more than 6 years ago | (#21415753)

DoucheBag Shut Your Fucking Mouth

Re:But I thought that this didn't happen with FOSS (2, Insightful)

stevenvi (779021) | more than 6 years ago | (#21415763)

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.

Re:But I thought that this didn't happen with FOSS (4, Insightful)

Crypto Gnome (651401) | more than 6 years ago | (#21415787)

Firstly...

libFLAC version 1.2.1 was released in September, 2007, fixing these vulnerabilities for most vulnerable applications.

Secondly...

this isn't supposed to happen with FOSS
Actually exactly this IS supposed to happen with FOSS.

Where this is .... someone other than the original developer(s) read through the original source code in order to identify vulnerabilities, and then provided information about said vulnerabilities back to the original developer(s) who promptly resolved the aforementioned vulnerabilities, with many thanks"

Re:But I thought that this didn't happen with FOSS (1)

SanityInAnarchy (655584) | more than 6 years ago | (#21415873)

So this is really ironic - 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.

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.

Now, how did this ship? Who tested it? Who did the code reviews? Who did the security reviews? Who did all the threat modeling?

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.

Re:But I thought that this didn't happen with FOSS (0, Flamebait)

Tweekster (949766) | more than 6 years ago | (#21415885)

The fact you are an MS developer pretty much explains why you are that stupid.

Re:But I thought that this didn't happen with FOSS (5, Insightful)

BlueParrot (965239) | more than 6 years ago | (#21415895)

So this is really ironic - 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.


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:But I thought that this didn't happen with FOSS (2, Interesting)

totally bogus dude (1040246) | more than 6 years ago | (#21415907)

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 format

How can a file format have vulnerabilities? Surely the vulnerability exists in code that reads and interprets the bytestream, not in the format itself.

Re:But I thought that this didn't happen with FOSS (1)

beav007 (746004) | more than 6 years ago | (#21415979)

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...

Re:But I thought that this didn't happen with FOSS (1)

grcumb (781340) | more than 6 years ago | (#21415985)

Now, how did this ship? Who tested it? Who did the code reviews? Who did the security reviews? Who did all the threat modeling?

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 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?

love em M$ shills (-1, Troll)

Anonymous Coward | more than 6 years ago | (#21415989)

d00d, you misspelled Micro$oft. Now go back to sucking Ballmers... eh, balls.

security bugs that FOSS does not have (0, Offtopic)

r00t (33219) | more than 6 years ago | (#21416081)

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"

Re:But I thought that this didn't happen with FOSS (1)

Tribbin (565963) | more than 6 years ago | (#21416135)

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.

Fixed in Ubuntu (3, Informative)

coolhelperguy (698466) | more than 6 years ago | (#21415789)

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 [ubuntu.com] 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.

open-source (0)

Anonymous Coward | more than 6 years ago | (#21415791)

Why don't they switch to something more secure, like an open-source alternati- ...oh. Right.

Phew (5, Funny)

Frogbert (589961) | more than 6 years ago | (#21415807)

Good thing no one uses this esoteric "FLAC" format.

Re:Phew (1)

dkalley (776724) | more than 6 years ago | (#21416041)

From article: "Until updates are made available, users should only play FLAC files from trusted sources. To date, however, FLAC files are rarely seen in the wild."

Ironic since I read this article while listening to a just downloaded Devo show in flac format. Considering the number of live music torrent sites ( e.g. archive.org [archive.org],trader's den [thetradersden.org], etree [etree.org] , and dime a dozen [dimeadozen.org]) that mostly offer FLAC I am surprised by the statement. I also would think that people wanting lossless quality audio will be checking their hashes anyways for audio integrity and it won't be a problem. There is also a difference in leaching an album in FLAC off a torrent site and audiophiles listening to live music, the former would be inclined to listen to mp3 rips anyways. Good to know, but the security implications seem a stretch.

Queue the open source apologists... (0, Troll)

ComputerPhreak (1057874) | more than 6 years ago | (#21415853)

Queue the open source apologists who will downplay this and praise the quick response (that may not have happened yet) of open source teams to fix this vulnerability. How are you going to patch embedded devices that have hardware vulnerabilities?

I'm not flaming FLAC, but let's try to have a discussion that isn't a skewed, auto-defense of FLAC just because it's open source.

This comment not modded up yet (0, Troll)

QuantumG (50515) | more than 6 years ago | (#21415935)

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.

Re:Queue the open source apologists... (1)

pclminion (145572) | more than 6 years ago | (#21416185)

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.

Those security tell me to get the FLAC out of here (2, Funny)

syousef (465911) | more than 6 years ago | (#21415917)

I thought they were just being rude. Now I know why.

Fuck no, get a clue (1, Informative)

Anonymous Coward | more than 6 years ago | (#21415963)

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 (2, Informative)

unixmaster (573907) | more than 6 years ago | (#21416017)

libavcodec never ever used libFLAC, it has its own FLAC encoding & decoding code, hence not affected. Lousy journalism on Heise part.

Some things in life, money can't buy... (5, Funny)

Mr2001 (90979) | more than 6 years ago | (#21416033)

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.

OMG PONIES!!!! (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#21416141)

         xxxxxxxxxxxxxxxxxxxxxx
    _____xx  Feed me Feed Me xx
  /   O O\   Feed the trolls xx
/         \   I like Ponies  xx
/ _    \   \  xxxxxxxxxxxxxxxxx
  |\____\   \        XX
  | | | |\__/        XX
   \|_|_|/ |        _XX
           | i_ _ _i XXo
            \ -----i_XXo
             \
Please control the human population, have sex with ponies!

Thank you eEye and Devs (4, Insightful)

awfar (211405) | more than 6 years ago | (#21416175)

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.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...