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

Comments

I like ponies.

[Anonymous Coward]

I like ponies.

Re:I like ponies.

[Anonymous Coward]

ok

Re:I like ponies.

[Anonymous Coward]

I like ponys more

Re:I like ponies.

[Anonymous Coward]

OMG! Ponies!

Re:I like ponies.

[Anonymous Coward]

No, you can't have a pony.

Re:I like ponies.

[Anonymous Coward]

Hello ,kind sir,

I am direct to your attention the postage of the rtaate which of TWELVE THOUSAND DOLLARS ($) U.S. in forthwith to bank of me,. to you!!! PRAISE GOD

Re:I like ponies.

[Anonymous Coward]

Who doesn't?

Re:I like ponies.

[Anonymous Coward]

Mmm ponies, delicious.

Sanity checks:

[andreyvul]

Perform them.

Re:Sanity checks:

[MarkRose]

Sanity checks? Whatever for? I was just going to rely on my FLAC jacket.

root listens to audio?

[Gothmolly]

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?

[springbox]

root listens to audio?

Yes. Windows.

Re:root listens to audio?

[QuantumG]

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?

[Goaway]

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?

[Anonymous Coward]

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

Re:root listens to audio?

[gnuman99]

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?

[Anonymous Coward]

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.

Re:root listens to audio?

[Tweekster]

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

Re:root listens to audio?

[paulgrant]

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?

[Anonymous Coward]

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

Re:root listens to audio?

[timeOday]

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?

[node 3]

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

[Erpo]

• nmap -sS
  
• insmod rootkit.ko
  
• rm -rf /home/roommate
  

...just off the top of my head.

Re:root listens to audio?

[MightyYar]

Now, now. Some of us are just lazy :)

Re:root listens to audio?

[Dare nMc]

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?

[Gothmolly]

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?

[Gothmolly]

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?

[QuantumG]

1. local exploits
2. see my page on jumping su and sudo.

Re:root listens to audio?

[hdparm]

Hilarious! Thanks for a real good laugh.

Re:root listens to audio?

[timmarhy]

it can keylog your ass so next time you su to root it'll have you.

grow some imagination please.

Re:root listens to audio?

[russ1337]

It is difficult to get Vista hosed by malware compared to XP.

Newsflash. Vista is the malware.

Re:root listens to audio?

[pclminion]

Oh, you mean that a USER could compromise THEIR PERSONAL FILES... well, that does suck, but you have backups, right?

"That hacker stole all my steamy emails between me and my mistress and threatened to tell my wife unless I pay him $10,000! Thank God at least I have backups!"

Re:root listens to audio?

[xouumalperxe]

Because, of course, privilege escalation bugs have never EVER cropped up.

But that's merely a technical argument in an area where psychology reigns supreme. And the moment you assume the attitude of "It's not worth giving a damn because careful users won't have issues", you already lost that game.

Re:root listens to audio?

[Anonymous Coward]

But how many man hours are wasted because they're waiting for the lost data to be restored? How many man hours are wasted because they can't create new data because there is nowhere to put it? How much money is it worth to be able to be back to normal after 2 hours as opposed to two weeks? How much is it worth to know that your office should be able to rebound from a crash in less than a day? Certainty and predictability are worth a lot of money.

Re:root listens to audio?

[darthgnu]

Bah, just restore your wife's brain backup, you have one, don't you ?

Re:root listens to audio?

[durnurd]

Cf. Vista not trusting its users with HD media

Re:root listens to audio?

[Gothmolly]

You're really stretching there. Not only does my "friend" give me an evil FLAC, but he also happens to craft it against specific, unpatched-at-hack-time local exploits, or manage to include a shellscript/sudo-avoiding payload?

Re:root listens to audio?

[definate]

It seems you're writing a pro Vista comment...

We don' like yo' type 'roun' 'ere, yew best keep moving.

Man, I hope I got my punctuation of the accent correct, or I am going to get reamed by Grammar Nazi's.

Re:root listens to audio?

[Lost Engineer]

Point taken. This is one reason my BSD, OS X, etc. are on the sudo system, and a reason for you to use sudo

Re:root listens to audio?

[empaler]

