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

Sanity checks:

[andreyvul]

Perform them.

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?

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

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

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

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

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

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

I bet someone will cop some flack for this..

[QuantumG]

HAW HAW HAW.

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.

The best thing about these vulnerabilities

[Anonymous Coward]

Is that they're still lossless.

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

[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: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

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

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

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.

Phew

[Frogbert]

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

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

[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

[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]

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

[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

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

Those security tell me to get the FLAC out of here

[syousef]

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

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

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

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

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.

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

[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

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

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.

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?

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

[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

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

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

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: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:Another idiot gets modded up

[silent_artichoke]

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

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.