Multiple FLAC Vulnerabilities Affect Every OS 360
Enon writes "eEye Digital Security has discovered 14 vulnerabilities in the FLAC file format that affect a huge range of media players on every supported operating system (Windows, Mac OS, Linux, Unix, BSD, Solaris, and even some hardware players are vulnerable). Heise points out a number of vulnerable apps that use the open source libavcodec audio codec library, which in turn relies on the flawed libFLAC library. These vulnerabilities could allow a person of ill will to trojanize FLAC files that could compromise your computer if they are played on a vulnerable media player. eEye worked with US-CERT to notify vulnerable vendors."
Sanity checks: (Score:5, Insightful)
Re:But I thought that this didn't happen with FOSS (Score:5, Insightful)
Re:But I thought that this didn't happen with FOSS (Score:2, Insightful)
Re:But I thought that this didn't happen with FOSS (Score:5, Insightful)
Secondly...
Where this is
Re:Time to write libraries like these in OCaml. (Score:0, Insightful)
Re:But I thought that this didn't happen with FOSS (Score:5, Insightful)
You misunderstood. Where FLOSS differs from microsoft is:
a)This bug was discovered by third parties because they had access to the source
b)The bug is already fixed
c)Even on still vulnerable systems it wouldn't give you root access
d)It would have to rely on special plugins or user action
e)The problem is clearly described and documented allowing users to take precautions
Compare this to a vaguely described bug in your rendering engine for animated cursors enabling arbitrary webpages to compromise kernel space, and this not being fixed for days or even weeks despite documented exploits in the wild.
Somehow I don't see the irony.
Thank you eEye and Devs (Score:5, Insightful)
This is the way things were meant to work, as so eloquently put elsewhere.
Re:Some things in life, money can't buy... (Score:3, Insightful)
More like $100.
Portable audio player that supports FLAC: $300.
I don't mess with these. There are no portable players in production that meet my needs. The only one close are the iRivers with SPDIF, and the models I would be interested in are not in production any more.
High-end headphones and speakers necessary to hear the difference between MP3/AAC and FLAC: $1000.
I was able to hear a big difference on a pair of $69 headphones and $20 sound 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.
Freedom is valuable in its own right. (Score:3, Insightful)
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... (Score:2, Insightful)
the whole point: it's NOT sanity checking (Score:5, Insightful)
My solution is far less complicated in total. Yeah, setting up a guard page isn't taught in Programming for Dummies. It's not a lot of code though, it's easy to test, and it's damn reliable.
People who write secure code try to avoid having to trust themselves to get everything right. People who write insecure code think that somehow, despite decades of failure, they'll get it all right. Look ma, no bugs! Sure...
Re:Some things in life, money can't buy... (Score:1, Insightful)
Your head:
|
|
|
\/
+1 for anal stupidity.
Re:Queue the open source apologists... (Score:3, Insightful)
Buggy software is a fact of life for the most part - it is created by humans and we all make mistakes.
When is the last time you were driving and the road just COLLAPSED? The bridge fell down? Your car spontaneously burst into flames? When's the last time you plugged an electrical appliance into a wall and got shocked? Last time your plasma television went nuts and shot laser beams at your cat? When's the last time the case of your box fan failed and the blades went flying through the air, decapitating 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:guard pages, bit masks, and so on: better (Score:3, Insightful)
Aren't we prideful. Do you work for Microsoft or something? Everyone makes mistakes. In the real world, you should program in as many sanity checks as you can. Over compensating for potential problems will usually lead to more secure and stable programs, or at the very least make it fail in a less catastrophic way.
Expecting sanity checks to be done elsewhere and not covering your ass leads to absurdly buggy programs and security compromises, which is happening all too often in so called "professonal" 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:the whole point: it's NOT sanity checking (Score:5, Insightful)
Studies show that nearly everybody thinks he is a better-than-average driver.
Kind of the same problem, no? Maybe this is why we require safety equipment.
Re:the whole point: it's NOT sanity checking (Score:2, Insightful)
It's like wearing a seat belt because you have no control over what other drivers will do.
There, possibly the finest car related analogy on Slashdot ever.
Re:guard pages, bit masks, and so on: better (Score:3, Insightful)
sanity checks have to go at each point writing to the buffer.
Answer 1: Yeah, writing good software requires effort.
Answer 2: Centralize the code which accesses the buffer, and put sanity checks there. Then just call this code. I know this "structured programming" concept is pretty bleeding-edge stuff, being only 40 years or so old, but hey. Sometimes you just gotta learn something new.
Re:where's the vitriol? (Score:3, Insightful)
There might be buffer overflow bugs in the FLAC reference software, but I don't think that the bugs are there by design.
(I agree that tags like "Micro$oft" probably aren't the most grown-up thing to post, but what would
OT Vista security (Score:3, Insightful)
Vista has some security improvements if Vista is used correctly, but MS still missed the boat in a big way.
The fundamental problem is people running under an admin account. Vista does not solve this basic problem.
When you install Vista (or run for the first time), it guides you through creating an account. If you actually read the dialog (hint: most people won't), it tells you that this first account is an admin account. The problem is that for most folks, 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:root listens to audio? (Score:3, Insightful)
I suppose I better expand on my "sudo is a waste of time" comment.
Sudo is generally configured out of the box to allow root access, making it little more than an alias for su. Actually configuring sudo to allow limited access to certain commands is fiddly, and often misses things (try running a root /bin/sh from sudo - works almost every time). Sudo is also a poor alternative to ACLs, or just setting up groups to control access to certain device files (which is often what a presumed need for sudo boils 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.