(grumblegrumblethenewdiscussionsystemdidn'tshowthepostyourepliedtowhenIwaswritingminegrumble)

This answer goes a lot further in explaining what you were trying to express in your post, though the exploit does need the local user to also be the admin who uses sudo (though it's a pretty safe bet on most machines).
My point below was also that you shouldn't hastily call people fools for not knowing something obscure you posted to insecure.org's bugtraq 5 months ago.

Btw, congratulations on your marriage; I hope it leads to many happy years, which in turn will hopefully spread happiness.

Re:root listens to audio?

[harlows_monkeys]

You don't need root to use a machine to send spam, or to otherwise participate in a botnet. You also don't need to be root to steal sensitive information, since that is most likely to be in the user's files, not the system's files.

And if, for some reason, you do want to do something that requires root, well, local privilege escalation exploits come up fairly often.

Re:root listens to audio?

[a_nonamiss]

OK, this is Slashdot. Nobody here here has a wife let alone a mistress

You are right about the backups, though...

Re:root listens to audio?

[nick this]

...I am going to get reamed by Grammar Nazi's.

But now I've lost track of whose the troller, and whose the trollee. :)

Re:root listens to audio?

[zsau]

XP didn't cease to be Windows after the release of Vista, so the GP is right, and your correction is wrong.

If what you say is true,[*] Microsoft is to be congratulated for (finally) being concerned with the safety & security of their operating system and users, but unfortunately the release of Vista doesn't suddenly cure the millions of deployed XP boxes, many of which will probably still be in use ten years hence.

[*]: I make no apologies for not keeping up-to-date with the latest details of Windows however, and base my comment exclusively on yours.

Re:root listens to audio?

[SirTalon42]

sudo wouldn't be any more immune to the keystrokes being logged than su.

Re:root listens to audio?

[Anonymous Coward]

You give me the awful impression of someone who has never seen XP deployed in a corporate domain setting. Nobody runs XP as an admin in corporate environments, Its certainly possible to have good security with XP.
Of course you don't need to be in a domain to secure it, you can secure it on individual boxes too. However that means the user needs to be more competent and pro-active to make sure he is up to date in anti virus updates, anti-spy ware updates and run them roughly bi-monthly or so.

Re:root listens to audio?

[Anonymous Coward]

Did you even read the post? I thought it was pretty clear that he answered your questions in the "it will take 2 weeks to recover" part.

Re:root listens to audio?

[jamstar7]

Beats me, I use MP3 encoding for my music, so these problems won't bother me.

Yeah, it's proprietary, but a lotta open source audio apps know MP3.

As for hosing my user partition, that's what backups are for. You DO back up things now and again, don't you???

Re:root listens to audio?

[Jeremi]

If you don't trust your flac-giving buddy, why take anything he gives you at all?

Your flac-giving buddy doesn't have to be malicious. The percentage of people who are qualified to recognize a virus-bearing FLAC vs a correct FLAC is approximately zero. So if you're going to refrain from accepting files from people who are "untrustworthy", then you are essentially not going to be able to accept files from anyone.

The point is that "flac" cannot compromise your system, only your data. Unless you play the file as root.

Or unless there is also an escalation bug in your OS that allows someone with non-root access to get root access. And chances are quite good that there is.

Re:root listens to audio?

[n3r0.m4dski11z]

So the uac prompts that are the first thing everyone asks me to turn off, are what you think "not running as root" means? buddy, newsflash, everyone's still running as administrator

You run a non admin account on a default vista install? are you sure about that?

Re:root listens to audio?

[Anonymous Coward]

In light of the fact that you "keep loosing track of what all my computers have on them", by your own admission, how would you know?

Re:root listens to audio?

[jacquesm]

that's a good one

ask any small business how they'd like to be *DOWN* for two weeks. what an absolutely idiotic argument. the backup time
gets smeared out over the years, the two weeks happens *ALL AT ONCE*.

backup daily. Even if it costs you that 1/8th of a day, just do it at night and automated, that's what
computers are for.

here's an excellent chance to excercise your scripting skills.

http://rndpic.com/ don't clikc, not safe for work *and* addictive. you've been warned ;)

Re:root listens to audio?

[kestasjk]

I run under an XP non admin account, it's not hard. In business environments it's the usual set up. Vista does do this by default though, which is a plus.

Re:root listens to audio?

[CrossChris]

It is difficult to get Vista hosed by malware compared to XP.

Bzzzt! Wrong! It's as trivially easy to take down Vista as any other version of Windows. It's still the same old NT kernel after all. Watch out - here comes the malware on every file-sharing site!

Windows: a poor proprietary client for a Unix world.

Re:root listens to audio?

[Tenebrarum]

It seems you're writing a pro-Vista comment.

Allow or allow?

Re:root listens to audio?

[paulgrant]

you laugh, and then you get rooted.

Re:root listens to audio?

[Goaway]

The only one malware wants to do is the rootkit one, and even that is just a bonus. It can do its real work just fine without it.

Re:root listens to audio?

[Optikschmoptik]

The percentage of people who are qualified to recognize a virus-bearing FLAC vs a correct FLAC is approximately zero. So if you're going to refrain from accepting files from people who are "untrustworthy", then you are essentially not going to be able to accept files from anyone.

...unless you encode it yourself from CD or wav, or a trusted friend gives you one she encoded herself, or you get it from a reputable distributor, etc.

This actually happens to be the source of most of the FLACs I have. I think it's an obscure enough format that most people know who encoded most of the files they have, so I doubt this really affects anything at all.

Re:root listens to audio?

[LizardKing]

So rather than needing to record two passwords if your machine doesn't allow remote root access, the keylogger only has to record one. When are idiots like you going to realise that sudo is a waste of time?

Re:root listens to audio?

[LizardKing]

I suppose I better expand on my "sudo is a waste of time" comment.

Sudo is generally configured out of the box to allow root access, making it little more than an alias for su. Actually configuring sudo to allow limited access to certain commands is fiddly, and often misses things (try running a root /bin/sh from sudo - works almost every time). Sudo is also a poor alternative to ACLs, or just setting up groups to control access to certain device files (which is often what a presumed need for sudo boils down to). For instance, perhaps you want an unprivileged user to be able to burn CDRs on a workstation install of Linux. Simply create a suitable group and set things up so that the unprivileged user is a part of that group. Then alter the group permissions on the CD burner's device file. This is far more fine grained and easier to configure than sudo.

Re:root listens to audio?

[quantum bit]

Actually the NT kernel is decently designed, and kernel-level exploits in Windows have been fairly rare (though there have been a few).

It's the Win32 layer and all the random services that run as SYSTEM (half of them OEM junk or stupid things like scanner drivers) that have had the most problems.

Re:root listens to audio?

[jedidiah]

"cp -a /home/jedi /mnt/really_big_firewire_drive"

Gee, that was hard.

That was such an economic inefficiency.

The same goes for opening up K3B, pointing to a directory and burning it to disk.

Re:root listens to audio?

[Craig Davison]

It's been said elsewhere in this thread, but malware doesn't need root to join a botnet, send spam, perform DoS attacks, record and forward your private emails and credit card numbers, etc. It also doesn't root to infect other FLAC files on your system.

And if it does need root for some reason, there are a number of privilege escalation bugs in Linux (off the top of my head, look at past vulnerabilities in the setitimer syscall). Or, the malware could just read your root password as you type it in. That's called a "blended threat".

I think the larger problem here is every application using the same library to parse FLAC files. The gzip library is the same way, used everywhere by so many products. Monoculture is a serious weakness in information security.

Re:root listens to audio?

[Sancho]

Not at all. The malicious FLAC starts up a daemon that sits and waits for you to use su/sudo, then it performs its ptrace injection. Maybe it modifies your bash_login file so that it runs every time you log in. It could even probably spoof an update-manager window, making you think that there are updates to install (which will then prompt you to enter your password.)

That's the thing about security. If the OS allows the user full control, then your security implementation is only as good as your user is knowledgeable. If you moved most Windows users over to Linux, it wouldn't take a week for malware authors to start spoofing gksudo windows.

Re:root listens to audio?

[maxume]

Losing the 'system' on a desktop is a bummer, but it can be fixed in a day or two. Losing data sucks loads and can be irretrievable. Good habits make it otherwise, but people don't have those.

On single user systems, data security is a hell of a lot more important than root security. The dependence of data security on good root security means that root security is still important(just as important as data security), but not because of the system, but because it is the first line of defense in protecting the data.

I bet someone will cop some flack for this..

[QuantumG]

HAW HAW HAW.

SLASHDOT SUX0RZ

[Anonymous Coward]

_0_
\''\
'=o='
.|!|
.| |
multiple goatses affect every OS

Time to write libraries like these in OCaml.

[Anonymous Coward]

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.

Re:Time to write libraries like these in OCaml.

[bmo]

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.

[Anonymous Coward]

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.

[Anonymous Coward]

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.

[Anonymous Coward]

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.

[Anonymous Coward]

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

Re:Time to write libraries like these in OCaml.

[Crypto Gnome]

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.

[Anonymous Coward]

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.

[Anonymous Coward]

Baise mon cul, putain!

Re:Time to write libraries like these in OCaml.

[Bill, Shooter of Bul]

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.

[coolGuyZak]

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.

[Anonymous Coward]

But there is a grassroots movement aiming at making it one: http://boulter.com/blog/2004/08/19/performant-is-not-a-word/

Re:Time to write libraries like these in OCaml.

[hdparm]

It's pretty interesting in this context, though.

Performant code for audio libraries. I love it!

Re:Time to write libraries like these in OCaml.

[Anonymous Coward]

french people are niggers.

Re:Time to write libraries like these in OCaml.

[Hal_Porter]

because its fast as heckfire. Much much faster than ML or haskell. Its often faster than c http://en.wikipedia.org/wiki/OCaml#Philosophy
Xavier Leroy has cautiously stated that "OCaml delivers at least 50% of the performance of a decent C compiler"[1], and benchmarks have shown that this is generally the case

Re:Time to write libraries like these in OCaml.

[Anonymous Coward]

Good luck with that, since O'Caml doesn't even support dynamic shared libraries written in O'Caml.

Re:Time to write libraries like these in OCaml.

[Anonymous Coward]

french people are niggers. Actually, I believe Lennon's quote was "Women are the Niggers of the world". I can never remember... I wasn't really listening to him, because to me, "Lenon is the Nigger of the world."

Re:Time to write libraries like these in OCaml.

[Bill, Shooter of Bul]

Good catch, its been a while since I looked at the benchmarks. .

But you can still see that its just slower than java 6, and still faster than haskell. I'm really surprised that Lisp is right there as far as performance. Not to mention my first serious language PASCAL kicks ass! Time to dust my Pi, and prime number finding programs off and put them back to work!

Re:Time to write libraries like these in OCaml.

[Bill, Shooter of Bul]

when will I learn to preview? Heres the benchmark

Re:Time to write libraries like these in OCaml.

[lordholm]

Does ocaml support multiprocessing now days? Last I heard the GC couldn't handle it, hence it is a rather useless language.

Do not take this wrong, ocaml is a nice language, but the lack of SMP support really kills of the usability of the language these days.

Re:Time to write libraries like these in OCaml.

[jericho4.0]

$10 on you, Mr. AC, being unilingual.

The OPs english was excellent for a nonnative speaker, and I wish my french was as good.

Re:Time to write libraries like these in OCaml.

[Anonymous Coward]

And anonymous cowards are pussies. Pot... kettle... black...

Re:Time to write libraries like these in OCaml.

[Anonymous Coward]

Dude, about 40% of English vocabulary is derived from French. Another 15% is derived from Latin, which was the precursor to French. The grammar is mostly derived from German and Old Norse. So when you're speaking English, about half of the words you're using have a French origin.

Re:Time to write libraries like these in OCaml.

[Anonymous Coward]

french people are niggers. No, Africans are niggers. French people are pussies.

Re:Time to write libraries like these in OCaml.

[zsau]

UNKNOWN ENGLISH (ENGLISH)=40 (LATIN)=(per cent) ENGLISH ENGLISH LATIN ENGLISH FRENCH ENGLISH FRENCH. ENGLISH (ENGLISH)=fifteen LATIN ENGLISH FRENCH ENGLISH LATIN ENGLISH ENGLISH ENGLISH LATIN ENGLISH FRENCH. ENGLISH GREEK-via-FRENCH ENGLISH ENGLISH FRENCH ENGLISH LATIN ENGLISH ENGLISH ?DUTCH ENGLISH ENGLISH ENGLISH ENGLISH ENGLISH, ENGLISH ENGLISH ENGLISH ENGLISH ENGLISH ENGLISH FRENCH ENGLISH ENGLISH FRENCH LATIN.

33 words of English origin.
7 words of French origin (mostly the word "French")
7 words of Latin origin (i.e. learned borrowings from Latin, not vulgar evolutions)
1 word of Greek origin via French, a learned borrowing that is somewhat masked. Also fun is the related word "glamor", so let no-one tell you that grammar's not glamorous.

The dictionary has lots of French words, but most of the words we use most of the time are English words. Even if we ignored repetition, it'd only reduce the degree of English's win, and not the amount. Most of the time people talk you get the same result. (Prepared speeches on academic topics are the most likely to be different.)

(Errors might have crept into that; I did it mostly on memory rather than by consulting a dictionary. I also might have missed words

Jailbreak!!

[evw]

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

Re:Jailbreak!!

[Winckle]

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

[larry bagina]

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

[tuffy]

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

[QRDeNameland]

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

[despisethesun]

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

[Anonymous Coward]

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.

Re:Jailbreak!!

[Fweeky]

If only Rockbox got half-decent battery life, it would be the perfect replacement for Apple's firmware Erm, it's pretty half-decent right now. From an old commit message:

"6 Aug 17:26 - Jens Arnold - firmware/target/arm/system-pp5002.c - Reduced battery consumption on PP5002 targets (iPod 1st/2nd gen and 3rd gen). Now rockbox battery runtime is better than OF, verified on 2nd gen :-)"

Even on targets where it's not quite so optimized, it's typically reasonably comparable.

Re:Jailbreak!!

[Anonymous Coward]

No, they simply wanted to foist their own proprietary formats upon users and thus tie them down to the iPod platform, as with their lovely DRMless music from iTMS, they're bastards and we wouldn't accept it from anyone else but people just seem happy to be shafted by steve and co.

Re:Jailbreak!!

[empaler]

I installed this but never really use iTunes for anything except syncing my Audio books to my iPod, but here:
Xiph.Org QuickTime Components. Should do the trick.
HTH :)

Re:Jailbreak!!

[despisethesun]

I own a 4th gen, and it's still not that great. I hadn't checked their wiki recently, but it looks like they're close to the 7h mark for mp3s and over it for FLAC. Better than it was, but still not stellar. If I were upgrading my battery, I would make the switch, but not otherwise.

Re:Jailbreak!!

[Fweeky]

Do these components support metadata yet? Last I heard, Apple made it pretty much impossible.

I dread to think what sort of a mess their plugin architecture is like..

Re:Jailbreak!!

[thePowerOfGrayskull]

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. Sure there is - haven't you heard about the security flaw in FLAC? Pure foresight, man. Pure foresight. I'm gonna go buy me some Apple stock.

Re:Jailbreak!!

[lazyforker]

Only if you can get an app that uses libFLAC onto the iPhone.
AFAIK iTunes doesn't play/support FLAC files natively so I'm guessing the iPhone doesn't either.

The best thing about these vulnerabilities

[Anonymous Coward]

Is that they're still lossless.

losslessly compressed

[Romancer]

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?

Re:losslessly compressed

[Locklin]

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

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

[CastrTroy]

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

[Phlegethon_River]

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

[tuffy]

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

[recoiledsnake]

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

[sseaman]

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.

Re:losslessly compressed

[wizardforce]

look up lossless compression on Wikipedia, it explians it quite nicely.
http://en.wikipedia.org/wiki/Lossless_data_compression

Re:losslessly compressed

[belmolis]

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

[BlueParrot]

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.

Re:losslessly compressed

[syousef]

Yes, and JPEG is lossy too. I take a lot of pictures (20,000+ between my wife and I on our 3 week honeymoon, and that's because the weather is bad.) If it matters I shoot RAW. However if I'm fiddling I stick with JPEG, encode with good quality and don't continually make changes and re-save, and in MOST practical cases there's no difference. If I really REALLY want to make lots of edits I'll save the original to TIFF and fiddle with it till I'm happy, and then and only then save to JPEG.

With audio it's the same. If it's THAT important or you're going to edit/mix (assuming it's legal), don't buy a lossy product (MP3/AAC/WMA/OGG). If you're just going to listen to it, it probably doesn't matter in practical terms so long as the bit rate is good enough (e.g. you don't want 128kbps for classical, probably 192 and up). There are of course people who'll insist they can tell the difference etc. That's their perogative. I'll stick to my dirt cheap 5.1 surround logitech X-530s and dirt cheap bargain shop cables and be happy as a pig in mud.

Re:losslessly compressed

[fishbowl]

I don't think anyone has ever claimed that the compression artifacts from, e.g., MP3 and OGG, are not audible.
It's quite obvious, particularly in the high frequency content, when you are listening for it. The distortion
is not only in the frequency domain but also in phase. It's well within the threshold of human perception, even
for middle-aged guys, except maybe people who shoot guns daily or who work on jet engines.

I've ruined MP3 for many people just by suggesting what to listen for.

On the other hand, there is no loss whatsoever with FLAC. It's good enough for use on the production side (security
issues notwithstanding.)

Audio production machines tend to be dedicated hosts and not even plugged into any network anyway...

Re:losslessly compressed

[MojoStan]

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. I think it's also helpful to compare the size of FLAC files compared to typical MP3/AAC/WMA/OGG files (in kbps since that's the way many users think nowadays). According to FLAC's site, FLAC typically compresses CD audio to about 54% of its original size.

• Uncompressed CD Audio: 1411.2 kbps
• FLAC at 54% compression: 762 kbps
• "Very high quality" lossy compression: 256 kbps
• "High quality" lossy compression: 192 kbps

So FLAC's big drawback is filesizes 3x the size of 256 kbps files and 4x the size of 192 kbps files. For me, it's worth it.

Re:losslessly compressed

[Deb-fanboy]

They have special algorithms that are much better at recognizing patterns in wav files

the usual principle (I am not specifically aware of the details of FLAC) is that you have the algorithms which recognise patterns as in quote above.

For a lossy compression that might be close enough and therefore information about the patterns can be sent, which involves much less data than the original.

For lossless compression the patterns might be derived as before, and then the difference between the original and the lossy-compressed patterns is also recorded. The lossless compression works because by combining the compression and difference you get the exact same waveform as the original but it takes less data than just recording the original wave data.

Re:losslessly compressed

[jericho4.0]

I take a lot of pictures (20,000+ between my wife and I on our 3 week honeymoon, and that's because the weather is bad.)

I first read that as "We stayed in the hotel and shot lots of porn"

Re:losslessly compressed

[Anonymous Coward]

I take a lot of pictures (20,000+ between my wife and I on our 3 week honeymoon...

Sorry to be insulting, but don't you think it's a bit sad? On average one or the other of you were taking a picture every single minute of every waking hour you were away. Did you have time to actually appreciate anything you were doing/seeing/eating etc. while you were continually fiddling with your cameras?

Re:losslessly compressed

[syousef]

I first read that as "We stayed in the hotel and shot lots of porn"

Well I have plenty of proof that's not the case. For starters my balls are in tact (my wife's not a fan of porn), then there's the pics themselves.

Re:losslessly compressed

[syousef]

don't you think it's a bit sad? On average one or the other of you were taking a picture every single minute of every waking hour ...says a mindless accountant/statistician type. Ever heard of cameras that take more than one frame a minute?

We had lots of fun. Drove 6000km....saw sites you wouldn't believe, and couldn't understand.

Oh well what do I expect out of a/c

Re:losslessly compressed

[Anonymous Coward]

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

There's likely a small overhead for the FLAC meta information, but most compressors are smart enough to just store the data "as is" if compression attempts would increase storage requirements.

Re:losslessly compressed

[I'm Don Giovanni]

"If you rip a Audio CD to MP3,AAC,WMA or OGG that is lossy compression."

Well, you can rip an Audio CD to WMA Lossless or Apple Lossless (OK, the latter isn't actually AAC, but a user will see it and treat it as such), which give about the same compression ratio as FLAC.

Re:losslessly compressed

[mvdwege]

(e.g. you don't want 128kbps for classical, probably 192 and up). There are of course people who'll insist they can tell the difference etc.

Hell no. If you have had any amount of classical music training, lossy compression is immediately recognisable. And over a decent set of earplugs, I can tell the difference just fine. Hence why my classical is all encoded in FLAC.

Mart

Re:losslessly compressed

[syousef]

I bet you can tell the difference between those gold cables and standard cables too. Each to their own I guess. Me, I'm glad I can't. Makes "good" music affordable.

Re:losslessly compressed

[mvdwege]

And from the fact that you have to resort to a strawman I deduce that you have no argument, aside from having a tin ear.

Mart

Re:losslessly compressed

[rant64]

From the flac.sourceforge.net FAQ: "the encoder is looking for functions that approximate the signal. Higher settings make the encoder search more to find better approximations." What is stored in the FLAC file looks like some mathematical function approximating a given audio waveform, together with some 'corrections' that, when applied to the function, result in the original waveform. The less information there is in a sample the less 'correcting' needs to be done and the more the math function alone will be able to re-create the original sound. Silence or nice sines result in excellent compression. Noise can hardly be compressed at all. Regular music is somewhere in between. Compressing a WAV file into FLAC and back into WAV results in exactly the same digital waveform.

Re:losslessly compressed

[syousef]

I love it, whining about a supposed straw man while in the same sentence throwing the good old "tin ear" insult.

Well Mr. Golden Ear, I'm glad you're always able to listen to your music in the dark and quiet so as to be able to hear those subtle nuances. Personally I don't want to spend thousands of dollars on stereo equipment to hear that last subtle nuance. All the evidence points to requiring that sort of equipment at a sufficiently high bit rate. So for me the whole exercise is pointless. Like worrying about that tiny JPEG artifact in a photo that's not even going to be seen unless you zoom in on a picture or print poster size. I have much better things to do with my life than worry about MP3 artifacts. To me MP3 is amazing. Under $50 of drive space to have your entire music collection at your fingertips, or under $200 for a decent portable music player that stores the lot. I can listen to what I want when I want without having to hunt down or carry a suitcase of CDs. How many players play decent lossless formats again? Thank goodness for my "Tin" ears.

Re:losslessly compressed

[syousef]

Here you go. Found something interesting for you. Have a ball:

http://www.maximumpc.com/article/do_higher_mp3_bit_rates_pay_off?page=0%2C1

Re:losslessly compressed

[mvdwege]

What supposed strawman? I point out that someone with classical music training may well be able to hear the difference between lossless and lossy compression on a classical piece, and you bring up a comparison with audioph00l-targeted gold-plated cables. How in the world you imagine that that is not a strawman defies logic.

And your supporting argument is an unscientific study by Maximum PC? A study that did not even include classical music?

I take back the tin ear comment. It is obvious that there is another reason for your stupid comment: you're an idiot.

Mart

Re:losslessly compressed

[syousef]

Oh please exactly how many double blind trials have you done with properly encoded music? At least I pointed you at something. If you wish to criticize my source you're welcome to provide a better one than just your own say so. \At this point of course in an argument with someone like you, the typical answer is "It's not worth my time. Go look it up yourself".

In any case it doesn't matter how scientific a study I point you to, you're clearly a member of the audiophile religion. You'll continue to buy overpriced equipment and encode your music in obscure formats that will be difficult to read in a decade or two because some little club has told you they're better. Do what you have to. The manufacturers love your kind and it subsides moderately priced equipment I'll happily buy. I should be thanking you.

It's a "supposed" straw man because you make it very clear that with no science backing your point of view either you'd be the sort of person who takes a claim about $4000 cables making a big difference seriously. Are you going to tell me otherwise?

You're also quite liberal with the insults and personal attacks, while you have less science backing you than I do. I don't need to wish harm on you or insult you. You're clearly doing a very good job of harming yourself without me adding to your misery or the world's. So instead, have a lovely day.

Think like a .zip file

[samwh]

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

But I thought that this didn't happen with FOSS

[Foredecker]

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

[Locklin]

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

[Phlegethon_River]

He works for them, check his webpage.

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

[stevenvi]

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

[Crypto Gnome]

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

[dedazo]

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

[Phlegethon_River]

Or his comment where he said he was a Microsoft Developer, either/or.

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

[onefriedrice]

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

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

[SanityInAnarchy]

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

[Tweekster]

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

[BlueParrot]

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

[totally bogus dude]

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

[beav007]

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

[grcumb]

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

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

[Tribbin]

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.

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

[hcmtnbiker]

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.

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

[EveLibertine]

Your understanding is wrong. It's not that this "isn't supposed to happen" it's that it should tend to happen less often with a properly maintained FOSS project.

"FOSS folks are not any better, or worse, than Microsoft, Apple, Sun or IBM developers" Yes they are better. And they're worse too. It depends on what you're specifically talking about. You can't pretend to be serious about a 1:1 comparison between any two of these. But, you're also talking about people here, and yes, all people make mistakes, but it's pretty trivial to be pointing that out.

Thanks though, for the quality full disclosure at the bottom of your statement.

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

[Almahtar]

So this is really ironic - Its my understating from reading hundreds and hundreds of /. posts that this isn't supposed to happen with FOSS. Then you misunderstood.

Who did the code reviews? eEye Digital Security.

Who did the security reviews? eEye Digital Security.

Who did all the threat modeling? I'll give you three guesses.

The security impact of open source software is not that it has less bugs, but that they get found because people can analyze the source. Read this article and you'll see that's exactly what happened. It's good news.

You will have bugs in your software, and they will be found. The difference is are they found by 'good guys' that will warn you and help you fix it or are they found by 'bad guys' that root your system?

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

[Anonymous Coward]

How long will it take for the libFLAC flaws to be fixed?

As reported in the article, libFLAC is fixed already.

How does this compare to closed-source applications with similar flaws?

http://ask.slashdot.org/askslashdot/07/11/19/2121226.shtml

An infinite time, apparently.

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

[Anonymous Coward]

From the parent's website: This page was last updated on Thursday December 25'th, 2003 . Yep, he's a MS developer all right.

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

[Anonymous Coward]

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. There are contradictions in your post. So does FOSS development process will result in bug-free secure software or not? Please answer in YES or NO.

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

[Anonymous Coward]

Now, how did this ship? Who tested it? Who did the code reviews? Who did the security reviews? Who did all the threat modeling? Great questions, and with FOSS, you might have a chance to get answers to those questions. When was the last time Microsoft released that kind of information?

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

[dedazo]

This bug was discovered by third parties because they had access to the source

That's irrelevant, since you don't need the source code to find buffer overflows. It just reduces the time needed to find them.

The bug is already fixed

And a patch has been applied by... everyone?

Even on still vulnerable systems it wouldn't give you root access

You don't need root access to turn a machine into a spam zombie, which is the growth market for trojans nowadays.

It would have to rely on special plugins or user action

We all know users don't install plugins or take actions. Stupid actions, even.

e)The problem is clearly described and documented allowing users to take precautions

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.

Compare this to a vaguely described bug

This doesn't seem vage to me.

enabling arbitrary webpages to compromise kernel space

Kernel space? Hardly. Read the exploit description. It's a bad exploit though.

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

[godless dave]

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.

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

[lnjasdpppun]

Compare this article and one posted earlier (http://ask.slashdot.org/article.pl?sid=07/11/19/2121226) to see the difference FOSS makes.

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

[howlingmadhowie]

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

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

[Anonymous Coward]

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.

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

[andy.ruddock]

Have you stopped beating your wife(/husband/girlfriend/boyfriend/so) yet? Please answer YES or NO.

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

[huge colin]

That's irrelevant, since you don't need the source code to find buffer overflows. It just reduces the time needed to find them.

A reduction in the time needed to find such a bug is the best thing you could hope for. And, oh, gee - that's exactly what access to the source code gives us.

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

[marcosdumay]

"That's irrelevant, since you don't need the source code to find buffer overflows. It just reduces the time needed to find them."

Yeah, and with infinite time a monkey can also be as good as Shakespeare.

"And a patch has been applied by... everyone?"

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.

"We all know users don't install plugins or take actions. Stupid actions, even"

Well, it is better than the computer taking stupid actions automaticaly...

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

[syrinx]

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.

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

[Anonymous Coward]

do you know how many ten year old bugs are sitting in Windows or IE which Microsoft refuses to fix?

Just One. Windows.

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

[Slashcrap]

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.

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

[I'm Don Giovanni]

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.

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

[howlingmadhowie]

do you deny that the peer-review happened and the bugs were found?

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

[I'm Don Giovanni]

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.

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

[howlingmadhowie]

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.

You're right

[QuantumG]

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.

Comment removed

[account_deleted]

Comment removed based on user account deletion

DoucheBag Shut Your Fucking Mouth

[Anonymous Coward]

DoucheBag Shut Your Fucking Mouth

Old McDonald Had a Farm

[Lachryma]

eEye worked with US-CERT to notify vulnerable vendors.

If this happened over email, one could consider it eEye e-I/O.

Re:Old McDonald Had a Farm

[Anonymous Coward]

That post should be taken out back and shot.

Fixed in Ubuntu

[coolhelperguy]

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.

Re:Fixed in Ubuntu

[Anonymous Coward]

I'm glad I don't use Ubuntu. An fixed version for Arch Linux was released over a month ago* and I installed it on the 13th Oct. TBH, I would have expected better from a distro like Ubuntu. Leaving an exploit unpatched for over a month I expect from Microsoft, but if Ubuntu want to market themselves as more secure than Windows shouldn't they try harder to get security updates out in a timely fashion. Checking the Ubuntu website they don't seem to be marketing themselves based on security at all, but they should still provide faster updates when the issue has been fixed upstream.

*The build date on the package info say built on 8th Oct can't be sure of when it was uploaded to the mirrors.

Re:Fixed in Ubuntu

[Anonymous Coward]

I've just had a look at the first linked article (eeye.com) which says the vulnerabilities were only patched a few days ago, so perhaps my rant was unfair to Ubuntu and I'm wrong. I had previously only looked at the second linked article (heise-security.co.uk) which says the vulnerability was fixed in libflac since flac version 1.2.1 which was released 2 months ago, so does anyone know what is correct and if the vulnerability is really fixed in flac 1.2.1?

open-source

[Anonymous Coward]

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

Phew

[Frogbert]

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

Re:Phew

[dkalley]

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,trader's den, etree , and dime a dozen) 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.

Re:Phew

[mqduck]

Ironic since I read this article while listening to a just downloaded Devo show in flac format. If this was a recent Devo show, do you have a link?

Worst possible choice.

[SanityInAnarchy]

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.

Queue the open source apologists...

[ComputerPhreak]

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.

Re:Queue the open source apologists...

[pclminion]

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.

Re:Queue the open source apologists...

[QuantumG]

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. Yeah man.. and, by your analogy, stop making murders!!

Idiot.

Re:Queue the open source apologists...

[Re-Pawn]

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?

Re:Queue the open source apologists...

[pclminion]

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.

Re:Queue the open source apologists...

[ComputerPhreak]

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.

Re:Queue the open source apologists...

[Anonymous Coward]

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.

Re:Queue the open source apologists...

[fishbowl]

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

Re:Queue the open source apologists...

[fishbowl]

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

Re:Queue the open source apologists...

[jb523]

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?

Re:Queue the open source apologists...

[LordLucless]

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.

Re:Queue the open source apologists...

[Anonymous Coward]

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.

Re:Queue the open source apologists...

[my_nickname_was_alre]

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.

Re:Queue the open source apologists...

[marcosdumay]

"When is the last time you were driving and the road just COLLAPSED? The bridge fell down?"

When was the last time you saw a bridge standing up after a willfull, informed, and competent attempt to put it down?

Re:Queue the open source apologists...

[silent_artichoke]

I am NOT going to your house for Thanksgiving.

Re:Queue the open source apologists...

[Night Goat]

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.

Re:Queue the open source apologists...

[Just Some Guy]

When is the last time you were driving and the road just COLLAPSED?

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?

guard pages, bit masks, and so on: better

[r00t]

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

[Anonymous brave dude]

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

[r00t]

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.

Re:guard pages, bit masks, and so on: better

[pclminion]

None of what you just described counts as a "sanity check." It's more like putting an immensely complicated band-aid on the problem so that when things do explode they explode in a predictable way. This can be a good thing in certain fields. If failure of your software might cause somebody's death, then yes, you want complete assurance that things cannot silently go wrong. But failing that, this is nothing but a poor substitute for good coding practice.

If you have so much doubt in your own code, why do you trust yourself to correctly execute this complex plan? "Well, I package it up in a function so I only have to get it right once." Yeah... Ever thought of applying that concept to, I don't know, THE REST OF YOUR CODE?

Re:guard pages, bit masks, and so on: better

[sowth]

Aren't we prideful. Do you work for Microsoft or something? Everyone makes mistakes. In the real world, you should program in as many sanity checks as you can. Over compensating for potential problems will usually lead to more secure and stable programs, or at the very least make it fail in a less catastrophic way.

Expecting sanity checks to be done elsewhere and not covering your ass leads to absurdly buggy programs and security compromises, which is happening all too often in so called "professonal" software these days. Twenty years ago, they probably would have been laughed out of the market and/or sued into the ground for selling the stuff they call software these days...

Re:guard pages, bit masks, and so on: better

[pclminion]

Aren't we prideful. Do you work for Microsoft or something? Everyone makes mistakes. In the real world, you should program in as many sanity checks as you can. Over compensating for potential problems will usually lead to more secure and stable programs, or at the very least make it fail in a less catastrophic way.

Where did I say we didn't need sanity checks? What I said was, this DOESN'T EVEN COUNT as a sanity check. You could do all this crap so that you feel comfortable AVOIDING real sanity checks, OR, you could check if the index you are about to reference is in range or not. THAT'S a sanity check. I really can't imagine how you read the complete opposite of what I meant.

What r00t is suggesting is like pointing a gun at your wife but hey, at least you made sure she was wearing a bulletproof vest. What I'm suggesting is to not point the gun at your wife at all.

Re:guard pages, bit masks, and so on: better

[Lehk228]

sanity checks have to go at each point writing to the buffer. a guard page only needs to be placed once per buffer

Re:guard pages, bit masks, and so on: better

[Follis]

Got any other nifty techniques up your sleeve?

Re:guard pages, bit masks, and so on: better

[pclminion]

sanity checks have to go at each point writing to the buffer.

Answer 1: Yeah, writing good software requires effort.

Answer 2: Centralize the code which accesses the buffer, and put sanity checks there. Then just call this code. I know this "structured programming" concept is pretty bleeding-edge stuff, being only 40 years or so old, but hey. Sometimes you just gotta learn something new.

Re:guard pages, bit masks, and so on: better

[Anonymous Coward]

You know that some languages will make sure you don't write outside of a buffer automatically, right? (Personally I program in Ada most of the time)

Re:guard pages, bit masks, and so on: better

[Anonymous Coward]

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.

What if you want it to work on a different operating system? You know, that other operating system that isn't based on Unix. I forget what it's called, but I hear it's quite popular.

Re:guard pages, bit masks, and so on: better

[Jeremi]

Twenty years ago, they probably would have been laughed out of the market and/or sued into the ground for selling the stuff they call software these days..

Nah, twenty years ago it wouldn't have mattered, because there wasn't enough Internet around to make botnets practical.

Re:guard pages, bit masks, and so on: better

[sowth]

I didn't say you claimed sanity checks weren't needed at all. I said this guy's proposal was a valid thing to add to a program and anything to make sure your program doesn't die by covering multiple bases is a good thing. You do realize all programmers make mistakes, don't you? Good programmers try to minimize the effects of those mistakes.

Was he really saying to do that instead of sanity checks? I didn't see anywhere in his post where he explicitly said to do the "guard page" trick and not ever do any other sanity checks. The way he started off by saying how people get sanity checks wrong, it seems to me he was saying you should do that in addition to normal sanity checks, so if you really screw them up, you will still have some protection... Then again, maybe he was just trying to offer a more simple and efficient solution for those who can't get it right or are worried about wasting CPU cycles.

At any rate, the "guard page" trick coupled with the bitmasking certainly looks like it would be difficult or impossible to write outside the buffer, unless there is some sort of exploit I didn't see. Unlikely since I am quite familiar with assembly language and binary operations. It looked easy and foolproof to me--assuming no one makes a typo or other mistake, but other sanity checks are just as vulnerable to those problems. Just read the strlcpy paper written by Todd C. Miller and Theo De Raadt. Here is a relevant excerpt:

There are several problems encountered when strncpy() and strncat() are used as safe versions of strcpy() and strcat(). Both functions deal with NUL-termination and the length parameter in different and non-intuitive ways that confuse even experienced programmers. They also provide no easy way to detect when truncation occurs. Finally,strncpy() zero-fills the remainder of the destination string, incurring a performance penalty. Of all these issues, the confusion caused by the length parameters and the related issue of NUL-termination are most important. When we audited the OpenBSD source tree for potential security holes we found rampant misuse of strncpy() and strncat(). While not all of these resulted in exploitable security holes, they made it clear that the rules for using strncpy() and strncat() in safe string operations are widely misunderstood.

It is difficult to write functions which prevent security flaws. The trick r00t proposed sounds as good as any. You may not catch many bugs with binary masking, but then that is what a debugger and assert() are for.

Your comments about it being "complicated" and a "complex plan" suggest to me you know nothing about boolean algebra or low level programming. Maybe you should learn a bit more before you write inflammatory comments.

Re:guard pages, bit masks, and so on: better

[Anonymous Coward]

GOT-table manipulation (and many other methods) are still possible with your technique. You should not allow the overflow to occur in memory to begin with.

Re:guard pages, bit masks, and so on: better

[rucs_hack]

Answer 1: Yeah, writing good software requires effort

Ah, that's where you're wrong. All you need to do is load this new microsoft mashup stuff, and perfect software materializes out of the ether and makes you a multi millionaire.

Don't you know anything?

Re:guard pages, bit masks, and so on: better

[chairthrower]

I really like the suggestion - you have something that is quite a discrete operation - you map a page of memory and then start a thread and do the operation and let it run in an almost sandbox. sounds really good for things like video decoding or packet protocol decoding where sanity checking does become expensive (ie video means lots of matricies and index checking is expensive). Its almost like spawning a seperate process (a la microkernel) to run the job except a lot more lightweight.

Is there any equivalent to mmap, mprotect and masking in windows ?

Re:guard pages, bit masks, and so on: better

[Nazlfrag]

djgpp has mprotect but no mmap, but malloc is all you need for his technique. It looks very robust at minimal cost. No such thing as too paranoid, look what just happened with FLAC.

Re:guard pages, bit masks, and so on: better

[ehrichweiss]

I've been programming for about 30 years at this point and I think his code is great. Low overhead, should work well, fast, and it PLANS FOR someone to attempt a buffer overflow and then takes all the sting out of it. Besides, it doesn't seem that complex by any means.

Re:guard pages, bit masks, and so on: better

[Anonymous Coward]

I've looked at the flac code. While your advice is probably good in general, I think in this specific case the issue is more plain old bad coding, and there were very few sanity checks that I saw.

Re:guard pages, bit masks, and so on: better

[r00t]

Sort of. It's not equivalent because Windows is unable to map one object on top of another. (with mmap, each page is treated separately so you can map something right into the middle of something else)

I posted it elsewhere, but forgot one thing. (can't rely on PageHeap, which is buggy)

First of all, the obligitory remark: shame on you for supporting that abusive monopolist.

1. Allocate pages with VirtualAlloc.

2. Protect pages with VirtualProtect. Use PAGE_NOACCESS, not the ever-so-tempting PAGE_GUARD which isn't persistant. Do not be tempted to use PageHeap, which sometimes (randomly? for small things?) does not do its job.

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.

Re:guard pages, bit masks, and so on: better

[Anonymous Coward]

Your comments about it being "complicated" and a "complex plan" suggest to me you know nothing about boolean algebra or low level programming. Maybe you should learn a bit more before you write inflammatory comments. Agreed.

The bitmasp is a simple assignment of a bitwise AND (x = x & 0xffff).

The AND operation is (of course) part of the X86 instruction set, so you'd be looking at an AND operation on the AX register, followed by a MOV from AX to memory.

These are very efficient operations to code and would have no noticeable impact on runtime in all but the most pathological or extreme cases.

Re:guard pages, bit masks, and so on: better

[Anonymous Coward]

"Masking" is nothing more than a bit-wise AND operation (& in C/C++). You make sure there is a 1 in the bit(s) you are interested in and a 0 in the others. For a 32 bit number, 0x0000FFFF as a mask will leave you with only the lower 16 bits and zeros the upper 16. Any mask pattern would work (a hex digit 0x0 - 0xF spans 4 bits), but non-intuitive masks would need serious commenting.

Bitwise logic and bit shifting operations are very fast.

For OSs that don't provide an API similar to mprotect or a processor that doesn't use an MPU, you could modify the technique to use a guard pattern instead of a read only guard page. Perform a 32 bit CRC on the head and tail guard blocks when you are done using the buffer (and before reusing if you don't actually do a free() for performance reasons).

Re:guard pages, bit masks, and so on: better

[The_Wilschon]

You missed the point. As I read it, GP wasn't whining about having to write a lot of code, but rather about how long that code takes to run. Every time you want to write to the buffer (which presumably happens quite a lot), you have to spend a few cycles making your sanity check. In some cases, every cycle is vitally important, and that is an unacceptable cost. Thankfully, in most cases, cycles are sufficiently cheap nowadays that bounds checking is realistic.

Re:guard pages, bit masks, and so on: better

[mcmonkey]

What r00t is suggesting is like pointing a gun at your wife but hey, at least you made sure she was wearing a bulletproof vest. What I'm suggesting is to not point the gun at your wife at all.

Yes, but have you met r00t's wife?

Re:guard pages, bit masks, and so on: better

[Lehk228]

Answer 2 requires discipline going forward and assumes that everyone who will ever work on a project knows what they are doing, bad assumptions. a guard page will make sure anyone who screws it up first goes out of their way to do so.

Re:guard pages, bit masks, and so on: better

[r00t]

No!

1. It is trivial to crack a CRC. That is not a crypto checksum.

2. Probably you get exploited before you get a chance to check. This depends on overflow severity, OS, etc.

There is a fix. You mask everything, not just when adding arbitrary untrusted offsets. This sucks.

Re:guard pages, bit masks, and so on: better

[Thundersnatch]

Twenty years ago, they probably would have been laughed out of the market and/or sued into the ground for selling the stuff they call software these days...

Actually, 20+ years ago, the code out there was MUCH worse than it is today from a security perspecitve. In the 1980s, my father once showed me the VAX-based system that ran the local hospital, because I was visting he knew I was "into computers." It crashed to a command prompt about 5 times during his demonstration, and he didn't once have to enter a password. I was salivating as a 12 year old proto-hacker, but was too scared to ever do anything (probably because of the security shock troops that descended on Broderick in War Games).

First, back then networks were in general far rarer and far less interconnected. The Internet was in relative infancy, and a lot of LAN-LAN bridging was done via modem. So security wasn't thought of much, because jsut getting connectivity was tough. The focus on secure computing was in preventing local privilege escalation, or privilege escalation from an attacker in the LAN.

Secondly, computers were a lot slower, so defensive coding checks and thorough input validation were often skipped in the name of efficiency.

Finally, attacks have gotten a lot more sophisticated over the years, with a lot of new techniques and a lot more automated tools. Writing secure C is nearly as tough as it was 20 years ago.

Re:guard pages, bit masks, and so on: better

[sowth]

Yeah, they didn't worry about security at all, but as I recall, they didn't crash nearly as much by themselves (at least personal computers) and the programmers usually went out of their way to optimize, instead of today where they seem to be looking for new ways to waste resources for no reason. Not even all of the eye candy can account for the absurd bloat they have today. Many things take longer than they did back with a 1 MHz processor, and I have a 1.2 GHZ supercomputer now.

I fired up khexedit and it took several seconds. Yeah, I didn't have any other KDE programs running, so it had to load a few daemons, but then why would a hex editor need any daemons. Don't tell me it's for cut and pasting. Even if it was, it shouldn't take more than a fraction of a second to load a cut and paste daemon. WTF???

right, I have backups...

[r00t]

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

No problem?

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

Those security tell me to get the FLAC out of here

[syousef]

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

This comment not modded up yet

[QuantumG]

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.

Fuck no, get a clue

[Anonymous Coward]

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.

Re:Fuck no, get a clue

[fishbowl]

>You can't have stack overflows in a file format, that doesn't even make sense.

You could have a file format that describes a Pushdown Automaton that ignores its boundary :-)

Re:Fuck no, get a clue

[Anonymous Coward]

or a file format which specifies chunks of binary which must be executed by the processor

A lot of these are app flaws, not flac flaws ...

[Anonymous Coward]

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.

love em M$ shills

[Anonymous Coward]

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

libavcodec is not affected, Heise is wrong

[unixmaster]

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

Re:libavcodec is not affected, Heise is wrong

[Zorandler]

I read it as "lossy" journalism on Heise part.

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

[QuantumG]

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.

Some things in life, money can't buy...

[Mr2001]

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.

Re:Some things in life, money can't buy...

[the eric conspiracy]

Additional hard drive to store your lossless music collection: $200.

More like $100.

Portable audio player that supports FLAC: $300.

I don't mess with these. There are no portable players in production that meet my needs. The only one close are the iRivers with SPDIF, and the models I would be interested in are not in production any more.

High-end headphones and speakers necessary to hear the difference between MP3/AAC and FLAC: $1000.

I was able to hear a big difference on a pair of $69 headphones and $20 sound card.

Card: Chaintech AV710
Headphones: Grado SR-60

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.

Watching all that equipment turn into one big zombie spambot as soon as you press "play": priceless.

I don't download flac's so that is not going to happen.

People really should do a bit of research before spouting off. It is pretty cheap to get excellent sound with a headphone based system out of a desktop computer. For a laptop you probably need a USB sound card which will add another $250 or so to the price. However the cost is NOT in the thousands, and the sound quality you can get for a relatively minor cost is jaw-dropping compared the usual iPod crap.

I have no idea why people put up with low bit rate MP3's, ear buds, lousy DACs and amps when it is so easy to do far better.

Re:Some things in life, money can't buy...

[CnlPepper]

The joke: --------->

Your head:
|
|
|
\/

+1 for anal stupidity.

Re:Some things in life, money can't buy...

[MostAwesomeDude]

5th generation iPods can be flashed with Rockbox or iPodLinux, both of which have FLAC support. Also USB sound cards are $40 and usually don't sound better than the cards bundled with most laptops, while also being slower than onboard chips. Finally, $200 will get you 750GB, which is adequate for music, assuming, of course, that you are storing lossless. Please "do a bit of research before spouting off."

Re:Some things in life, money can't buy...

[the eric conspiracy]

5th generation iPods can be flashed with Rockbox or iPodLinux, both of which have FLAC support.

5th gen (or any other) iPods have crappy DACs and poor amps. FLAC support is irrelevant for them.

Also USB sound cards are $40 and usually don't sound better than the cards bundled with most laptops, while also being slower than onboard chips.

USB sound cards that cost $40 don't sound better than the laptop sound cards because they have the same crappy amps and DACs as the laptop sound card. Get a $250 USB sound card like the iBasso D1 or Meier Move that are designed to drive high quality headphones and you are in a whole 'nuther league.

Finally, $200 will get you 750GB, which is adequate for music, assuming, of course, that you are storing lossless.

$100 for a 500 GB drive lets you store about 2000 CD's ripped to FLACs. That is pretty adequate and I think would satisfy most people.

Open your mind and your ears. The world of high fidelity is easy to experience. You won't want to go back to iPods, low bit rate MP3s and earbuds - I assure you.

Re:Some things in life, money can't buy...

[AikonMGB]

I am not myself an audiophile (though I do exhibit some audiophile tendencies); I thought the idea behind using gold-plated connectors was not that they sounded better, but because they stayed sounding the same for longer due to not corroding?

Aikon-

Re:Some things in life, money can't buy...

[the eric conspiracy]

but because they stayed sounding the same for longer due to not corroding?

Yes, it is a matter of reliability.

Re:Some things in life, money can't buy...

[Crypto Gnome]

I have no idea why people put up with low bit rate MP3's, ear buds, lousy DACs and amps when it is so easy to do far better. Hey man, quit knockin' my buds - they sound mighty-fine. At least they sound "very nice considering they're headphones, not a large pair of full-range speakers". Oh yeah and those in the know swear that ALL HEADPHONES SUCK unless you have headroom.

Re:Some things in life, money can't buy...

[Anonymous Coward]

Oh, FLAC is something audio snobs use. THank god! For a moment, I thought this was the format of all those files I was downloading from YouPorn.

Re:Some things in life, money can't buy...

[MostAwesomeDude]

I'm a musician. My ears can appreciate the difference between LAME and other MP3 encoders, and between LAME and Vorbis. That's about it. I'm too deaf for anything else. Also I'm a college student. When I can afford to eat something besides ramen, I'll reconsider.

Re:Some things in life, money can't buy...

[WWWWolf]

True audiophiles do not use FLAC encoding! A FLAC-encoded sound will have to be processed using a complex computational process, which will mean it will travel through very, very many transistors in the CPU before it hits the DAC on sound card, thus causing noticeable and very jarring latency in the sound. Even uncompressed files have headers which might affect seek performance. No, true audiophiles use raw sound data - indeed, raw sound files also save disk space, because they don't have headers.

Re:Some things in life, money can't buy...

[evilviper]

I thought the idea behind using gold-plated connectors was not that they sounded better, but because they stayed sounding the same for longer due to not corroding?

There are a few problems with that...

Have you ever seen a standard (nickel-plated, IIRC) headphone plug corrode? Speaker wires are a bit different, as cheaper stuff isn't plated at all, but in any case gold really isn't necessary.

Even if your headphone plugs and speaker wires are gold plated, what benefit do you get from it? The other end of the connection is very likely NOT gold-plated, so it's moot.

Re:Some things in life, money can't buy...

[evilviper]

High-end headphones and speakers necessary to hear the difference between MP3/AAC and FLAC: $1000.

I was with you until there...

Certainly with the very crappiest equipment you won't be able to tell the difference, but anything halfway decent will do. With a $30 pair of Aiwa headphones, plugged into my $15 SB Live card, I can pretty easily tell the difference between current lossy audio codecs, up to ~192K, and even more, MP3/WMA to any rate. The same is true with a $40 portable Sony CD/MP3 player + ear buds.

Where lossy becomes transparent, in my experience (at least without terribly high-end equipment, that I don't have) is with Musepack at --standard (~160k), or AC3/MP2 over 192k. Vorbis need not apply, because at any bitrate, it will occasionally have a few jarring artifacts. MP3/WMA have noticeable distortion at higher frequencies, no matter the bitrate. AAC omitted because faac/faad is crap.

Re:Some things in life, money can't buy...

[value_added]

Open your mind and your ears. The world of high fidelity is easy to experience. You won't want to go back to iPods, low bit rate MP3s and earbuds - I assure you.

And that's a good thing?

I've been there and back more than a few times, and not just with respect to audio. The more you know (and understand), the more discriminating you become. The more refined your preferences, the more the world around you looks likes like, tastes like, walks and talks like, and, to get back on topic, sounds like, complete shit.

Being discriminating is a good thing. Unless it makes you miserable, which it inevitably does. I'd recommend the OP stick to his earbuds. Chances are, he'll be happier not being able to tell the difference.

Re:Some things in life, money can't buy...

[pebs]

Watching all that equipment turn into one big zombie spambot as soon as you press "play": priceless.

A true audiophile is going to rip his music from vinyl recorded at 24-bit/96kHz, therefore there is no chance of getting exploited.

Re:Some things in life, money can't buy...

[hudsonhawk]

Etymotics and the like are considered "in-ear monitors" not ear buds.

Re:Some things in life, money can't buy...

[gillbates]

That was true before digital audio. Basically, anything with analog input and output - microphones, headphones, speaker cable, etc... is subject to signal degradation from corrosion. But even aluminum contacts do not corrode in normal residential environments, which makes it a little pointless. Still, when it comes to low power applications like microphones and headphones, you want the best contact you can get, and gold usually isn't that much more expensive. It happens to be better than copper with respect to electrical conductivity, and unlike copper, is more corrosion resistant.

However, we're seeing cables with gold plated connectors used for digital data - like monitors, digital video, etc... In these circumstances, it really doesn't make that much of a difference - the connectors tend not to corrode in the first place, and in the second, digital data transmission is much more tolerant of error than analog. By the time corrosion corrupts a digital signal, your connectors will have rusted to the jack...

Re:Some things in life, money can't buy...

[2nd Post!]

It's much cheaper to live in a moderate fidelity world, thank you very much!

Re:Some things in life, money can't buy...

[Anonymous Coward]

I use gold-plated connectors because I like how they look. I'd use copper, but copper doesn't retain that shiny look for very long.

security bugs that FOSS does not have

[r00t]

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:A lot of these are app flaws, not flac flaws ..

[Anonymous Coward]

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.

OMG PONIES!!!!

[Anonymous Coward]

         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

[awfar]

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.

Re:Thank you eEye and Devs

[pclminion]

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.

Yeah. A sincere thank you to the engineers who designed that bridge which fell down due to not one, but multiple catastrophic flaws. I'm sure you'll do better next time. This is the way engineering is supposed to work.

Wait, no it isn't.

Re:Thank you eEye and Devs

[jhol13]

NO!

This is NOT the way things are meant to work. This is the way Microsoft[1] meant things to "work". F/OSS should have higher standards. I wholly agree though that they don't.

[1] More and more F/OSS fanboys are singing the same song: "There is no security problem unless there is a virus on the wild".

P.S. Thanks for eEye.

don't need root for a rootkit

[r00t]

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:don't need root for a rootkit

[Gothmolly]

Except that this only affects YOUR processes, not root's. So you are not "so pwn3d". Ask your buddies on IRC for something cleverer next time. Nice OLPC troll though, it got you some karma.

Re:don't need root for a rootkit

[r00t]

That code gets injected into your xterm, gnome-terminal, konsole, eterm, screen, emacs, etc.

You'd better not ever do "su" or "sudo" from a shell in any of them. You wouldn't do that, would you?

Do you know what an "input method" is? It's a lovely way to play with your keystrokes, no matter what the app. It's normally used to enter things like Chinese characters... and to pwn you.

BTW, getting into your account is one step closer. Now the attacker is not only inside your firewall, but able to attack setuid binaries and the kernel itself. Any bugs just got exposed. At this point, a local exploit is as good as a remote exploit.

Not that any of this matters. A typical attacker wants your private data, your IP address, and your network bandwidth. Maybe they want your disk space too. Really, they don't need root. That's just for bragging rights.

Re:don't need root for a rootkit

[ookaze]

That code gets injected into your xterm, gnome-terminal, konsole, eterm, screen, emacs, etc. No it doesn't !!! At least as long as you don't launch any xterm from your gnome-terminal/konsole/eterm/whatever.
This little trick would change whatever apps you use that is launched from your shell session, which is just unlikely.
But wait, there's more ...

You'd better not ever do "su" or "sudo" from a shell in any of them. You wouldn't do that, would you? This is even more nonsense, as your little trick just won't work on a glibc drived system, meaning nearly every Linux OS out there.
This was fixed like more than 4 years ago !! Your LD_PRELOAD, containing slashes, will just not work at all and be rejected for suid binaries like su or sudo.
And if you don't put slashes, the library will be searched in the trusted paths put in your ld.so.conf.
So sorry to destroy your scary FUD. Not to say a rootkit is not possible, but it requires more than a vulnerability fixed years ago.

Do you know what an "input method" is? It's a lovely way to play with your keystrokes, no matter what the app. It's normally used to enter things like Chinese characters... and to pwn you. Except this is not launched from a bash session... at all. This is launched by your desktop environment, itself launched from a desktop manager, itself suid and not launched from your bash session. Just wow at your failed pwn methods though!

BTW, getting into your account is one step closer. Now the attacker is not only inside your firewall, but able to attack setuid binaries and the kernel itself. Just no, you're plain wrong. Kernel is safe as long as you're not root, and setuid binaries are safe too. You have to have an exploit on one of them, and no, LD_PRELOAD is not one.

Any bugs just got exposed. At this point, a local exploit is as good as a remote exploit. Well, I kind of agree, though it's not as simple as you make it out.

Re:don't need root for a rootkit

[Anonymous Coward]

Okay, it's Interesting when you post how many steps you'll have to take to protect yourself, but when someone points out it simply wouldn't happen in Windows it's Flamebait? Leaping Jesus people, I appreciate bias as much as the next near-perfect person like me, but let's take a little time to try to be *somewhat* objective and consistent?

Re:don't need root for a rootkit

[r00t]

No it doesn't !!! At least as long as you don't launch any xterm from your gnome-terminal/konsole/eterm/whatever.
This little trick would change whatever apps you use that is launched from your shell session, which is just unlikely. That's a very minor detail. First of all, I can just hit your desktop menu files instead. I can hit .xsessionrc or .xinitrc instead. Second of all, your desktop environment most likely USES THE SHELL to start things, and it is likely that at least some of the shell's files (not all) will still be used.

This was fixed like more than 4 years ago !! Your LD_PRELOAD, containing slashes, will just not work at all and be rejected for suid binaries like su or sudo. No, I don't mean injecting into su or sudo. I mean injecting into the terminal program. As part of the push for security, the setuid bit has been removed from many of these programs... eliminating the LD_PRELOAD protection. Oops.

In any case, with control of your menu system, I can substitute a look-alike program of my own design. That could be the terminal program. It could just be su or sudo. Heck, I could probably get away with making them mere shell functions.

Kernel is safe as long as you're not root, and setuid binaries are safe too. You have to have an exploit on one of them No shit. Suppose I do. I probably can't use it remotely... until I get into your regular user account.

Re:don't need root for a rootkit

[ookaze]

That's a very minor detail. First of all, I can just hit your desktop menu files instead. I can hit .xsessionrc or .xinitrc instead. Second of all, your desktop environment most likely USES THE SHELL to start things, and it is likely that at least some of the shell's files (not all) will still be used. Of course, but the point is that they are files controlled by root or by setuid programs, and you just can't access them with your method, without being root or using setuid programs, so your attempts will fail already. You're basically saying any user on a Linux system can escalate privilege to root like that which is just plain false.

No, I don't mean injecting into su or sudo. I mean injecting into the terminal program. As part of the push for security, the setuid bit has been removed from many of these programs... eliminating the LD_PRELOAD protection. Oops. Wow man, do you do that on purpose ? There's no way for you to be root from an ordinary user, unless you exploit a program running as root, or are promoted root by a setuid one. The setuid is dead with your little trick, only the exploit remaining. You can inject the terminal all you want, as soon as you reach a setuid code, your trick fails immediately. And there's not a lot of legal ways to become root with the shell. Even using pam will make this trick fail.

No shit. Suppose I do. I probably can't use it remotely... until I get into your regular user account. Well OK, but all vulnerabilities do not allow such a thing. Most have an hypothetical way of executing arbitrary code, but no exploit. This vulnerability was fixed weeks ago BTW, so it's very unlikely someone which uses the shell so extensively has not updated its FLAC already. I don't say a vulnerability isn't dangerous or doesn't allow what you say, but accessing a user account with this one is one work that is not so easy already, and escalating to root is another, that requires knowledge that has to be gathered through the first one, and is not an instant given. It's not so easy to gain root privilege illegally from a user account like you try to imply. If it was, it would have been patched long ago, which is what happened already.

Re:don't need root for a rootkit

[r00t]

Of course, but the point is that they are files controlled by root or by setuid programs, and you just can't access them with your method, without being root or using setuid programs No, these files reside in your home directory. They start with a ".", so ls won't show them by default. Many file managers won't show them either. They have names like ~/.gnome/* and such.

There's no way for you to be root from an ordinary user, unless you exploit a program running as root, or are promoted root by a setuid one. The setuid is dead with your little trick, only the exploit remaining. You can inject the terminal all you want, as soon as you reach a setuid code, your trick fails immediately. You missed it. Think about where "su" gets keystrokes from. I give you a hacked xterm. It is not setuid. It transfers keystrokes from the X server to the su program. It listens in, recording your password.

Most have an hypothetical way of executing arbitrary code, but no exploit. It's not really that hard. One has to be totally comfy with assembly, including assembling the bytes by hand.

How about

[Anonymous Coward]

Audio codec's security FLACking

patents, technically

[Anonymous Coward]

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.

Freedom is valuable in its own right.

[jbn-o]

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.

the whole point: it's NOT sanity checking

[r00t]

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

Re:the whole point: it's NOT sanity checking

[Anonymous Coward]

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.

It's like driving a car wearing a suit of armor because you crash into other drivers on a daily basis. Personally, I think you should just take a few driving lessons.

Re:the whole point: it's NOT sanity checking

[r00t]

Heh.

Studies show that nearly everybody thinks he is a better-than-average driver.

Kind of the same problem, no? Maybe this is why we require safety equipment.

Re:the whole point: it's NOT sanity checking

[heinousjay]

With an analogy that overwrought, it's pretty obvious you're just being a bitch. I'll correct it for you:

It's like wearing a seat belt because you have no control over what other drivers will do.

There, possibly the finest car related analogy on Slashdot ever.

Re:the whole point: it's NOT sanity checking

[lena_10326]

Studies show that nearly everybody thinks he is a better-than-average driver.

The thing is, half are right and half are wrong. In which half are you among?

Re:the whole point: it's NOT sanity checking

[Anonymous Coward]

Studies show that nearly everybody thinks he is a better-than-average driver.

That is entirely possible, if the worst drivers are really, really bad. Maybe you mean better-than-median driver?

Re:the whole point: it's NOT sanity checking

[Anonymous Coward]

The actual studies I've read went something like: X% of people consider themselves to be among the top Y% of Zs, where X >> Y. This turns out to be true for nearly any value of Z.

Re:the whole point: it's NOT sanity checking

[MrMr]

Not really, that would be true for 'better than median'.
When only a minority of people is responsible for traffic accidents, the majority is indeed better than average.
'nearly everybody' may be completely right about being a better than average driver...

Re:the whole point: it's NOT sanity checking

[lena_10326]

Rolls eyes.....

Re:the whole point: it's NOT sanity checking

[Ox0065]

Or else ask your 'life partner' if your code is secure

Re:the whole point: it's NOT sanity checking

[marcosdumay]

"It's like driving a car wearing a suit of armor..."

The only problem with your argument is that cars are reequired by law to be armored, since they colide every time.

If coders used half the number of techniques the car industry is required to use to avoid problems, we'd have much less problems.

Re:the whole point: it's NOT sanity checking

[ehrichweiss]

Except "better driver" is defined in the people's own terms, not simply whether they have accidents. So for them it might be that they always use their turn signals, brake early, leave 5 football fields of space between them and the car in front of them when moving at 15 mph, etc.

Re:the whole point: it's NOT sanity checking

[ultranova]

When only a minority of people is responsible for traffic accidents, the majority is indeed better than average.

Actually, from what I've seen, most dangerous situations are not caused by bad - unskilled - drivers, but by good drivers who at some point began thinking that accidents can't happen to them due to their l33t sk1lls. The problem is that the laws of physics don't care how skilled you are; if you drive a foot behind another car at 80 mph and that guy has to make a sudden stop, you simply won't have time to react, no matter your skill level.

It's not lack of skill which kills in traffick, but lack of humility.

Re:the whole point: it's NOT sanity checking

[Anonymous Coward]

true. people often also overlook the fact that nearly everybody has a greater-than-average number of legs.

Re:the whole point: it's NOT sanity checking

[The_Wilschon]

if you drive a foot behind another car at 80 mph. . . . . .then you aren't a good driver in the first place.

Re:the whole point: it's NOT sanity checking

[MrMr]

But if you accept different idiosyncratic criteria for 'better' depending on the driver, we could have 100% of the people driving 'better' than average, and it could still be true. That seems to be just my point, only more extremely put...

(Yes, I love to write idiosyncratic whenever I can)

I think you misunderstand the post

[empaler]

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.

Re:I think you misunderstand the post

[QuantumG]

no-one said it did.

Someone getting the ability to run arbitrary code on your machine is a security issue..

In Files?

[pete-classic]

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

Re:In Files?

[Anonymous Coward]

lolz, where the fuck then would the exploit be if not in files??

the solar wind mayhaps?

o_O

Re:Comparing A/D converters CD vs Sound card

[Technician]

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.

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

[Workaphobia]

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)

libavcodec does not need libFLAC

[uhmmmm]

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.

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

[QuantumG]

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!

Re:How to compare a FLAC to CD

[Technician]

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.

Monster Cable, my friend.

[Khyber]

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.

Re:Monster Cable, my friend.

[daBass]

Unfortunately, with HDMI cables they actually have a point. But that is more because HDMI is so lousy and requires it; cheap cables won't do on longer runs.

The sad thing is the professionals have HD-SDI which does long runs on cheap 75 ohm coax.

Re:Monster Cable, my friend.

[Khyber]

WTF, is it that hard to do? I just bought HDMI ends and used individually shielded wires (soldering was a bitch) and got no issues with noise, for maybe 15 bucks total and some labor. Maybe most of these companies don't know jack about extra grounds.

Re:Comparing A/D converters CD vs Sound card

[starwed]

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

Re:Comparing A/D converters CD vs Sound card

[Technician]

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,

Re:My Bad

[Technician]

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.

Trojanize me!

[tmh - The Mad Hacker]

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

There is no environment safe enough

[symbolset]

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.

where's the vitriol?

[buddyglass]

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?

Re:where's the vitriol?

[Qubit]

The WMV format is "restricted" or, as the FSF terms it, "defective", as a matter of its design. I'd show you some docs, but they're probably not freely available anywhere for me to access them...

There might be buffer overflow bugs in the FLAC reference software, but I don't think that the bugs are there by design.

(I agree that tags like "Micro$oft" probably aren't the most grown-up thing to post, but what would /. be without a little trolling here and there to provide a nice garnish to the stories?)

Re:where's the vitriol?

[Anonymous Coward]

No... if it were WMV we'd see total amazement at the vulnerability having been fixed months before the exploits in the wild, instead of after. Some would speculate that Microsoft had been secretly taken over by some other company.

on Windows

[r00t]

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.

Re:on Windows

[LO0G]

One other option is to use the built-in support for that functionality in that alternative operating system.

See here for more details on how to enable "PageHeap", which does exactly what you're describing.

Re:on Windows

[r00t]

That would be great if PageHeap were fully functional.

(well no, because ALL allocations would suffer the overhead, but the killer is that PageHeap does not fully work as advertized)

The OS randomly decides to not bother. I know not why. It's one of the mysteries of Windows.

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

[jhol13]

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.

Obligatory Simpsons

[MacDork]

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

I don't know why. It's a perfectly cromulent word.

Re:Obligatory Simpsons

[Snart Barfunz]

Words become established through use: there is no ISO committee to ratify the English language. Performant is a word because people are using it.

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

[QuantumG]

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

can't hit the GOT

[r00t]

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

fuck linux, and fuck you

[Anonymous Coward]

Windows has suceeded because it's the better OS.

UNIX is prehistoric shit

You are wrong

[SmallFurryCreature]

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.

Re:You are wrong

[buddyglass]

I'm not sure I buy this. Microsoft gets slammed any time they make a mistake, not just those related to DRM. You can bet that if they'd made one this colossal and announced it publicly they'd get raked over the coals ad nauseum. This would happen even if they had discovered and announced the flaw themselves and already had a fix ready, both mitigating circumstances which are not true with regard to this FLAC issue.

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

[ThirdPrize]

2. I hardly think libFLAC counts as an "essential Linux library". You are new here aren't you, boy.

Vuln in libavcodec ?

[Anonymous Coward]

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.

Three people affected

[nagora]

None of whom ever leave their mother's basements and the $200,000 of equipment they've bought on the recommendation of Hi-Fi magazines over the years and which they are now too old (25+) to actually hear any difference from.

TWW

OT Vista security

[pedestrian crossing]

No. Vista.

Yes. Windows.

root listens to audio?

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.

Re:OT Vista security

[CastrTroy]

Why even have an admin account? On the Mac Mini we have at work, root was disabled by default. With many Linux boxes, you create a root password, but never login as root, and if you try, you will get dire warnings about how bad of an idea it is. Most Linux boxes rely on sudo to get most of the administrative actions done, with some being left to su root. There's no reason to even have an admin account that the user can log in to through the GUI. Take away the ability for users to log in as root, and you'll take away a lot of the problems.

Re:OT Vista security

[pedestrian crossing]

More importantly, most Linux install programs guide the user through making both a root and regular user account as part of the install process.

That's where MS really dropped the ball. Their install wizard doesn't make sure that important step is taken care of.

When they are starting their computer for the first time, typical users just want to start using the system, so if you don't force them to create a regular user account, it's not going to happen.

The release of Vista provided MS with a golden opportunity to modify the startup wizard and eliminate a huge chunk of their security problem, but they chose not to.

It boggles the mind.

Re:OT Vista security

[zbabinga]

Yes, but you need to remember UAC. By default, an "admin account" is not as powerful as root on Linux, since it requires entering a password for performing administrative stuff. This is akin to a Linux user being a sudoer.

Which is how Ubuntu creates its first user, BTW.

Re:OT Vista security

[Sancho]

Actually, the admin account on Vista doesn't have to enter a password--they just have to click through the UAC control. If you try to perform an administrative action as a regular user in Vista, you'll have to enter a password as part of the UAC control.

Re:OT Vista security

[I'm Don Giovanni]

On Vista, admin accounts to run under "admin" rights, which is why you still get UAC whenever an app tries to do something that required admin rights. The difference between admin and standard accounts is that when a standard account gets a UAC prompt, the user must enter and admin password, but an admin only has to OK the dialog. And there are other things an admin can do that standard user can't, but still only after OKing UAC prompt.

The default account on Mac OS X is an "admin" account too, and it's been that way since it was released in 2001. But Apple's dlg may be considered more robust because someone logged in as admin still must enter an admin password to dismiss an authorization dlg. Then again, Apple's dlg is more easily spoofed.

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

I reckon that Apple and Microsoft did a hell of a lot more analysis on whether the default account should be admin or not than you did. Do you think that these companies just decide things on whim? You may find the reasons "unfathomable", but maybe it's due to your own tunnel vision.

Most people want to be able to do certain things without switching accounts, and an authorization dialog serves the same purpose and is faster. Apple and Microsoft understand that.

Re:OT Vista security

[Thundersnatch]

You have a Mac Mini at work? Where the hell do you work, at a Prada retail store or something?

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

[Anonymous Coward]

his UID is an order of magnitude lowers than yours, so suck my shit fucktard

Maybe I missed something ...

[Anonymous Coward]

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.

Another idiot gets modded up

[QuantumG]

Fuck Slashdot. Is there an algorithm for choosing the most stupid people to moderate or what?

Re:Another idiot gets modded up

[silent_artichoke]

No, there can't be. I get mod points twice a week... Oh, wait...

Mod parent informative!

[Mode_Locrian]

I know it's a bit off-topic, but thanks for those links!

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

[Night Goat]

who doesn't have a personal kernel exploit they haven't told Linus?

Well, since you're counting, I don't. So that's at least one person.

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

[CastrTroy]

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.

Many distros/OSs still using FLAC 1.1.2

[Anonymous Coward]

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

Re:Many distros/OSs still using FLAC 1.1.2

[Anonymous Coward]

It's not always about being up-to-date. Sometimes stability is more important.

Re:Many distros/OSs still using FLAC 1.1.2

[Anonymous Coward]

This is because the FLAC API changed between 1.1.2 and 1.1.3. Some applications have not been yet ported.

Stop using cheap cables.!

[LWATCDR]

"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!

I'd be interested to know....

[Amphetam1ne]

...exactly what a hacker would do with my Xbox once he's taken control of it.

Re:I'd be interested to know....

[Aleksej]

Show you goatse?

Re:I'd be interested to know....

[Amphetam1ne]

Goatse superimposed over Milkdrop... It's a scary thought.

Re:I'd be interested to know....

[Aleksej]

And I say you deserve it, but this comment of mine should be modded offtopic and flamebait.

a general guideline may be better

[r00t]

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.

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

[m50d]

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?

sanity checks can be exploitable

[r00t]

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.

Gotta love cross platform vulnerabilities

[Anonymous Coward]

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.

Re:Comparing A/D converters CD vs Sound card

[Sancho]

You even quoted all of the relevant parts. The entire portion of text that you qutoed:

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. When you're called out for not reading the post before posting a huge rant, you might actually go back and re-read the post just to make sure that you were wrong, rather than assuming that you were right. That's politician-like behavior.

iDefense Screwed Us

[Anonymous Coward]

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.

winamp flac exploit

[menixzero]

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

Re:winamp flac exploit

[Anonymous Coward]

that's why people use blink, it protects from weird crap like this real well. i run the blink personal at home too, it's got some really interesting stuff in it. my fav is the vuln assessment part since we use they're vuln scanner at our hospital, now i use it at home since its free.

check this out, this is kinda new: http://searchsecurity.techtarget.com/magazineFeature/0,296894,sid14_gci1280028_idx9,00.html

funny thing is, based on this testing, it looks like eeye's tool would be the only that will protect from this flac stuff on wind0wz. the rest of the tools did really crappy on the client-side and 0day tests.

you should post it somewhere...but dont use hushmail. >=]

Checking malloc() output, not just input.

[billstewart]

It should be perfectly safe to take unchecked input and malloc() that much data - unless something's seriously broken, if malloc can't get that much data, it'll return NULL as an error value. The problem is that if you don't check the return value, you can then go do something stupid with the NULL. (Some machines or operating systems at memory block zero - either putting zeroes there to be "helpful", since for some errors that really will do what you thought you wanted, or setting the memory page to non-readable to cause an error so you have to fix your bug.) If libFLAC isn't checking its malloc() returns, shame on it!

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.

fixed on Windows? Who knows!

[spage]

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.