WinXP and WinAmp Vulnerable to Malicious MP3s

mypenwry writes "Foundstone, a Mission Viejo, CA security services company, is reporting several vulnerabilities that would allow malicious code embedded in MP3 and WMA files to be executed via WinXP and WinAmp. WinAmp versions 2.81 and 3.0 are vulnerable to buffer overflows via certain long ID3v2 tags when MP3 files are loaded. More troubling is the WinXP vulnerability: A buffer overflow exists in Explorer's automatic reading of MP3 or WMA (Windows Media Audio) file attributes in Windows XP. An attacker could create a malicious MP3 or WMA file, that if placed in an accessed folder on a Windows XP system, would compromise the system and allow for remote code execution. The MP3 does not need to be played, it simply needs to be stored in a folder that is browsed to, such as an MP3 download folder, the desktop, or a NetBIOS share. This vulnerability is also exploitable via Internet Explorer by loading a malicious web site. Explorer automatically reads file attributes regardless of whether or not the user actually highlights, clicks on, reads, or opens the file. Windows XP's Explorer will overflow if corrupted attributes exist within the MP3 or WMA file. Microsoft has issued a fix for this vulnerability. Nullsoft has posted fixed version of WinAmp 2.81 and 3.0 on their web site."

Comments

Uh Oh

[Jaysyn]

I hope no one tells the RIAA about this. They will be putting landmines in P2P soon.

Jaysyn

Re:Uh Oh

[Jugalator]

Uh oh. I think they already infected my computer when I d/l:ed some christmas mu*?DZMV*Z@@@@+++ KNEEL BEFORE HILLARY ROSEN +++""!##""!1!!1.

NO CARRIER

Re:Uh Oh

[Jugalator]

Why would your computer suddenly post and submit the words "NO CARRIER" before it was disconnected from the internet?

"NO CARRIER" jokes are a relatively common kind of jokes in nerd culture with a rather long history. ;-)

Re:Uh Oh

[WNight]

Modems used to print it when they lost carrier, so BBSes would watch for it and force a reset of that line, in case they had missed the hardware handshaking that was a little spotty in the old days. So, you'd convince someone to type NO CARRIER and they'd be kicked offline.

Some systems had a bit of an accounting bug where they tallied billing every hour, or when you logged off. If you were kicked off, they forgot. So some people would NO CARRIER themselves just before the hour.

Don't worry

[Psmylie]

This is all part of the Berman Bill.

Subject : Name : AC

[Anonymous Coward]

So, now when the users are afraid because of having virii in their mp3s, they are not stupid anymore?

Re:Subject : Name : AC

[Jucius Maximus]

"So, now when the users are afraid because of having virii in their mp3s, they are not stupid anymore?"

It's a good argument to get your friends to finally switch to ogg vorbis. I haven't encoded an mp3 since vorbis beta 3 (which was well before RC3) anyway.

Re:Subject : Name : AC

[doofusclam]

Thats a feeble excuse for switching to Vorbis regardless of the merits of this format. It's like saying "They found vulnerabilities in Apache so i'm gonna change my webserver to something else"

I'm sure there are exploitable buffer overflows in Vorbis too but as the format is so little used (relatively), hackers ain't looking for them. The day Vorbis is more popular than mp3 is the day the hackers change what they're targeting.

seany

Re:Subject : Name : AC

[Blkdeath]

I'm sure there are exploitable buffer overflows in Vorbis too but as the format is so little used (relatively), hackers ain't looking for them. The day Vorbis is more popular than mp3 is the day the hackers change what they're targeting.

Much like people used to claim in days of old that certain message base formats (BBS / FTN message 'echoes') were faster than others, this is also a bit of rubbish. The format doesn't contain vulnerabilities; the players that implement the format have vulnerabilities. It is, in point of fact, perfectly feasable to assume that the same, if only slightly different vulnerability could possibly be exploited with the Ogg Vorbis format.

Unchecked buffers (read: lazy/braindead programming and poor code audits) are at fault here. MP3 is merely the current carrier.

But you're right; it is a feeble excuse to switch formats. It would be more apt to suggest that people switch to a different player, or use a different operating system, but I'm not going to do that.

Re:Subject : Name : AC

[greenrd]

Any code that reads input from "untrusted" sources (you can argue about what that includes, but it definitely should include "arbitrary, random Internet sites") should be "bulletproofed" against every theoretically possible input. But no, the culture of programming is not set up to do things that way, in too many *cough*MS*cough* cases.

Re:Subject : Name : AC

[greenrd]

Ah well, I don't worry about that kind of thing - I code in Java, and I trust the soundness of the JVM and the libraries it depends on. Exploitable buffer overruns are pretty hard to code in Java!

"hack me baby one more time"

[sweeney37]

looks like listening to the newest Britney Spears album will result in more than just bad taste.

Mike

Buffer overflow yet again

[graikor]

Why hasn't Microsoft just changed the way it handles buffers to eliminate the weekly discovery of yet another buffer overflow exploit that compromises security? It's obvious to just about everyone else that any buffer that doesn't ignore excessive input will be a problem in the future - why does Microsoft insist on treating each one of these issues as though it was a totally new problem instead of making a global change to secure the OS from this kind of hack?

Re:Buffer overflow yet again

[Anonymous Coward]

because it's a feature !

Re:Buffer overflow yet again

[FortKnox]

I'm guessing that it require a retest of the entire OS (which isn't a half-bad idea).
Changing something THAT global could result in more harm than good.

Mind you, I think you are right, and that's what should be done; I'm just telling you what is (probably) on the architects/lead developers minds.

Re:Buffer overflow yet again

[Frosty Inc.]

Because it would cost a lot of money to design and implement, something Microsoft doesn't hav...

Oh, wait a minute...

Re:Buffer overflow yet again

[Beryllium Sphere(tm)]

This isn't exactly what you're asking about, but to Microsoft's credit they have added a flag to the compiler which adds a "canary" to the stack to detect stack-smashing. Better, the flag is on by default.

Changing "the way it handles buffers" is harder than it sounds, There's a huge amount of legacy code in shared DLLs, older operating systems and so on.

If Microsoft asked me to recommend a global change, I'd tell them to go through the agony of implementing least-privilege throughout their entire system architecture. That would be sheer hell, but at least it would contain the damage from whatever next week's security hole turns out to be.

Re:Buffer overflow yet again

[NineNine]

I dunno. Why doesn't Linux handle buffer overflows, also? There are always buffer overflow bugs in various apps, like Apache, the PHP mod, etc. Maybe there's no good way of doing it?

Re:Buffer overflow yet again

[stratjakt]

>> why does Microsoft insist on treating each one of these issues as though it was a totally new problem instead of making a global change to secure the OS

Palladium

Oh wait, you don't want that.

So what do you want?

Re:Buffer overflow yet again

[Blkdeath]

>> why does Microsoft insist on treating each one of these issues as though it was a totally new problem instead of making a global change to secure the OS

Palladium

Oh wait, you don't want that.

So what do you want?

Palladium is an attempt to secure what we do with our OS/computer, not an attempt to secure the OS/computer itself. It's Microsoft's belief that in a society that goes to war with totalitarian nations, implementing a totalitarian system of checks and balances will somehow;

1. Work effectively to combat the evils facing our virtual world, and
2. Be socially, morally, as well as legally accepted.

In order to secure the OS itself (and thus allow for their 'DRM' format files to be immune from such buffer overflows) would require an exhaustive audit of the entire Windows codebase, with emphasis on security rather than functionality / new features.

Re:Buffer overflow yet again

[__aanonl8035]

I just wanted to point people to
a project that tries to catch buffer
overflows under linux.

freshmeat entry
homepage

Re:Buffer overflow yet again

[NineNine]

Ah, you're new here. Here at Slashdot, every tiny thing is something to pontificate about, and every tiny problem is a major conspiracy/security hole in which The Man can exploit you/invade your privacy. "No big deal" isn't a very common phrase here.

Re:Buffer overflow yet again

[IamTheRealMike]

Well, there is, which is, don't insist on writing all your software in C and C++. Java/Python/Ruby/Perl/C# for instance aren't susceptible to this kind of problem.

Re:Buffer overflow yet again

[jpmorgan]

libsafe only protects you from buffer flows within parts of the standard C library.

It is not a sufficient solution to prevent programmers making mistakes.

Re:Buffer overflow yet again

[dubious9]

Ok, but what happens when you don't want to use all of that overhead? C is great because it has, AFAIK, the least overhead of any "high" level programming language out there.

This isn't the fault of the language, it's the fault of the programmer. How hard is it to do bounds checking?

Re:Buffer overflow yet again

[dubious9]

I'm not familiar with Ruby but, Python, Perl - powerful, but slow as they are interpreted

Java/C# - garbage collection and automatic bounds checking take overhear

Face it, when you are doing something that requires some real speed, you can't afford an idiot-proof language. OSs won't be written in any of those languages any time soon. Nor will programs that do heavy duty graphics

Sometimes even C++ has too much overhead. There is no out and out replacement that is better than c. Switching from c/c++ is simply not an option for many projects.

And for those projects that could be served by the languages you suggest, even if you write it in c, it's nobody's fault except the programmer. C is the problem here.

Re:Buffer overflow yet again

[dubious9]

errr.. maybe someday i'll hit the preview button.

C is not the problem here.

Re:Buffer overflow yet again

[Detritus]

It may be an obvious security flaw now, but it didn't used to be for many programmers. To mangle an old joke, "This program crashes when I type 514 characters into a text entry field!", "Well, don't do that!". It used to be common to assume that the user was not hostile and that the program was not getting its input from some random hacker on the Internet.

Re:Buffer overflow yet again

[dubious9]

sheesh! ... 'cause it's so complicated to use strncpy() instead of strcpy(), you know...

And I've been wondering about that. Why don't we just change strcpy()? Would that be breaking anything? Why hasn't it been changed already?

Re:Buffer overflow yet again

[timeOday]

Guess what's wrong with this code for an access member in an array class (assuming it's C++, except I had to use lt for "less than"):

const T & operator[](int i) { assert(i lt size()); return data[i]; };

Re:Buffer overflow yet again

[IamTheRealMike]

Well, in C# you can switch off garbage collection and bounds checking to get direct memory access for when it's really needed by pinning stuff. But yes, I know C isn't always appropriate. I think C is used in inappropriate places far more often than Python is used in inappropriate places though for instance.

Re:Buffer overflow yet again

[dvdeug]

C is great because it has, AFAIK, the least overhead of any "high" level programming language out there.

So your box is owned, but the people who own it get the most speed possible. Thanks.

C lets you write to the metal. Ada, and many other languages, lets the compiler write to the metal; even if you're writing to just one platform, it's likely the compiler writers knew more about how to get the best out of that metal then you do, and if you're writing to more than one platform, you can't optimize on the level that the compiler can. And a compiler can optimize "A : Integer range 1..10;" better then it can "int A;", because the first tells it more information. Higher level, an APL compiler can compile a matrix multiplication to the the most accurate and fast possible on the platform, whereas a C compiler can't change your implementation of the same.

Also, it's no good to get the least overhead if you don't use it. I wrote an Ada version of strings that was ten times faster then GNU strings. (It didn't have all the fancy binutils options, but I needed to extract the strings from a 10 GB hard drive image.) It was a simple matter of a slight algorithmic improvement, but they never made it. Until you're willing to go through and make all those improvements, you've lost the slight advantage that C would give you.

This isn't the fault of the language, it's the fault of the programmer. How hard is it to do bounds checking?

Right. Blame the programmer. Back in real life, we have no perfect programmers, and only a few excellent programmers, and are left with the average programmer to write most programs, and the average programmer very frequently forgets bounds checking. It seems better to fix the machines to work with the users, rather than try an obviously futile job of fixing every programmer out there.

Re:Buffer overflow yet again

[Rich0]

How do you know that there is not a bug in the compiler/library you are using in that language.

At least when using a language which does bounds checking, there can only be a finite number of errors in the libraries. When one is found and corrected, it fixes an exploit in every program complied using that library.

If you code the routines yourself in C, then it is up to you to find your own bugs. I have a hunch that most of the shared libraries on my linux installation are a little less buggy that a typical 100k line project.

Re:Buffer overflow yet again

[dvdeug]

automatic bounds checking take overheard

How much time, compared to hand bounds checking? And how much CPU time is worth a weekend of admin time cleaning up after a break-in?

Nor will programs that do heavy duty graphics

Most programs that do heavy duty graphics offloaded most of their code to the graphics card.

Sometimes even C++ has too much overhead.

Gee, like when? C++ was designed to have no overhead except when you use the new features. And metatemplate programming can massively beat procedural programming by doing at compile time what the procedural program does at execution time (or writes the same code a dozen times.)

Switching from c/c++ is simply not an option for many projects.

We've gone from OS's and heavy duty graphics to many projects. Furthermore, assembly has less overhead than C; you can frequently write the code in whatever language, and then take the 5% that actually takes time, and rewrite it in assembly, and beat anything that's straight C.

Re:Buffer overflow yet again

[NewtonsLaw]

Why hasn't Microsoft just changed the way it handles buffers to eliminate the weekly discovery of yet another buffer overflow exploit that compromises security?

I wonder if I should lend them my copy of Code Complete... oh, hang on.. :-)

Re:Buffer overflow yet again

[Pig Hogger]

Ok, but what happens when you don't want to use all of that overhead?

That's what ASSEMBLER is for.

won't affect most people

[tps12]

This is more of a curiosity than any sort of danger. Most of us, when we get a new mp3 file, give it a listen to make sure it's not mislabeled, doesn't cut off in the middle of the song, and sounds okay. We throw out or fix the ones that aren't up to our standards. So the number of people who would let one of these dangerous mp3s just sit there and be scanned is probably pretty small. And as is usually the case when something like this is discovered, they probably deserve what they get for being such idiots.

Re:won't affect most people

[Jucius Maximus]

"This is more of a curiosity than any sort of danger. Most of us, when we get a new mp3 file, give it a listen to make sure it's not mislabeled, doesn't cut off in the middle of the song, and sounds okay. We throw out or fix the ones that aren't up to our standards. So the number of people who would let one of these dangerous mp3s just sit there and be scanned is probably pretty small."

That average person does not notice when a backdoor app is covertly installed on their machine. As long as the mp3 is actually what they wanted, chances are they will keep sharing it.

The even more dangerous part is that someone could be downloading mp3s and LOOKING for these trojans. And as soon as they find one, they can just go back to the IP of the machine they got the file from and have an instant DDOS zombie!

Or even better, if I am an RIAA employed disturber-of-the-peace, I could create a bunch of these trojaned mp3s share them, and then whenever someone downloads it from my machine I could instantly use the backdoor to destroy their music collection. (But I'm sure the RIAA has already thought of that.)

Re:won't affect most people

[illtud]

So the number of people who would let one of these dangerous mp3s just sit there and be scanned is probably pretty small.

Read the Microsoft Bulletin (which I got yesterday). Opening a shared directory with one of these MP3s in will trigger the attack, or even previewing an email with one of these attached will execute it.

Here's MS own words:

An attacker could seek to exploit this vulnerability by creating
an .MP3 or .WMA file that contained a corrupt custom attribute
and then host it on a website, on a network share, or send it via
an HTML email. If a user were to hover his or her mouse pointer
over the icon for the file (either on a web page or on the local
disk), or open the shared folder where the file was stored, the
vulnerable code would be invoked. An HTML email could cause the
vulnerable code to be invoked when a user opened or previewed the
email.

It's a sad day when...

[Anonymous Coward]

...a machine can be hacked through the mp3 player. This is all not so Windows centric either, many software developers need to get a clue.

Re:It's a sad day when...

[xsbellx]

Definitely one of the more insightfull comments in a while. Exploits like this really speak volumes about the current state of software development, both at the application and O/S levels.

So click the update button

[AKnightCowboy]

Click the Windows Update button and reboot and you're fixed. Or if you're like many people, the fix has already installed during an automatic update check last night. This isn't really news unless Slashdot is merging with Bugtraq (Slashtraq? Bugdot?). Are we just posting this to bash Microsoft once again? Automatic updates were one of the best new features they added to Windows and they make life much easier. Oh and no, I don't wrap tinfoil around my head worrying whether Microsoft is going to invade my PC and lock me out of it.

Re:So click the update button

[Anonymous Coward]

"Are we just posting this to bash Microsoft once again?"

Yes.

Sincerely,
Linus

Re:So click the update button

[div_2n]

So if NT SP4 had been automatically updating servers and workstations everywhere, that would have been a good thing?

You couldn't pay me to have my system automatically update itself with patches tested quite possibly only from the company that created it.

I would rather my system be vulnerable for a day or two than have the contents of my hard drive obliterated.

What if some patch disabled a computer's networking? What is Ma an Pa gonna do when that is the only computer they have? Download a fix using broken networking?

IMHO, automatic updating is a monumental disaster waiting to happen.

Re:So click the update button

[MacAndrew]

Like another poster I am very wary of updates to anything. Not needing a security patch in the first place is a heckuva lot better than beta testing a hastily written patch for free. Then there are th people who get nailed in the interim.

Also, on my [platform] I have seen only a few security updates a year on a young OS, some addressing obscure services I don't even use. What's the deal with MS? Why sweep this under the rug?

I don't buy that automatic bandaids are the answer to hemmoraging code.

Re:So click the update button

[PinkStainlessTail]

Well, a lot of "power users" have disabled automatic updating and don't bother to check Windows Update. So they might have missed this.

Re:So click the update button

[Blkdeath]

IMHO, automatic updating is a monumental disaster waiting to happen.

I tried to submit a story about the most recent Windows Update debacle, but for some unknown reason it was rejected (I really wish they'd inform users WHY submissions were rejected; even if only a one-word description, like "duplicate", "absurd", "false", "flamebait", etc.), but anyways; it appeared to me that when Microsoft announced their Java VM vulnerability, so many canned installs of Windows XP and the older variants with Automatic Update patches applied were actually DoS'ing the Microsoft Windows Update servers to the point where my 3Mbit connection couldn't even get as far as "Scanning for updates ... ". It was a real nuisance, too, since I had six machines on the bench that day and a customer LAN with five machines that all required major updates (new installs of Win'98, ME, 2k, XP, and/or machines over 1-2 years old running v5 of everything, etc.)

Well, thanks to Microsoft I get to book another service call, likely for 2-3 hours on-site, where I'll update their machines (among other things, but the update will take time; 5 machines, all of them having to download and apply 20MB, requiring 4 re-boots, and there are no centralized images for such a small LAN).

Anyhoo.. </RANT>

Re:So click the update button

[aardvarkjoe]

(I really wish they'd inform users WHY submissions were rejected; even if only a one-word description, like "duplicate", "absurd", "false", "flamebait", etc.)

What gives you the idea that they would reject a story for any of those reasons? That sounds like a description of the front page to me.

Re:So click the update button

[Reziac]

PJ Connolly, who normally has better sense, was caling for forced security updates in a recent Infoworld newsletter. Here's how it went, and my response:

SecurityAdviser@bdcimail.com wrote:
As usual, I have a suggestion that's going to enrage a lot of you: Windows users would be better served by introducing a new category of mandatory updates, where you have 60 or so days to apply the patch, and if you don't, the computer's networking functions will be disabled. Savage, yes, but effective.

[my response]
And are you willing to take responsibility for everything that forced updates break? Are you willing to cover lost revenue for any resulting unexpected downtime or data loss? Which, as certain NT Service Packs have amply demonstrated, is a real risk.

What if *my* solution to a security issue was to entirely disable the vulnerable service -- and a forced update not only re-enables it, but worse, also introduces yet another vulnerability?? And of course with a NEW vulnerability, now I get to learn about it the hard way, because it's not yet a *known* risk.

What about forced updates that include a new EULA, a la recent M$ SPs??

Forced updates are not a solution. If anything, they are liable to ultimately be worse than the problem.

Re:So click the update button

[Blkdeath]

Maybe you're just spoiled with the 3Mbit connection and all, but there's no reason to be downloading the same patches multiple times off the Internet.

We use a transparent (cacheing) HTTP proxy for the bench machines, so the vast majority of Windows Update is cached (the rest aren't "proxy friendly"); but I can't apply the updates if I can't get to the Windows Update site itself.

A local cache, unless I can store it on a CDROM, keep it updated daily with the latest patches (major hassle), and cart it around with me isn't going to do me any good on location for a customer's LAN.

If that's too much work, go into Windows Update Catalog in your Windows Update and put all that shit in your download basket.

If you know of a simplistic way that I can keep all up-to-date Windows Updates available without having dozens of executable files to run manually (or even with a three/four stage batch file, due to the fact that so many of them require reboots), I'm all ears. I looked at their corporate downloads page, but it didn't list any updates for Windows XP, and now it appears to re-direct me to their primary Windows Update site. (As a matter of fact, that was one facet of the article I tried to submit; how to keep updated without having to rely on windowsupdate.microsoft.com).

Re:So click the update button

[homer_ca]

The corporate downloads page doesn't always list the latest patches. The Technet Security page works for XP Pro too, but you'll have to click through the security bulletins and then scroll down to the download links, so it's a hassle. Try Software Update Services. It's like a local Windows update server. It'll work for a corporate LAN, but not very useful for those one shot installs because it'll keep hitting your local SUS server for updates. Still better than phoning home to Microsoft since you control what patches are available.

Re:So click the update button

[Blkdeath]

The corporate downloads page doesn't always list the latest patches. The Technet Security page works for XP Pro too, but you'll have to click through the security bulletins and then scroll down to the download links, so it's a hassle. Try Software Update Services

That would work if not for our customer base; a lot of them (perhaps the majority) still run Windows 98/ME (don't want to pay, it works, etc.), and we wouldn't want to give public access to our server (for obvious reasons).

The sad truth is, there doesn't seem to be a way for a computer repair shops to update Windows without windowsupdate.microsoft.com. The nature of our business is either computers come in for a day (or two, or three) then leave again and sit behind dial-up, cable, DSL, or no Internet connection, else they're on company/home networks of varying degrees of complexity.

For 99% of the time, cacheing the updates with Squid seems to expediate the process, but like I said; it doesn't work when the site won't even let you scan for updates to apply.

Hrm... virus scanning my MP3 collection

[rickthewizkid]

Something tells me that my daily virus scan is gonna take a lot longer now...

Oh wait... it's a Windows problem... never mind...
RickTheWizKid
My purpose: to inject random comments...

How long before...

[bryhhh]

we see a worm exploiting this, remember the last worm that was executed without even opening a file.

Re:How long before...

[PetiePooo]

This cannot be a self-propagating worm ala Nimda or Code Red. Simply put, it requires user interaction. A user must browse to an infected folder in order for the shellcode to be executed.

Since a properly administered server is not also a client, it should not be affected, even if a rogue client dumps an infected MP3 onto one of its shares. That is until the admin logs in via TermServ and starts poking around.. but that's still user interaction.

Hmm.. I wonder. If a person does a search of MP3's, does viewing it in the search window run the exploit? I bet it does..

Re:How long before...

[PetiePooo]

Combined with another vulnerability, sure. But then this is just another way of transporting or hiding shellcode.

If you'll read your comment again, you said "run" mplayer2 bad.mp3. If you have the power to run arbitrary commands, why not just download and run your own exploit instead of having mplayer2 run some shellcode out of an MP3?

Why does this matter to /.-ers?

[toupsie]

You guys are all supposed to be using Ogg anyways! That way you can act like you are a snooty audiophile anytime a MP3 story is posted...

Re:Why does this matter to /.-ers?

[13Echo]

Most people don't use Ogg Vorbis for the quality. They use it for the license.

In high bitrate modes, there is little difference between properly encoded MP3s and OGG files. And high bitrate is what really matters, unless you are streaming over a low bandwidth connection (in which OGG is the clear winner due to size).

Maybe your comment would make sense if you were referring to something like FLAC from http://flac.sourceforge.net/ . MP3 and OGG are both lossy, so you really can't be a snooty audiophile if you use them. ;)

Re:Why does this matter to /.-ers?

[runderwo]

Remember that re-encoding a lossy compression codec (MP3) to another lossy codec (Vorbis) will ensure that, at best, the re-encoded files will sound no better than the original ones.

You would notice more difference if you encoded the OGG files from the original source, instead of from MP3s that have already been lossily compressed.

Don't even need to have the file local?

[Jugalator]

From Microsoft:

An attacker might attempt to exploit this in one of three ways:

* Host the file on a website. In this case, if a user were browsing the page containing the file and hovered over it with his or her mouse, the vulnerability could be exploited.

Eep!

* Host the file on a network share. In this case, if a user browsed to the network share and simply opened the folder which contained the file, it could cause the vulnerability to be exploited.

Gaah!

Also, it seems you can send an e-mail with the mp3 object in a frame (this is the third way of exploiting it) so you don't even need to click a link in Outlook / OE for it to be run. This shouldn't be possible on XP SP1 or a recently patched IE though.

Effects more then you realize

[nurb432]

From what it says, by then its to late.. As the act of verifying will let the malicious code take effect..

Unless i TOTALLY misunderstood....

The only thing funnier

[I Am The Owl]

would be if they embedded these in Jon Bon Jovi MP3s.

Re:Obvious reply

[archen]

All file formats are safe, it's just the programs that read them.

In defense of Microsoft...

[MacAndrew]

Oh, just kidding. :)

I would like to ask for factually-based opinions whether these innumerable highly dangerous security holes in MS software are more the result of the ingenuity of the hackers or the incompetence of the Microsoft design and testing process, or about 50:50. I am inclined to be prejudiced against Microsoft, so I would be REALLY interested in hearing reasoned defenses of their predicament, if such exist.

So, please, no MICROSOFT RULZ!!! or MICROSOFT SUX!!! I'm not asking for a vote.

Microsoft provides the #1 small-system OS, for better or worse, which means Windows will immediately be the hot target for black-hat types intent on spreading misery or demonstrating their hatred for the leviathan.

I know, too, that half the problem has been MS's arguably foolhardy decisions in adding dubious extensions to their software, like default enabling scripting in Outlook and macros in Word. But I'm kind of curious about the mistakes in doing their core work, like handling MP3's.

Last, I have trouble understanding how so many of these bugs come from a company with many of the brightest programmers. Is it a largely problem of scale and bureaucracy?

Share your concise insightful informative nonprofane fact-based reactions from experience? :)

Re:In defense of Microsoft...

[MacAndrew]

Two fools means no fools? ;-)

Re:In defense of Microsoft...

[doofusclam]

Hang on... Microsoft also has thousands of 'very bright' programmers around the world. Your point is? The key is what motivates these programmers?

Much as I love the idea of OSS (and indeed I contribute myself) there are a lot of OSS coders who just want to write new, funky stuff - bug fixing and other stuff that could be termed 'patrolling the perimeter of the code' just isn't funky enough so it gets forgotten about.

MS coders used to be the same, because obviously they're driven by the dollar, dollars which would only be spent on their software if it had the wizziest new features. Now after a few years of being mercilessly slagged off for bad code they're doing something about it because Chairman Bill realises that it's gonna affect the bottom line if they don't. They are paying a lot of dollars to fix their own bugs - which you may laugh at but - hey - at least it's being done. Big-name OSS projects, such as the Apaches of this world are similar to MS in that they have a lot of people working on them and, more importantly, *willing* to work on them so project admins can crack the whip and get the juniors to do the same code security audits that MS are now doing.

There are however a lot of less well known OSS projects with worse code than anything Microsoft come up with. They neither have the dollars of MS or the cachet of a big OSS project so people just code whatever bits they want. Hence, their code is likely to be worse without sufficient peer review etc.

The point of all this being that inferring that OSS is better that MS because linux has 'thousands of very bright programers (sic) accross the world' is not only incorrect it's harmful to the acceptance of OSS when the most vocal advocates turn out to be dumb-asses who don't think before they type.

seany

Re:In defense of Microsoft...

[GooberToo]

Simple fact is, awareness of buffer overflow exploits has been high for a very long time. Anytime you have a buffer overflow, it is a serious problem. That doesn't mean that every overflow can be exploited by running code, however, it a bug nontheless. You're welcome to characterize this type of bug however you like but the fact remains, almost all buffer overflow bugs are CS101 (real basic in nature) problems which one shouldn't find much of these days.

Combine that with the simple fact that hackers do tend to have real ingenuity, it creates a simple backdoor to walk right through.

Make no mistake about it. Buffer overflows are bugs and a programmer's failing. The fact that so many are found coming from Microsoft's direction only highlights just how little they cared about the quality of their products and the effect it can have on their user base. After all, even the most basic of code reviews should of been catching most and possibly all (vast majority) of them. Again, this creates several possibilities: 1, MS doesn't review their code. 2, MS employs programmers that are reviewing code but simply don't have the proper experience. 3, Such sloppy programming is well accepted and simply ignored by a review process as it's deemed unimportant, or worse, acceptable by corporate standards.

I would like to point out that I've met several people that work for MS and none were short in the brain department. If they are typical, I'm betting that possibility #2 probably does not apply.

Re:In defense of Microsoft...

[Pig Hogger]

Hang on... Microsoft also has thousands of 'very bright' programmers around the world. Your point is? The key is what motivates these programmers?

It's not the programmers. It's the pointy-haired bosses.

Re:In defense of Microsoft...

[Sloppy]

It has to be a problem of values. Buffer overflows have been biting people in the ass for a long time now, everyone knows they are very serious, and programmers who know what they're doing can easily avoid them.

If Microsoft is still shipping them, it has to either be because they think it's just not important enough to worry about, or because they don't have the resources to hire decent programmers. The rumors going around indicate that Microsoft has abundant resources.

Windows will immediately be the hot target for black-hat types intent on spreading misery or demonstrating their hatred for the leviathan.

For some reason, this has never happened, even though the the opportunity has been there for many years. My guess is that the kind of people who write Worms For Windows, enjoy the fun of it, and know that if they ever write a truly nasty one (massively destructive payload with a time-delay so that it can spread before detonating), there will be a crackdown (either legal or technical) and then the fun will be over. Perhaps that is why Microsoft considers security unimportant: so far there haven't been any serious incidents.

Re:In defense of Microsoft...

[tshak]

First, a similar bug was reported to XMMS. Second, we are talking about millions of lines of code that has historically been managed by people who care much more about features than security. Sure, last year MS initiated a major focus on security, but it will probably take a year just to get the mindshare of the managers, let alone get the programmers to rewrite a lot of code.

Re:In defense of Microsoft...

[gosand]

Last, I have trouble understanding how so many of these bugs come from a company with many of the brightest programmers. Is it a largely problem of scale and bureaucracy?

1. Programmers are human (barely. ;-))

2. Programmers build on the architecture. If the architecture is flawed by design, there isn't much a programmer can do.

Re:In defense of Microsoft...

[yoz]

Of course when there is no shareholder value to increase, priorities change. For examples of how this system works, please observe GNU/Linux.

Or, more accurately, please observe GNU/Hurd which is a project several years old that is still nowhere near to a 1.0 release.

Microsoft releases buggy software. So does Redhat. So does Debian. In fact, anyone who releases any reasonably complex code (and an entire operating system with loads of supporting packages is pretty damn complex) and claims that their code is entirely bug-free is lying. As has been pointed out elsewhere in this thread, Redhat 6 had a remote root exploit in its default install. Even OpenBSD, that bastion of religious security auditing, discovered recently that it was distributing a package with a hole in it.

The simple reason is that you have to put up with releasing buggy software because otherwise you will never release. No QA system will be able to get rid of all the bugs. The best you can do is prioritise the bugs you have and try and get the most significant ones fixed in time for a reasonable shipping date.

In terms of how good/buggy MS's code is, I think it's fantastic in some areas and terrible in others. I think that they are relatively weak and often irresponsible when it comes to security but they are learning. They share the same problems as any massive software development organisation, which is that as you grow it gets harder to enforce regimented coding practices. God knows they really have no excuse for bounds-checking errors (given the number of implementations of safe arrays they have lying around) other than policing this stuff is very hard, especially when it comes to legacy code.

Besides, as I said earlier, OSS projects have security holes all the time. They just tend to be patched faster and have a smaller impact (due to smaller, more savvy audiences)

-- Yoz

Re:In defense of Microsoft...

[iabervon]

Buffer overflows are pretty easy to avoid, if you care. Many of the brightest programmers care more about other things, however. It's a bit easier to write code which could overflow than code which can't, and writing readable code which can't overflow requires a bit of non-standard library support.

Furthermore, fundamental parts of the OS design make any bug security critical, which means that what would be a minor flaw on other OSes (browser crashes, have to restart it) are major security holes on Windows. This reflects a bit of bad planning a long time ago (and the fact that the design started out on systems which were not affected by anything but physical access) and an unwillingness to change fundamental user-visible design.

Re:In defense of Microsoft...

[Reziac]

The other problem, which I've heard about firsthand from an Apple OS programmer, and 2ndhand re M$'s OS and core Office programmers, is that often a coder or coding group is not allowed to finish their own project. At some arbitrary time it gets willy-nilling passed on, in partly-baked form, to some other coding group, so whatever was meant to be fixed later never gets fixed (the next group having no idea what still needed fixing), and features remain in a state of "this is a great idea, but look at all the spots where it doesn't quite work".

Reportedly this happens inside M$ to keep all the subgroups "competitive" with one another. Apple didn't seem to have any excuse other than crappy management. And I'm sure having "on the shelf by NN date" deadlines don't help.

So, back to the nominal subject line -- I don't think it's entirely sloppy coding, and my observation of Windows' evolution tends to support this. Particularly in WinME and WinXP, there are lots of functions where you can see where it was meant to go, but clearly just never got finished. Contrast this to Win95 and Win2K, which overall are much more polished in terms of what's there being *complete* and fully functional.

Anyway, I don't think it's fair to put the onus entirely on sloppy coding, as from what I've seen, M$'s coders generally do good work -- when they're allowed to.

Re:In defense of Microsoft...

[Reziac]

That's something I've observed too. The brightest programmers do brilliant things, but they find slogging thru the more mundane aspects of coding (such as security and UI) downright boring. And boring work tends to get done only at the last minute (with typical last-minute quality), or only when pressure is applied to get it done, or not at all. Throw a couple PHB into the mix, and Bill's vision of taking over the world (frex by forcibly miscegenating OS and browser), and suddenly you've got a real problem.

BTW when I review an app, a major PLUS is "when it does crash, it doesn't take out anything else." Which to my mind is how it should be. The fastest way for an app to get removed from my box is to crash the OS along with itself.

Re:In defense of Microsoft...

[yoz]

Note that I said tend to. I recall that Mozilla had a couple of nasty exploits that were known about for months before being properly fixed.

There's also the fact that "issuing a patch" can be an entirely different process for two different projects. OSS patches are usually:

1. a slight change to the source
2. some quick testing on a couple of machines
3. issue of a source patch file through the usual channels
4. updated tarballs and builds

whereas, in MS's case, it probably looks more like:

1. bug triage by project leads
2. reassignment of busy coders
3. slight change to the source
4. create binary patch for Windows Update along with standalone exe
5. send patch to QA lab for testing across hundreds of different setups
6. once back from the QA lab, start the process of fast-tracking the patch to WU
7. WU
8. Updated builds pushed to distribution

So yes, OSS is often faster, but you can see why. OSS is better able to handle a patch breaking something for some users, because it'll probably only be installed by power users who'll put up with it and know how to roll back, and the patch can be followed by a better patch. If a WU patch breaks something, even for only 10% of users, it's potentially disastrous because it's going out to everyone and 10% is still several million.

Re:In defense of Microsoft...

[yoz]

If Microsoft is still shipping them, it has to either be because they think it's just not important enough to worry about, or because they don't have the resources to hire decent programmers. The rumors going around indicate that Microsoft has abundant resources.

Microsoft has abundant resources, abundant programmers, and abundant code being written. Keeping it all in check is hard. That is where the problem lies for any large software development organisation that needs to ship.

Re:In defense of Microsoft...

[Reziac]

"... concise insightful informative nonprofane fact-based reactions from experience"??! Where do you think you are? :)

I've already posted a couple replies with my observations uphill from here, but consider 'em as replies to yours too. As a long-term observer of Windows' evolution, M$'s problem strikes me more as a partly-baked code problem (largely thanks to PHB) rather than programmer incompetence.

Note that "partly-baked" is not the same as "half-baked" :)

I recall a post from some previous similar discussion in which someone pointed out that some flaws come from compiling to the MFCs, which are apparently severely buggy. Dunno how relevant that is to this discussion. Anyone who knows more about that care to elucidate??

Re:In defense of Microsoft...

[indiigo]

Worm proposal:
Melissa-propagation, with a payload of randomly deleting (but better yet just changing a random metadata part of the file, such as add a few lines of corruption to a jpg, or a few random letters in a word document) network and local files, changing the date and filesize back to their original values, rooting every box to disable SFC, then restart the boxen with the "restart" tool from the Microsoft resource toolkit after infecting 500 hosts for propogation, changing the bootloader to load a linux quickboot random DOD filesystem wipe.

Boom, Microsoft OS +millions are gone. All this is possible with one single IE loaded webpage or link into an outlook/social engineering hack. IE is still vulnerable to scripting hacks and always will be.

Now go write it!

Re:In defense of Microsoft...

[kesuki]

How about another possibility? that microsoft actually manges to catch Almost all the in-house buffer overun problems but in by sloppy temp agency programmers, but that the ones that slip past are the minority?
For instance in this particular case the buffer overflow is not found in windows media player, but only in explorer itself. So obviously the WMP code was checked better, and no overflow was left when checking the id3v2 tags. windows has a lot of code going into it, the more code that needs to be reviewed the more bugs that will slip past watchful eyes.

Obligatory:

[Mr Guy]

This shouldn't be possible on XP SP1 or a recently patched IE though.

Or, of course, Mozilla, Eudora, or Opera.

Disturbing that it's in WinAmp too. Guess that llama's ass only holds so much.

fixed version of WinAmp 2.81 and 3.0

[Gregg M]

You mean they patched both versions and gave them the same number?

Thanks for nothing Nullsoft.

Versions??

[bconway]

Nullsoft has posted fixed version of WinAmp 2.81 and 3.0 on their web site."

Is there a reason they haven't released a new version with the bugfix instead of just uploading a new copy with the _same release number and date_? Both versions are listed as released in early or middle August, and there's no bugfixes listed anywhere on the site in regards to this. Site. Are they trying to hide that it's been fixed, or just don't want anyone to figure it out?

Re:Versions??

[Edgewize]

The file winamp.exe is exactly the same.

As it should be. ID3 tags are handled by the in_mp3.dll plugin.

Re:Versions??

[Night Goat]

The new Winamp version is 2.81c. I don't know about version 3, that bastard crashes too much on my computers.

Re:Versions??

[jakobgrimstveit]

This vulnerability was fixed a long time ago in WinAmp. It's only Windows XP that's a bit behind in patches at times :-). The files in the winamp281.exe archive has old dates.

Freedom to innovate

[c0y]

It can't be denied any longer. Back in the day the poor virus writer had to rely on his victims to carry the payload through meatspace on floppies.

M$ has been continually improving virus transmission methods, and now you might be infected just by moving your mouse.

But do we really need to worry? After all, how many kiddies are out there bragging that they '@dm1n1str@t0r3d' someone's XP box. No, it's just not as sexy as r00t3d.

Re:Freedom to innovate

[Alsee]

M$ has been continually improving virus transmission methods, and now you might be infected just by moving your mouse.

Auto-update installs code without so much as moving your mouse. How long before it installs a virus?

No, the real innovation will be when you can catch a virus without turning your computer on. I just wish I was kidding. Microsoft has yet to reveal the full capabilities of Palladium.

-

WILL affect most people

[gosand]

This is more of a curiosity than any sort of danger. Most of us, when we get a new mp3 file, give it a listen to make sure it's not mislabeled, doesn't cut off in the middle of the song, and sounds okay. We throw out or fix the ones that aren't up to our standards. So the number of people who would let one of these dangerous mp3s just sit there and be scanned is probably pretty small. And as is usually the case when something like this is discovered, they probably deserve what they get for being such idiots.

I don't think so. I know people who download a lot of stuff, and if you have it set up to download 100 MP3s overnight, your system could be compromised by morning. Are you going to listen to those 100 MP3s first thing in the morning?

The kicker is that the odds you get compromised go up greatly if someone seeds Kazaa, or even a web page, with an infected MP3 file. They can see who is downloading it so they know the IP to attack. On a web page, they could get your IP out of the logs. I never thought an MP3 file would leave a system vulnerable, but I guess that is why this is a pretty scary vulnerability - nobody else would either.

I have to hand it to Bill on this

[TerryAtWork]

I was sent and installed the fix before I read about the vulnerability.

Re:I have to hand it to Bill on this

[MacAndrew]

By Bill [Gates] Himself?

Wow. Most of us aren't that important.

Now, I'm wonder what was "sent and installed" with bugs in it? ;-)

Explorer workaround

[stratjakt]

Tools->Folder Options

set Web View to "Use Windows Classic Folders"

I've always done this, having never trusted 'web content' in any folder I browse to (nor needing the extra overhead it causes drawing thumbnails of bitmaps and whatnot)

I believe any Windows that's upgraded to Media Player 7.1 and/or IE6 would be vulnerable, not just XP?

File associations in WinXP

[PetiePooo]

Long ago, I've decided that Windows 2000 was going to be my last mainline MS operating system. Since Linux is making great strides towards usability on the desktop, it looks like I'll never have to rely on having XP on my PC. Now, I just have to make sure I keep Winamp current along with all my other applications.

However, this brings up an interesting question. Short of modifying the registry entries in HKEY_CLASSES_ROOT, is there any way to avoid all the cutsie stuff MS has been doing with file associations? I seem to remember a Win95/NT/2k shell extension that did something similar to the MS code that's being exploited. It popped up an additional property sheet with all the ID3 tag info. Could someone use that instead of the Windows shell without severely hacking the registry?

It also reopens an old sore. If the Windows Media Player were installed as an "application," not as "part of the operating system," this shell code would not be needed until WMP is installed. Those smart enough to search for better media-playback solutions would not be subjected to this vulnerability. Thanks, Microsoft! DOJ, are you paying attention?

And one more observation: now that MP3 files can carry shellcode, the virus scanners will have to start scanning them too. More processor overhead, longer scantimes, moan, gripe, ...

Re:File associations in WinXP

[Reziac]

We paranoids have been scanning ALL files since forever anyway. An old trick back in the BBS era was to have FOO.COM be a clean file, which in turn called FOO (no extension) which was the dirty code. If you didn't scan ALL files, you got bit.

It doesn't take all that much longer to scan everything, considering the alternatives.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Effects more then you realize (ID3v1 vs. ID3v2)

[GreenHell]

You're exactly right.

I think what the previous poster is thinking of is ID3v1 tags, which are located at the end of the MP3, so you don't get them until the MP3s finish downloading (and what's more, they have a fixed size so they're easy to check, but that's besides the point)

Now, this bug involves ID3v2 tags. ID3v2 tags are located at that start of the MP3, which is why when you add one to a MP3 playing in Winamp you get a brief pause, it has to add it to the start of the file. Therefore, any MP3 with an ID3v2 tag will already have the potential of compromising you by the time it's downloaded enough to play part of the song if you preview them using Winamp.

I don't know how Explorer checks file attributes on MP3s, but I'm assuming that you're already in danger by this time too.

Re:XMMS too.

[damiangerous]

Well, Microsoft and Nullsoft have already posted fixes, so I wouldn't draw attention to that difference too much. :)

How does a buffer overflow allow code execution?

[og_sh0x]

Thanks to Boatboy for the explanation of buffer overflows, but what I've never understood about buffer overflows is how it allows you to execute arbitrary code? Can anyone explain?

Not a problem...

[D-Cypell]

If the RIAA use these tactics the solution is simple...

Wait a few months until the RIAA's trojanized files are well and truely spread throughout the P2P networks...

then use the thousands of trojanized nodes to DDOS the RIAA

*chuckle*

Re:Not a problem...

[geekee]

Did you consider that the RIAA could close the hole once in, but leave themselves a backdoor?

Re:Not a problem...

[Anonymous DWord]

This would be the same RIAA that was serving mp3s from their website? That RIAA? No, we didn't consider that.

Re:Not a problem...

[geekee]

It doesn't take a lot of money to get some expert consulting, especially after getting burned.

danger for gnutella networks..?

[kipple]

will now the MPAA and RIAA have a new weapon against pirates?
And if they do, executing remote code using a vulnerability will be legal? :)

[just provoking]

The Next Nimda.

[Deathlizard]

And I thought Nimda was bad.

When all of the college students here on campus had read/write shares on the network, Nimda Spread at an alarming rate, Especially since WinXP Home decided that you SHOULD have your Shared Documents folder open for read/write access after running one of those networking wizards.

I could only imagine the hell a Modified Nimda would be if it can now infect mp3 files. It wouldn't even have to spread infected .eml files anymore. you would just see a new MP3 in your read/write network share with thousands of other MP3's so you would never find it and it would infect all of your MP3's in your read/write network share. Once you open the folder to pick a song it runs and infects all of your mp3's on the PC, then goes out and proceeds to infect every mp3 it can write to on the network that has read/write shares and the process starts all over again while it formats your hard drive 7 days later.

It's the RIAA Dream come true :P

Re:The Next Nimda.

[RzUpAnmsCwrds]

Except that it has been fixed already, and because of auto-update everyone has recieved the patch

Re:Why are there still buffer overruns?

[esarjeant]

Since you don't manage your own memory on Java or C#, the concept of buffer overflow doesn't really apply. While the array construct still exists in both languages, you can't overflow an array without going out of bounds.

It is critical that the software industry start to adopt VM's for managing applications, especially code that runs on a server. The emergence of a user-mode kernel for Linux is a critical development in this regard, but ultimately it makes more sense to modernize your codebase to Java, C# or any of the interpretive languages that can intercept/manage memory allocation checks for you.

Re:How does a buffer overflow allow code execution

[Anonymous Coward]

Search the Web for the classic: Smashing the Stack for Fun and Profit.

All you ever wanted to know, and then some...

Suggestion: Operation So Happy It's Thursday

[wowbagger]

There's a running joke where I work that it is not officially Thursday until the Microsoft exploit of the week is released (of late this seems to happen on Thursday).

So, why not make it official - I propose

Operation: So Happy It's Thursday

What I recommend is that everybody who finds an exploit in Windows release it on Thursday.

NOTE: be fair - a bug in a Windows APP that is not a part of Windows doesn't count - so the bug in Winamp doesn't count, but the bug in the Windows shell does.

Re:Suggestion: Operation So Happy It's Thursday

[gclef]

Heh. Well, since their old habit was to release these late in the afternoon on a Friday, I think I prefer the present setup....especially since they had a bad habit of announcing serious issues after CoB on the East Coast, meaning that we would all get called back for messy issues before a weekend.

Won't work

[kurokaze]

I'm doing the same thing on my work machine which
is running XP (hate all that crap also)

Look in a folder that contains only music files
(as most people usually have a folder just for
that).

At first, Windows treats it like any other folder
and displays only the filename, size, type and
mod date. After a while however, it seems to
figure out that it contains music files and starts
reading to ID tags. No idea how or why it
happens.

Re:Won't work

[Reziac]

I think what happens (I may be wrong but this is what it looks like) because XP reads the data tags (be that for MP3s, image files, or whatever) regardless, THEN decides whether it should display thumbnails or whatever. Run your mouse pointer over a filename that's too long to display completely and watch how sometimes, even in classic view, you get all the extra info displayed in the balloon.

Personally, I *loathe* the webview crap, and it's the very first thing I turn off. My screen space is limited enough without spurious graphics cluttering it up (and making it harder to read).

Re:How does a buffer overflow allow code execution

[pclminion]

Because of the way data is stored in memory. It is common in C code to declare buffers as local variables, causing them to be allocated from the stack. The stack, as it happens, is also used for execution control.

By overflowing a buffer on the stack, it's possible to maliciously change a particular piece of information (the function call return address) to cause the program to jump to a new piece of code: the code you just overflowed the buffer with!

Stack overflow exploits are very common because programmers often declare fixed-length buffers as stack variables and are too lazy to perform proper checking to make sure data never overflows the buffer. This problem in WinAmp is no different than any other buffer overflow, it's just much more severe due to its widespread use.

It's a good think I have Linux

[jmcnamera]

It's good that I have linux since it **never** has buffer overflows. Nor does any other open source software.

Re:It's a good think I have Linux

[pomakis]

It's good that I have linux since it **never** has buffer overflows. Nor does any other open source software.

I hate postings like this, because I never know whether I should mod it +1 Funny or -1 Clueless.

Snooty audiophiles

[wowbagger]

Snooty audiophiles won't like FLAC, either.

A snooty audiophile sneers at any form of digitization - "You aren't getting all of the music - Yes, I know you are sampling a 1GHz, 64 bits per sample, but you aren't getting all the music! Only analog gets all the music! I don't care that what you are missing wouldn't amount to the width of a hydrogen atom on my beloved LP - YOU AREN'T GETTING ALL THE MUSIC"

That's what a snooty audiophile would say.

Re:Snooty audiophiles

[spinlocked]

I think snooty audiophiles would be most concerned about the quality of the DSP on the MP3 player - that and the 'engine noise' coming from the power supply. I'm not an audiophile, but I did build my own MP3 player from the insides of an old laptop, a floppy disk based linux distribution and a homemade shell script based webserver control system. It's a bit clunky, but I'm proud of it :)

If I cared much about the quality of the sound, I suppose I'd need try to produce an optical digital output and run it into a decent pre-amp. As it is, it's playing through an old pair of PC speakers that go 'pop' whenever the refrigerator motor starts up in the kitchen :). I'd far rather fiddle about with the user interface (hey, we need voice activation!) than improve the quality of the sound.

Re:Snooty audiophiles

[13Echo]

Yeah. ;) But I still have problems believing that vinyl can even accurately reproduce perfect sound. I just don't feel that the arguments of "audiophiles" are well supported. All "audiophiles" use examples from older vinyl recordings when they are compared to newer, remastered versions on CDs. Well, of course it is going to sound different. It has been remastered on different equipment. I think that people are so used to the sound of a specific recording, on vinyl, that if it doesn't have the characteristics of that form of media, then they truely believe that "you aren't getting all of the music".

I really don't care as long as I can preserve most of the integrity of my original CD. If I can encode a VBR MP3 or Vorbis file, and it retains most or all of the attributes that are noticable to the human ear (my picky ears, most specifically), then I am fine with it. I just like being able to archive all of my music onto my hard drive, for easy playback, as do most people that use the MP3 or Ogg Vorbis formats (besides the pirates).

Re:Snooty audiophiles

[alanwj]

A snooty audiophile sneers at any form of digitization - "You aren't getting all of the music - Yes, I know you are sampling a 1GHz, 64 bits per sample, but you aren't getting all the music! Only analog gets all the music! I don't care that what you are missing wouldn't amount to the width of a hydrogen atom on my beloved LP - YOU AREN'T GETTING ALL THE MUSIC"

That's what a snooty audiophile would say.

Actually, that's what a snooty audiophile that wasn't well versed in signal theory would say. If you sample at a rate that is greater than or equal to the Nyquist frequency (twice the highest frequency present in the thing you are sampling) then you can reconstruct exactly the analog signal. Granted there are some really high frequencies in most music, and you'd have to sample at an insanely high rate, but you could certainly make a digital recording from which you could play back "all the music".

Alan

Re:Snooty audiophiles

[wowbagger]

Rather my point - audiophiles are not rational individuals who are well versed in signal processing theory, they are rabid indiviuals who's sound systems are a penis substitute.

Hence why audiophiles hate modern sound systems - it is far too easy to get great sound reproduction nowadays, and how are you to demonstrate how large you are when a $19 CD player sounds as good as your $3000 turntable?

That is why audiophiles use "oxygen-free copper wires with authentic virgin yak wool insulation, cryogenicly treated to release signal-distorting sub-micron strain! A steal at $300/ft! Act now, and we will throw in our patented Feng Shui turntable stones - five of these will disgronificate your turntable! Normally $150 each, but a steal at $800 for a set!"

Re:Snooty audiophiles

[MSG]

They also buy Monster Power supplies. :-)

Re:Snooty audiophiles

[OzJimbob]

True dat. So many people who are obsessed about audio quality, just don't understand the electronics and physics behind it. I think bitrate-nazis are the obvious candidates. I've seen tracks which are mono encoded in stereo format. I've seen dodgy, spoken-word recordings which are full of static anyway recorded at 320kbps. Raise your fists high and proclaim 128kbps is fine for me!.

foobar2000

[slothdog]

Apparently the current underground favorite audio player for Windows is foobar2000, which was written by a former Nullsoft developer (Peter P. aka zZzZzZz). It supports mp3, ogg, ape, flac, mpc, and relevant to the article has abandoned ID3V2 support in favor of APEV2 tags. (And it's been suggested that the source will be released in the near future.) Supposedly the audiophile geeks at hydrogenaudio.org can hear quality improvements over Winamp, although even the developer suggests that it's probably a placebo effect.

Just don't expect too much; it's a very minimalist GUI (what mean these "skinz" of which you speak?), and doesn't support Win9x/NT4.

There's also a support forum for the player.

Hey idiots, strcpy bad!

[hoggoth]

OK class, has anyone figured this out yet?
Buffer overflows are bad.

It is easy to STOP buffer overflows just by using SAFE strcpy functions that don't blindly copy past the end of a buffer.
Since we've known this for many many years, why do programmers still USE dumb functions that allow buffer overflows?!

Hey Microsoft, since you are spending so much on improving security, I have a hint for you. Print this out and make all your programmers pin it on their cubicles walls:

BAD: strcpy
GOOD: strncpy

Re:Hey idiots, strcpy bad!

[Ozan]

BAD: strcpy
GOOD: strncpy

BAD: char*
GOOD: std::string

Re:Hey idiots, strcpy bad!

[Tsali]

I thought it was...

Public Sub DoMaliciousCode(strSQL as String)
If Len(strSQL) > 25 Then
Call StrCopy(strSQL)
End If
End Sub

... for all those MS scripting gurus...

Is iTunes vulnerable?

[tbmaddux]

No mention of iTunes anywhere. Am I vulnerable? What about my iPod? Were they tested as well? Couldn't find any mention at the links provided and no test mp3s to try out.

Give me full disclosure...

Copy and Paste into your MP3s

[teamhasnoi]

10 Print "Windows Luser! You will Pay for Your Insolence!"
20 Print "Bill Gates laughs as he rolls about with his concubines!"
30 Print "Prepare for judgement!"
40 Input "Press any key";A$
50 If A$="AnyKey" Then fucksomeshitup;
60 W00t: Poke InChest;
70 Run "BSOD.exe -Playfile BritneySpears,HitMeOneMoreTime"
80 Print "This is what it sounds like when doves cry! Bwahaha!"
90 Goto 10

You should be able to find this on SourceForge too.

Build #'s and Winamp strangeness

[haplo21112]

I don't mean to be a pain in the ass here...but if the code has been patched and rebuilt on a different day shouldn't we at least see a different minor version in the help? I can understand fine at 488 is the code freeze version for the 3.0 release however is a bug has been patched and a new release has been done should this be like 3.01(3.0.1) or 488a just so the its more immediately obvious this is an updated version from the 3.0 I have. If I didn't know about the bug, and I went to the site to see if there is a newer version, I wouldn't get the fixed version cause I still see 3.0! Build dates are meaningless...and even less so if they are not even posted on the download page....

Use Ogg for the quality!

[tjwhaynes]

Most people don't use Ogg Vorbis for the quality. They use it for the license.

Speak for yourself - I use it for the quality, especially now that the audio artefacts that were so obvious in early development releases are fixed.

In high bitrate modes, there is little difference between properly encoded MP3s and OGG files. And high bitrate is what really matters, unless you are streaming over a low bandwidth connection (in which OGG is the clear winner due to size).

Personal blind testing between Ogg VBR 160kbit and MP3 192kbit was pretty even - very few people could tell the difference and where there were impressions of 'better' it fell on the Ogg side. Given that Ogg VBR 160kbit is about 25% smaller than the MP3 at 192kbit, that's pretty useful.

Cheers,

Toby Haynes

Re:Use Ogg for the quality!

[13Echo]

I generally use LAME VBR with a mostly r3mix setting for my MP3s anyway. They encode all the way up to 320k when neccessary, but end up with a file on the average size of 192k. That really isn't too bad, when you think about it. You get pretty good sound for a lossy format, but the size isn't too hateful.

When size is an issue though, it is true that OGG is probably the best choice.

Re:Use Ogg for the quality!

[karnal]

I would have to say, depending on the music style, I can.

I've found certain bands that I'm into don't compress well at 160. So, my solution? VBR, 192 minimum. Even though it takes more space, I have a better feeling that more of the actual music is represented.

I've heard artifacts in cymbals being played at 192, so giving it the ability to code up to 320 VBR is a godsend.....

Re:Pathetic

[CynicTheHedgehog]

A buffer overflow means that you take a variable location, such as char songName[255], and put enough data into that buffer to reach into the executable portion of the code in memory. Then, when some function returns, or execution branches, or something loops, part of that data will be at the address of the code that formerly handled the return, branch, or loop, and will get executed as if it were the next instruction.

Any buffer lacking good bounds checking is subject to this.

mod parent up

[tempest303]

damn right.

I wonder how "audiophiles" listen to music in the car? /me imagines a slot-loading turntable in the dash...

Re:mod parent up

[WNight]

Just like film grain, it's a valid comparison.

Purists will insist that because *some* film has incredibly small grains, if handled perfectly, that all film is 30+ MP, but we'll be laughing at them with out 5+ MP cameras that surpass anything film really has to offer. Just the same as audiophiles who prefer the "warmth" (static) of records...

Re:How does a buffer overflow allow code execution

[Montag2k]

Okay, I'll try to make this as short as possible.

Let's say that you have an array, x[20]. It is 20 bytes long. This array starts at memory location 149300. This means that the bytes 149300 - 149319 are reserved as being part of the variable called x. Now, lets say that in this array, you decide to store a string of letters (an ID3 tag, for example). If you allow the user to input the letters into x, without checking the maximum length, then the user can start writing data past x[19]. For example, if the user inputs a string that is 30 characters long, data will be written from bytes 149300 - 149329 in memory, even though you only allocated the memory through location 149319. This means that the user has the ability to write to other data in the computer.

Now, here comes the fun part. If the user (a cracker, at this point), knows where the operating system code lives in memory, he can just input a string that is long enough and eventually overwrite the operating system code. He can carefully craft the string as his own little bits of code which can do nasty things. This is how a buffer overflow works.

I have always thought that this was more of a problem with C than a problem with Windows, since C should really check for stuff like this (or handle strings better). However, it might be kind of hard for the compiler to be able to check for this. The only way to really prevent these is good programming habits - but people make mistakes all the time.

Hope that helps!

Regards, Montag

What if this IS the plan?

[burgburgburg]

Convenient that downloaded "pirated" music files are now potential attack vectors. So much more effective an argument for DRM ("If it was legal and properly signed, you'd have nothing to worry about.").

I wonder if the EULA on the MS patch for this will be overreaching and invasive?

Re:What if this IS the plan?

[Didion Sprague]

Which brings me to a slightly off-topic question (but not that far off-topic): won't it take just a single compomised DRM file on whatever platform to completely send the whole DRM concept -- at least the generation with the single compromised file -- down the toilet?

I mean, it would seem to me that Microsoft's DRM -- or DRM in general -- is based somewhat on "human" trust. Once that trust is abrogated -- just once -- the whole thing spirals into a "well, it's still pretty secure" type of situation -- and then sprials into "wait'll next generation's DRM. It'll be secure as hell."

I know no cryto scheme is 100% -- at least in theory -- but because the consumer/DRM stuff is being built up and hyped so much lately, it seems that its potential -- potential for complete security, potential for complete failure -- far outstrips the more practical, usability/crackability aspects.

And then I wonder: once this sort of consumer/DRM is launched mainstream, it'll become -- eventually -- embedded into the economic model for distribution. But once this DRM stuff is cracked or broken or whatever happens, the DRM itself will fall apart, as well the economic model. And companies who go balls-out to invest in this stuff -- and work hard to secure the "human" trust aspect of it -- will be in dire, dire straits -- economically, technologically, you name it.

DRM is like a massive WMD waiting to be let loose. It's failure -- assuming it fails at least once a generation -- will sink more companies than I think anyone realizes.

Just some thoughts.

Re:What if this IS the plan?

[Kashif Shaikh]

DRM is going to be DMCAs little child of hell. Doesn't matter how bad DRM is security wise--it's the potential of hacking it and shoving DMCA down to any who does hack it--that makes it the scary part.

Re:What if this IS the plan?

[Alsee]

DRM... -- assuming it fails at least once a generation --

Don't you read slashdot? There's a major DRM failure every month or so. And DRM isn't really that common yet. The more common DRM becomes the more people are going to look at it and the faster it's going to fail.

The entire DRM agenda is sickening. They can never actually succede, and the harder they try the more we're all going to get screwed over in the process. Bad laws. Crippled products. And inflated prices to pay for doomed DRM implementations.

-

CDDB

[laigle]

The twitchy part is, even most people who rip their own music these days get the ID tags via some free database site, and those often take submissions. How hard would it be for somebody to just submit a bunch of malicious ID tags for popular albums?

Maybe my mind's in the gutter...

[Thud457]

but I really could have done without the mental image you just gave me! Worse than goatse. ugh.

aka Silent Updates

[simetra]

They're called Silent Updates.

Microsoft has been doing these at least since Win95 days. Exact same file name, size, different contents. So if you downloaded office 97 SR-1 the day it was released, then again 2 years later, it would probably be different.

Re:aka Silent Updates

[Reziac]

AOL does it too. I've found I've got to keep a copy of each and every different AOL CD, even nominally for the same version, to have one that matches whatever subversion some client installed.

Re:aka Silent Updates

[Reziac]

I only keep one of each edition (have found as a quick indicator, if they have a different picture, the contents are usually different, even for the same version). So yeah, I've got a couple dozen. Sickening, isn't it? :)

The old AOL diskettes often had nifty modem utils on 'em. Not much useful like that on the CDs, tho.

RIAA Using This

[dmarx]

How long before the RIAA uses this to, say, trash an MP3 downloader's hard drive? And how much do you want to bet that Congress will legalize this?

strncpy bad, strlcpy good

[nestler]

99% of people using strncpy don't actually bother to read the definition of what it actually does.

Hint, this code is buggy:
char buf[1024];
strncpy(buf, big_ass_string, sizeof buf);

strncpy doesn't bother adding a null-terminator in the case where big_ass_string is too big. Most people don't realize that they have to do all of this to be safe with strncpy:
strncpy(buf, big_ass_string, sizeof buf - 1);
buf[sizeof buf - 1] = '\0';

The real solution is to use a function that doesn't have such crappy behavior: strlcpy

strlcpy(buf, big_ass_string, sizeof buf);

It always does null-termination. You never have to lie to it about the size of your string. Same goes for strncat (bad) and strlcat (good). Thank the OpenBSD developers for these. They are very useful in avoiding overflows when you don't have the option of using C++ and the string class.

Re:strncpy bad, strlcpy good

[arkanes]

The really funny thing is that there's even an update for the Windows SDK you can install, which will undef all the "unsafe", normal C library functions, replacing them with error pragmas, and provides a whole nice suite of safe string functions. It's still a pain in the butt to re-code everything, but in most cases its a drop-in fix, and where it's not, that usually means you had a problem that needed fixing anyway. I don't really expect them to have fixed the ENTIRE codebase yet, but the multimedia and internet components you'd think would be high priority.

Re:strncpy bad, strlcpy good

[Kashif Shaikh]

You could also use snprintf snprintf(buf,bufsize,"%s", big_ass_string);

Re:You see...

[Mwongozi]

Oh no, this never happens on OS X.

Re:Pathetic

[dirty]

Bounds checking really isn't that difficult in C. strncpy() instead of strcpy(). C made a good choice not to enforce bounds checking when you don't need it.

Question for slashdot

[Raul654]

My advisor, DL Mills (the guy who invented NTP), said something a while back which this article somewhat reminds me of. He said that back in the day, people wrote operating systems in assembly. But the thing is, they just got way too f****** big and couldn't be maintained, even with the best of care. He said that today's operating systems are getting to that point as well, and maybe it's time for a new level of abstraction. Stuff like exception handling (amoung which automated buffer checking should be one), garbage collection, etc, should be built into the language, and leave the programmer to concentrate on more important things.

So my question is, does anyone have any idea what this "new level of abstraction" might be?

Re:Question for slashdot

[Animats]

So my question is, does anyone have any idea what this "new level of abstraction" might be?

Ada? Pascal? Modula II/III? C#? Java? All those languages have subscript checking. It doesn't add much overhead, either, if the compiler is smart enough to hoist subscript checks out of loops.

Meanwhile, will somebody please move "strcat", "sprintf", etc. to a "deprecated" library? If you find any of the old unchecked UNIX string primitives in open-source code, rewrite them using the safe versions.

Re:Question for slashdot

[jhines0042]

Sounds like a 5GL to me. C+++?

I think that if something like what you are describing where to be widely adopted there would have to be other benefits to it as well.

For example, easy to code, distributed software. Security would also be paramount there.

Re:Question for slashdot

[frank_adrian314159]

does anyone have any idea what this "new level of abstraction" might be?

Lisp.

There's even been an OS built in the language. Seemed to work just fine. Problem was, that in those days, you needed special purpose hardware to run a Lisp-based OS on. You don't anymore, but the code has been lost to people who could do something useful with it in the mist of time and bankruptcy. Google for Genera and OpenGenera. Hint - once the base code is built into the system, you cannot have buffer overflows, uncaught exceptions, or uncaught arithmetic overflows. It's a good environment (as I can attest, having it running on my Symbolics Lisp Machine at home).

Oh yeah, they have a great OO database, decent graphics, and all of the web crap you'll ever need, too.

Re:Question for slashdot

[PinkX]

As I understand, Java manages all of the garbage collection by itself. So using Java with a native compiler (instead of the VM crap) like GCJ would be a clever solution.

About your comment regarding strcat, sprintf, etc., I couldn't be more agree with you. I *hate* the way C does string handling (it's awful for God's sake). What are those safe versions you are refering to?

Re:Question for slashdot

[Animats]

What are those safe versions you are refering to? Look up "strncat", "snprintf", etc. Each has an extra size-limiting argument.

Re:Obvious reply

[aengblom]

All file formats are safe, it's just the programs that read them.

The correct phrasing of that is: File formats don't kill programs. Programs kill programs.

Um, not a solution.

[Andy Dodd]

Well, maybe for Microsoft and their love for bloatware, it is, but in general, interpreted languages are NOT the solution.

Interpreted = slow. Period. Even with nifty stuff like Java JIT compilers and such, Java is still slow and bloated. I remember the Java version of AOL Instant Messenger - It could drive a machine with 256M of RAM into swapspace without lifting a finger. Yes, that was a particularly badly coded craplet, but I have yet to see ANY Java applet/application that could compare in speed/small footprint to a C program (or even C++) program that did the same thing.

And in this day and age, we are returning to having to return to small, efficient code thanks to embedded devices such as PDAs.

All it takes is a little bit of competence and a few extra utilities to check (and even prevent) buffer overflow vulnerabilities from occuring. I don't remember the exact name, but there's even a preprocessor for GCC that will check for vulnerable code and fix it.

Re:Um, not a solution.

[jpmorgan]

Chances are you've never seen a JITting JRE. Chances are you've only ever seen the Sun reference implementations, which are slow and bloated.

With C#/.NET, the entire bytecode is designed to be JIT compiled - you're not really even supposed to interpret it at all. In my experience, a typical .NET program runs at almost the same speed of a native program (almost being a 1 or 2% difference). They do, however, use twice the memory.

YMMV.

Conspiracy theorist?

[phorm]

Winamp doesn't belong to MS, so we're probably just warning people.
I'm not sure which is worse:
a) Those that imagine everything MS does is attempt to rule the world
b) Those that imagine every posting mentioning a bug in MS is a covert attack.

Considering the amount of geeks here that are into Mp3's, or those that maintain networks (with users who play downloaded Mp3's, permitted or not), this warning sounds like it fits well on slashdot.

Re:How does a buffer overflow allow code execution

[Sloppy]

One of the weird things about the x86 legacy is that the stack grows downward in memory. When you overflow, you're not writing over unallocated stack space (like you would on a processor that makes stacks grow upward). Instead, you're overwriting things that were earlier pushed onto the stack.

Think about that and visualize it in your head.

What is particularly nasty about this, is that the vulnerable data on the stack includes return addresses. Thus, the overflow can result in a return instruction not going back to the original caller. Instead, it can "go back" to some code that the attacker pushed onto the stack.

This must be the work of the RIAA

[Ignorant Aardvark]

The RIAA would rather not have computers exist, because that allows for trading of their precious songs. So by creating a virus that spreads through mp3 they're effectively cutting out a large amount of the piracy.

What's next for the RIAA? A virus on music CD's that is executed when played in computers. Obviously, allowing a CD to be played in a computer is the first step to it being pirated. Instead they'll allow it to play only in DRM CD players that will play 20 hours of music per license bought (each license will cost $20).

Please don't mod me down, I'm not trying to be flamebait, I'm being sarcastic :-)

Automatic source code analysis

[alispguru]

Feeding this to Google produced 11,000 hits, with over half of the first ten being for commercial or academic systems that claim to detect potential buffer overflow code automatically. I doubt any of them is 100% accurate, but even 50% combined with "shut-up-this-code-is-safe" pragmas would be an improvement over the current situation.

Buying or installing one of these tools and running all their source code through it as part of development would cost Microsoft less than they spend on caffeinated liquids, and would pay for itself with the first potential exploit caught before shipment.

I can only ascribe people's refusal to try these tools to programmer hubris - "MY code can't be understood by a mere code analyzer".

I am rashly assuming here that Microsoft doesn't use tools like this. If anyone out there knows differently, please reply.

Re:Automatic source code analysis

[mcjulio]

You are rashly assuming this, and you're wrong. All the major groups (and the minor ones with more attentive dev managers) run a tool like this that can catch issues like this, and many more. Unfortunately, quite often in the rush to ship, this data has not been inspected thoroughly or properly.

Re:Automatic source code analysis

[Anonymous Coward]

Windows and Office both recently did major security reviews where they reviewed (ostensibly) every line of every file that handles external input. Problem is, the automatic tools don't catch everything, and neither do human eyes. I would be interested to see the code on this vulnerability. If it's as simple as reading the ID3 tag into a stack-allocated buffer I would be surprised. Either the person who security reviewed the file would have to have been asleep, or somehow that file slipped through the cracks.

The point is, MS actually does take security seriously now. It just turns out this is a hard problem, and it's not something that has been on 90% of programmers' minds until just the last couple of years.

Re:Microsoft Security

[tshak]

Well, first you have to understand what memory is. Then you have to understand that byte's in memory get executed. Continue this path and you find that MP3's load it's byte's into memory, including bit's that describe itself (not just audio). Putting it all together you realize that it's possible (and non-trival to prevent in lower level languages like C++ or ASM) to have rouge byte's execute malicious code.

It's already patched.

[AzrealAO]

There is no EULA on the patch either.

Protestant vs Catholic

[Anonymous Coward]

About 500 years ago, a guy named Martin Luther decided to translate the Bible into German, thus was born the Protestant revolution. The point being, that before this, if you were German and could not read Latin, you had to have a priest translate the words of God AKA the Bible.

A Brit named William Tyndale had the same idea, he printed 50 copies of the Bible *in English*, the establishment was that shocked at this idea, they burnt him at the stake. Probably because they thought the idea of the common people having direct access to the 'holy writ' would lead to them thinking for themselves and having dangerous ideas.

How like the current debate between open source and closed source this all sounds. Just substitute operating system for Bible, money for God, the stock market for the Holy Roman Empire and Bill Gates as the Pope and it all lines up!

Automatic updates are spooky

[Wee]

Or if you're like many people, the fix has already installed during an automatic update check last night.

I don't wear the tinfoil hats either, but I find it a little unnerving that people let their system be updated automatically. There's just so many things wrong with that concept. Some updates I don't want, others I defintiely do. All of them I want to see before they get installed so I know what is going to be done. Although I suppose figuring out what an MS update will do can be pretty hard, since they tend to bundle lots of fixes into sinlge packages.

On the other hand, we're not talking about a dedicated SQL Server machine or anything, so maybe auto updates for desktops isn't a bad idea after all...

-B

Re:Obvious Answer

[DavidLeblond]

I remember back in the days of BBSes people around here would always put ANSI bombs in readme files.

So, no.

Re:Except that C...

[spakka]

Do you have a good example of where bounds checking is enforced but not needed in other programming languages?

In Java:

int a[] = new int[10];
for (int i = 0; i < a.length; i++) a[i] = i++;

Each access a[i] is needlessly bounds-checked.

Too late! I've already seen those landmines :S

[ToKsUri]

Doing a search in Kazaa I found a strange file called "!!Download me if you like REM!1Kewl new band.mp3". It came out to be a completely malicious mp3.. It's ID3 tag said something like NSYNC... yulk!

Re:Microsoft Security

[afidel]

Windows XP (actually every MS os since 98 I think) will read the extended attributes of files so that you can sort based on them. For instance you can sort your mp3 directory by genre if you want. I personally use it to sort my photo collection by date the picture was taken rather then the date I transfered it to the pc as the normal attribute is the latter.

Re:Microsoft Security

[donutello]

How the hell is the parent insightful?

That's the way Von Neumann machines work. This is not the OS getting involved in executing the code from the MP3. When a buffer overflow occurs, the OS is overwritten by the data that's overflowing. The result of this is that when that OS function is called, instead of the code for the OS function running, you have the code that was in the data running instead.

I remember about 10 or so years ago when there were designs for machines with separate data and control areas of memory. Such a machine wouldn't have buffer overflow issues since a buffer overflow would only corrupt data, not trash control code.

Re:XMMS too.

[Oliver Defacszio]

A brief synopsis of what just happened: an OSS user waited for the commercial vendors to do the legwork of finding a particular bug, then spent two minutes looking to see if he was affected too and then released a patch that was still later than that of the commercial vendor.

Sounds to me like the XMMS bug would never have been found (or at least not for a long while) if not for Microsoft/Winamp. You must be proud.

You'd better check

[Snork Asaurus]

From the Foundstone Advisory:

One buffer overflow exists in Winamp 2.81 (latest 2.x release) and two buffer overflows exist in Winamp 3.0 (latest 3.x release). The Winamp 2.81 overflow is with the handling of the Artist ID3v2 tag upon immediate loading of an MP3. The two Winamp 3.0 overflows are present in Media Library's handling of the Artist and Album ID3v2 tags.

There is often the flawed assumption in these reports that people always use the latest version of a particular app. Yes, I know that it would be hard to get and test all versions, but they could at least find out from Nullsoft and indicate what range of versions might be vulnerable.

Nullsoft (bless them - I love Winamp) has an annoying habit of removing or changing features that I like in the minor rev's, which is why I stick to certain versions. I use Winamp 2.50e and 2.78 on various machines. I also have 2.09, 2.70, 2.72 and 2.81 (and a 1.xx and probably others), but don't use them for this reason. Winamp 3 was too buggy as of the build I got a couple of months ago.

Anyway, I often wonder, when I see vulnerability warnings and a version of something that I use is not specifically excluded, is it:

a) Not vulnerable?

b) Not tested for vulnerability ?

Winamp2.5 doesn't handle ID3v2, so it's probably OK. The ID3v2 handling was added somewhere around 2.72, IIRC, so I'll have to do some checking. You might want to check yours as well.

I'd hate be forced to abandon my beloved older Winamps because there's no fix, but that may happen.

Re:You'd better check

[Reziac]

Any idea where a person could download older WinAmp versions? Are they archived anywhere?? I just did some looking for 2.50 and no joy. I've been using 2.62 for ages -- arrived with some version of Netscape. I did once try to feed it a proof-of-concept file for an exploit that went around last year (something to do with calling out to a malicious web page), but it just looked at me funny.

Re:You'd better check

[Snork Asaurus]

Google for this: winamp25e_full.exe

and you'll find it (I did). BUT I MUST WARN YOU: YOU'LL BE DOWNLOADING AN EXE FROM AN UNKNOWN SITE AND THE USUAL ANTIVIRUS PRECAUTIONS NEED TO BE APPLIED!!

I'm not sure why you want 250e, since 2.62 is probably OK (but that is in no way a guarantee from me - I'm speculating a lot on this), unless you're looking for a removed feature. Once WinAmp 3 gets some of the kinks out, it should be great, and in the meantime, the fixed 2.81 should do the trick.

Re:You'd better check

[Snork Asaurus]

Well done. I was trying various ways find Winamp 2.50e for my reply when you posted a much better one. I always figured that a place like this should exist. BTW, in answer to the question beside 2.50e on the site - "The most perfect of all versions?", I'd say that it is for me - it's a sweet spot in the history of a very good player.

Re:You'd better check

[Reziac]

Hey, coolness! Thankx!!

Re:You'd better check

[Reziac]

Thanks -- tho today's googling got nothing but borkend links, as far as I got before giving up. Someone here later suggested http://winampheaven.kicks-ass.net/ which is indeed full of every which version of WinAmp in one handy location.

I always regard all files as infected until proven otherwise, regardless of where they came from :)

As to v2.62, it's perfectly fine for most purposes, but it tends to choke on audio CDs, and over time it clogs up the swapfile. (Few other bugs too, incl. one in the visualization switcher that can make the program suicide -- to the point where it needs to be nuked and reinstalled, but I know to avoid that one now :) So am open to inspecting other versions. Several folk piped up that "2.50e is the most perfect version ever" so thought I'd give it a look.

Re:Pathetic

[spakka]

That's because programmers keep programming in C, which is a glorified assembler,

Ignorant programmers are not the fault of the language. C makes it simple to avoid buffer overflows almost everywhere (exception being the absence of snprintf() - remedied in C99).

...instead of using a HIGHER level language that handles all the plumbing...

If a programmer is too weak to avoid buffer overflows in C, how will they cope with, say, C++ exception safety?

The changing nature of Windows exploits

[irregular_hero]

A long time ago, you could destroy your files and have a very bad day by using that floppy from your friend that had creeping crud on it.

Shortly thereafter, your files were potentially at risk from files that you spent all day downloading from a BBS. Fairly soon after that, a malicious file could sneak onto your hard drive and cause mischief once FTPed from the Internet at a bit higher of a rate. In each case, you pretty much had to type the name of the file to run it.

Enter the world of Windows. Now running the file gets a hell of a lot easier, just a few points and clicks. And obtaining those lovely infected files gets a lot easier with the faster Internet connections and new "killer apps" like Usenet, e-mail, and the World Wide Web gaining in popularity. In less than a year, these files gain literally thousands of new vectors.

Then it becomes possible to pick up an infection by receiving a file via e-mail inside a program that loves to muck about with files before you run them by, er... running them. The only user interaction required is hitting the "send/recieve" button.

After that, malicious files no longer need to be files. They can be specially formatted e-mails, and all you need to do is preview them -- you don't even have to read them -- in order to get smacked by the latest nasty bug.

Don't feel e-mail is safe? Well, it wouldn't matter if you stopped using it entirely, the creeping crud will still get in if you click on a link on the Web. And as if the front door didn't put up a paper-thin defense, the back door will allow malware to slip in via Web server software, file shares, file transfer servers, and even instant messaging.

Now what do we have?

A malicious file you only have to point at for a moment to get an infection.

You've come a long way, baby.

I always remove ID tags anyway.

[Rai]

They just annoy me for some reason.

Re:Pathetic

[Reziac]

Thanks for a great layman's explanation. IANAProgrammer, but that made the concept perfectly clear to me.

So, if you do bounds checking, is that a 100% fix? If so, it strikes me as simple good procedure that there's no excuse for omitting.

Re:Why are there still buffer overruns?

[loconet]

I love Java and C# for managing my memory, but asking the software industry to adopt VM's for all languages for the reason of managing memory is like asking the automotive industry to make cars out of styrofoam and limit their speeds to 5k/h. You can't really do that, so what we need is concious drivers and a set of rules they must follow. In this case we need concious programmers and a set of rules they should be following to avoid the buffer overflows.

Re:XMMS too.

[Ducky]

Really? Where's the bug report? I don't see anything on bugs.xmms.org.

Sorry for sounding like an a-hole, but an AC exclaiming a bug in a product, no follow up on the product's web site, and no other info sounds very suspect to me.

-Ducky

Re:How does a buffer overflow allow code execution

[pclminion]

CS and DS are segment registers which control where the CPU gets it data from when reading code or data, respectively. A logical address is actually a 48-bit (32+16) value: 16 bits to select the appropriate segment descriptor, 32 bits to specify an offset.

What he's saying is that if the code and data segment selectors point to different memory areas, a buffer overflow becomes impossible because a data segment can be set such that code cannot execute from it.

While correct, the idea is bad because it assumes that all platforms have a concept of segmentation (definitely not the case), and that there are no impacts of setting the CS != DS. On Linux, for example, the segment registers are set to global descriptors at boot time, and are mostly unused from then on. Linux is a paging based system, not a segmentation based one.

Second, a lot of code assumes that the data segment is executable. GCC sometimes emits "trampoline" code which actually places code on the stack and executes it! There are legitimate uses of executable stack pages. Trying to change this would break too many things.

You could also prevent stack overflows by causing the stack to grow upward in memory instead of downward (because function return addresses would come before buffers in memory, not after), but nobody does this either because of some deeply ingrained assumptions in all modern operating systems.

There is no easy fix-all solution to the problem. The real way to avoid buffer overflows is to write code that isn't vulnerable to them.

Re:How does a buffer overflow allow code execution

[Sloppy]

The 80286 did not having paging or a big 32-bit address space, but it was still capable of implementing virtual memory and memory protection, through something called segmentation. The idea was that a pointer wasn't just an offset from address zero; a pointer was a segment selector thingie (as you can see I have forgotten what the actual technical term was ;-) and an offset. And unlike on the 8086, on a 286 running in protected mode, the OS would make up what segment selector thingie values were valid, exactly how long each segment was, and also various permissions that applied to that segment.

What's neat about this approach is

• If a segment overflows (i.e. you try to reference an offset that is larger than the size of the segment) then an exception is generated. Really neat for debugging.
• You can have a segment be non-executable. So if you attempt to execute code in, oh say, the stack segment or some other data segment, an exception is generated. Really neat for security.
• If a reference is made to a segment that isn't in memory right now, an exception is generated. Useful for virtual memory.

The 386 and later also implement segmentation, but people don't really use it because segmentation is a major pain in the ass to deal with. The 386 added paging, which is an easier and simpler way of doing vm, so having different segments for everything was no longer very useful. Also, the 386 made segments bigger, 32 bits (4 gig) instead of 16 bits (64k), so shoving everything (code, heap, stack) into one segment became feasible for most projects. This became known as the "flat" memory model, where pointers are just simple 32-bit values (all offsets within the same segment). This is very easy for programmers to deal with, compared to the earlier x86 days, where a pointer was a kind of compound object consisting of both a segment and an offset.

The thing is, using segments could still be useful. If you were to put up with some extra complexity and have your stack be in a different segment than your code, then you could set the stack segment to be non-executable, so that if someone puts malicious code on the stack (or somewhere else in "data" memory) then it still can't get executed w/out generating an exception.

Anyway, I think that's what he meant by CS!=DS.

Re: Virus scanning my MP3 collection

[saskboy]

You mean for once the Antivirus companies are going to HELP us?

Big difference from selling virus code to China.

Someone here has alluded that you can't scan for this malicious file. I'm curious why not?

Why would XP process data *in* files on file-copy?

[Tackhead]

> All file formats are safe, it's just the programs that read them.

The article was interesting, though: (Emphasis is mine)

"A buffer overflow exists in Explorer's automatic reading of MP3 or WMA (Windows Media Audio) file attributes in Windows XP. An attacker could create a malicious MP3 or WMA file, that if placed in an accessed folder on a Windows XP system, would compromise the system and allow for remote code execution. The MP3 does not need to be played, it simply needs to be stored in a folder that is browsed to,

What I really wanna know is why the fuck Explorer is "automatically reading" an MP3 or WMA when it's not playing it?

Building thumbnails for JPEGs, OK, I can understand that. But examining the content of a fucking audio file during a copy/move operation? What the fuck?

Ironically, the only possible use I can see for that behavior would be DRM. The OS sees "MP3" or "WMA" and says "I know you asked me to just copy some files full of bits from one directory to another, but I'm going to examine the bits in the files and process whatever metadata I find, because you might not be allowed to copy these special bits."

If that's the rationale, I can see a whole new market opening up: "Norton Copy! Works just like COPY.EXE used to do in DOS 1.0!" competing against "GNU CP! Has a few more command line switches, a 2GB file size limit, but unlike paying $49.99 for Norton you get the source code to /bin/cp!")

Very, very easy

[NineNine]

No registry hacking necessary. Just delete the file association. Open any Explorer window. Tools, Folder Options, File Types. Then delete the MP3 one. Voila. No more MP3 associations.

I just looked at the WinAmp 2 rev history

[Snork Asaurus]

It's located here. The ID3v2 support history is a bit murky. It says:

Winamp 2.09 ... "Preliminary ID3v2 support (tag is skipped reliably)"

Winamp 2.24 ... "Better support for invalid ID3v2 tags (for people putting invalid tags on)"

Winamp 2.666 (ha, ha) ... "ID3v2 support"

Winamp 2.71 ... (in_mp3 decoder) ... "Fixed id3v2 rare writing bug"

This one reminds me that one of the annoying (albeit sometimes necessary for legal and/or technical reasons) things that they did was switch decoders in various versions. My guess is that it is the actually decoder dll that has the vulnerability, and you can sometimes swap those between versions, but using the 2.81 version may lose some 'features' that certain powers found distressing :-(

Winamp 2.79 ... "Fix to id3v2+unicode support"

So, I'm not sure what to make of where the vulnerability really enters, although it may be in any version after (ironically) 2.666. Are there any folks from Llamaland around here to comment?

AT MY HOUSE

[Eric_Cartman_South_P]

Hillary Rosen kneels before me!

Re:Pathetic

[Reziac]

Thanks, that's good to know.

Seems to me the solution is to whack budding programmers' knuckles with a ruler until they get in the habit of using bounds checking with each and every buffer their program requires, written on the spot and not tacked on as an afterthought. But considering that probably half the coders out there are self-taught and still have whatever good or bad habits they started with.. *sigh*

I'm so torn...

[djcatnip]

XP is vulnerable to MP3's? I don't know if I should be in awe or laugh my head off.

Linux Security - Re:Buffer overflow yet again

[moncyb]

There is a kernel level patch so that nothing can be executed in the stack, but a lot of people don't seem to want it. Actually, I think there are two competing patches. One of them is called Openwall.

There are also libraries to combat this sort of problem as well. Such as the one another poster listed...

That would be great ..

[cje]

.. if only those functions (strlcpy, strlcat) were part of the standard C library. They are of little use on platforms where they are not available.

In the interim, it is more productive to make sure that developers are more clueful when it comes to the standard string-handling facilities in C. It is really not that much of a chore to write safe string-handling code in C; the problem is that most C programmers aren't taught how to do so. That's an education problem, not a language problem.

Re:That would be great ..

[dvdeug]

It is really not that much of a chore to write safe string-handling code in C; the problem is that most C programmers aren't taught how to do so. That's an education problem, not a language problem.

Is that your solution to all mine fields? When most users are having a problem with something, it's easier and far more reliable to fix it at the computer then to try and educate every user.

Re:That would be great ..

[cje]

When most users are having a problem with something, it's easier and far more reliable to fix it at the computer then to try and educate every user.

I don't disagree with this, but the fact remains that the set of C programmers that work in OpenBSD environments is a vanishingly small subset of the set of C programmers as a whole. The functions to which the original poster refers are not a part of the C language and are not available under any of the environments that I develop for (those being IRIX and Linux.) So if I have a choice between educating people on how to use their tools effectively and simply letting them go on blissfully abusing said tools, I tend to lean towards the former option.

Re:That would be great ..

[nestler]

OpenBSD is released (not surprisingly) under the BSD license. The source for strlcpy/strlcat is easily attainable. You're free to bundle the implementations of those two functions in your problem under the terms of that license. It's not too difficult considering how lenient that license is (even if your product is commercial).

You needn't limit yourself to the standard C library. After all, that is the library that brought you gets() and strcpy().

Re:Why would XP process data *in* files on file-co

[kesuki]

Windows XP constantly monitors all files writen to an local parition, or to a mounted network share.
it will generate thumbnails in the background on 'new' image files (or try to, that features is broken, as it always tries to see if the file has changed, and somehow decideds the old thumbnails aren't good enough and makes new ones Very annoying when you have 1000 images in one directory on a slow HD -- the thumbs.db file is supposed to Eliminate the lag time in generating thumbnails on the fly isn't it?) the finder/WMP tool in windows also keeps a database of files, for finder it needs to open text files and id3 tags so you can search for files 'containing' whatever. it does this in the backrground, not on 'mouseover' it does it all the time. for WMP it adds the files to the 'media library' if it's in a directory you specified, but I suspect it keeps track of all media files, not just the ones you've told it to tell you it's monitoring.
That's right With windows XP not only do you not have to open the folder you just have to finish downloading it -- and then windows goes "oh look a new file! let's see what we can monitor about it! *HD grinds as XP reads metadata*"
if you want to disable the service that does this go to http://blkviper.com/ he lists all the XP services and what they do.

Re:Pathetic

[CynicTheHedgehog]

That, or use a language like Java or Ada that do automatic bound checking, or a language like Perl or VB that uses dynamic buffers (they grow to the size that you demand). This promotes laziness, however; much optimization can be done by omitting bound checking when none is needed. For example:

for( int i = 0; i < strlen( str ); i++ )
{
str[i] = toupper( str[i] );
}

In this case we know what we're doing, there's nothing to exploit, and we saved ourselves strlen( str ) * 2 instructions at least. Perhaps not a tremendous boon, but it can add up. In higher level languages we don't have that option, but it's nice because we don't have to work about it either.

Re:Does it exist on older versions?

[anotherone]

Since the original ID3 tag specs only alloted 256 bytes of info (maybe a little more, I'm not sure). According to the version history of my copy of winamp, ID3v2 was first supported in 2.09, so you might want to upgrade. There's no reason not to, really, it hasn't really gotten a lot bigger and it's much better.

Don't go for Winamp 3 though, it sucks balls. 2.81 is the best ever.

True Audiophile cables!

[Theaetetus]

Hence why audiophiles hate modern sound systems - it is far too easy to get great sound reproduction nowadays, and how are you to demonstrate how large you are when a $19 CD player sounds as good as your $3000 turntable?

That is why audiophiles use "oxygen-free copper wires with authentic virgin yak wool insulation, cryogenicly treated to release signal-distorting sub-micron strain! A steal at $300/ft! Act now, and we will throw in our patented Feng Shui turntable stones - five of these will disgronificate your turntable! Normally $150 each, but a steal at $800 for a set!"

Bah, $300/ft? Are you kidding?
From Purist Audio Design:
-------
Dominus Speaker Cables (1.5 Meter)

Stereo pair of Speaker cables with fluid jacket. For more information on product, see the Product Page. Item weight per pair is 14.0 lbs.
Price each: $10,460.00
-------
So, that's about $2500/ft.

Bwhaahaahahahaha!! /me wipes eyes.

And for the record, I am not an "audiophile". I'm an audio and broadcasting engineer.

-T

So...

[Guppy06]

"WinAmp versions 2.81 and 3.0 are vulnerable to buffer overflows via certain long ID3v2 tags when MP3 files are loaded."

... the 2.80 that came with Netscape 7 is safe? HAH HAH! :)

Really? Which tools do they use?

[alispguru]

I guess it also depends on the meaning of the word "use". If by "use" you mean "they pass code through it, then pass their eyes over the report", that's not particularly useful. "Use" should mean "they pass code through it, and code with warnings of severity level X or worse does not ship".

It's the same craftsmanly drive that keeps you from shipping code that generates compiler warnings. Oh dear -- I suspect you're now going to tell me they ship code that compiles with compiler warnings. Yecch...

Re:Pathetic

[ergo98]

Seems to me the solution is to whack budding programmers' knuckles with a ruler until they get in the habit of using bounds checking with each and every buffer their program requires, written on the spot and not tacked on as an afterthought.

There is a downside to bounds checking though: The natural evolution of the idea is a "managed" model like .NET or Java- While they offer safe evirons, the extensive checking that they bring along with them (including garbage collection which is, to me, an absolutely ridiculous idea) is computationally costly. This is the reason why a Java applet on your super faster Athlon 2400+ feels like you're running a 486.

But considering that probably half the coders out there are self-taught and still have whatever good or bad habits they started with..

This has nothing to do with being self-taught or not: It has to do with the standards and processes that an organization sets on its code. It also has to do with a boss saying "I want all these features by next week as the top priority!" in reply to "I should probably spend some time hardening the code and auditing it for potential exploits" (a very, very common scenario).

Focus, Pace, and Bugs.

[_Sprocket_]

Last, I have trouble understanding how so many of these bugs come from a company with many of the brightest programmers. Is it a largely problem of scale and bureaucracy?

There are two interesting points to touch on.

First is that awareness of security issues is not automatic. I used to believe infosec issues were just a part of being a good system admin. Then I found myself working for a very forward-thinking IT company. And also found my group (corporate infosec) in constant struggle with the internal IT group over various issues - even basic infosec procedures. Its not that the IT group didn't have good admins - many were far better sysadmins than I ever was. Its that being familiar with a system does not mean one understands how to maliciously fail a system... or appreciate that people will seek to do just that. Infosec involves a healthy dose of paranoia. Not everyone has that.

Secondly, Microsoft is simply not geared to handle infosec issues. Microsoft is not run by developers and code quality is, at best, a minor focus point.

There was an article in Slate a few years back from an inside developer involved with Outlook (or Office - I forget which). One of the interesting tidbits of insight was that bugfix cycles always take a back seat to feature additions. The article noted that it wasn't too uncommon to be in the middle of a bughunt and have Marketing come down with a must-have feature to be added in. Bughunting would stop. Feature would be added. And now there was even less time to an already time-crunched bughunt cycle (and possibly new bugs generated by the new feature code).

There is also another intersting insider article that talks, amoung other things, the pace that Microsoft keeps. Its a fast pace, to say the least.

Is it any suprise that, under the pressure of this ultra-fast pace... one being driven by marketing, not development... that bugs make it to the final release? That there may be a fairly high number of bugs? And that these bugs may be exploited in a security context?

Re:Effects more then you realize (ID3v1 vs. ID3v2)

[kesuki]

Which is what makes this exploit so important. A malicious virus could easily connect to gnutella or kazza and start replying to mp3 queries and claim 'oh i have that mp3' and only accept downloads for the 'start' of the mp3, and give them a bogus id3v2 tag, complete with self-propigating code. It then cuts off the user so they have to finish thier DL elsewhere, and they end up with a valid mp3 with an invalid id3v2 tag that auto-infects and self replicates.

Good thing there are patches out there... so we don't have to have a repeat situation like code-red of the various outlook virus. Doh, there were patches for almost all of those virus when they propigated too!

old news or winamp site not updated?

[Narcocide]

winamps site still says the current version of winamp3 was posted in august. is that the fixed version this post is referring to or am i missing something?

Re:Except that C...

[spongman]

Not necessarily. It would be simple for a JIT to recognize that the for's terminating condition was sufficient as a bounds-check and yank the check for the array index. Microsoft's .NET VM does exactly this.

Re:Except that C...

[green99]

Not true. In the above case, the bounds checking can be easily optimized out. From Sun:

Compiler Optimizations

Range check elimination: The Java programming language specification requires array bounds checking to be performed with each array access. An index bounds check can be eliminated when the compiler can prove that an index used for an array access is within bounds.

(from Hotpot Documentation)

Which would be trivial in the case supplied.

Re:Except that C...

[Jetson]

for (int i = 0; i < a.length; i++) a[i] = i++;
Each access a[i] is needlessly bounds-checked.

Except, of course, that you're thinking in terms of a single-threaded application. The a[] array could conceivably change size in one thread while being iterated by another....

Checked; no update

[myowntrueself]

I just uninstalled my old winamp 2.81
after checking the version history,
and d/l'd the one on the winamp site,
installed it and checked its version history.

There really is no difference; its not 2.81c or anything; its identical.

Their site contains no references to this bug (that I could find).

Re:Except that C...

[PurpleFloyd]

I don't see how that would affect anything. Since you check against a.length (rather than a constant), once i hit a.length, you would end the loop. While you might hit a bug with the loop terminating early, it would never terminate late (and thus overflow).

Re:Why would XP process data *in* files on file-co

[rutledjw]

What are you talking about? Windows may need to read file info when the file is SELECTED, NOT when the directory is opened.

Further, you know an AWFUL lot re: windows for someone "Running Linux since '96", and then you BLAST people who criticize Windows, and you reply primarily insults and technical points of dubious validity, and...

WAIT A MINUTE! You're a - a - a Troll in penguin's clothing!. Nice touch though, I especially like the sig...

Re:(OT) Note to moderators

[jez9999]

I think the mods understood the technical content of the post, and modded it flamebait.

And flamebait is for posts which are utter BS :-)

Re:Pathetic

[dvdeug]

There is a downside to bounds checking though: The natural evolution of the idea is [...]

But that's just a slippery slope argument. You have to pick the abstractions you can afford - bounds checking is on by default in Ada, but garbage collection is a mostly-unoffered option - but BC doesn't imply GC, anymore than a lack of bounds checking implies machine language.

including garbage collection which is, to me, an absolutely ridiculous idea

Why? It catches another huge class of bugs - memory leaks - and simplifies programming - you no longer have to worry about whose responsibility it is to delete every little bit of memory. It seemed to work well enough back in the eighties, on Lisp Machinese - somehow, with a thousand times the computational power, we no longer have the power to spare?

Re:Pathetic

[dvdeug]

for( int i = 0; i < strlen( str ); i++ )
{
str[i] = toupper( str[i] );
}

In this case we know what we're doing, there's nothing to exploit, and we saved ourselves strlen( str ) * 2 instructions at least. Perhaps not a tremendous boon, but it can add up. In higher level languages we don't have that option, but it's nice because we don't have to work about it either.

But in

for I in Str'First .. Str'Last loop
Str (I) = To_Upper (Str (I));
end loop;

no half-decent Ada compiler will do any bounds-checking either, as it can be trivially inferred from loop bounds that everything inside is in bound.

Curious...

[ColeNielsen]

I've been a winamp user since windows 95 -> I've been a Micro$oft user since DOS -> I still use winamp because it's small, takes up nearly no memory and doesn't tax my processor with the right settings. It doesn't surprise me that this [vulnerability] was discovered, I knew that I could download an mp3 and it could harm my computer back in the day so I guess that someone finally decided to announce that they were unsafe??

If the name Micro$oft appears on a product, it's guaranteed unsafe... if you are running a product on a Micro$oft product, it's guaranteed unsafe.

I know Linux isn't perfect[to some it is], I know MAC OS isn't[to some it is], I know Windows isn't perfect[If anyone thinks it is, get informed then talk to me] Each have their own good and bad points but one of these takes the bad points from the other two, multiplies them by 10 and puts a price tag on it that is insane compared to the other two... GUESS WHO?

Informative??

[Theaetetus]

Should be +1 Funny... Or maybe +1 Ironic.

Informative implies that I think that people should go out and buy these cables.

-T

Re:Pathetic

[susano_otter]

The reason exploits like this keep showing up is there's a hell of a lot of buffers in any program, and it's pretty easy to forget to bounds check one of them.

And there's no way to automate this? Maybe have a compiler that alerts you when it's compiling a piece of code with an unchecked bound?

Re:Why would XP process data *in* files on file-co

[Seehund]

What I really wanna know is why the fuck Explorer is "automatically reading" an MP3 or WMA when it's not playing it?

Rest your mousepointer over an .mp3 or .wma in an Exploder window. Up pops the ID tag info.

What I wanna know is if/how this "feature" can be disabled. It's horribly annoying when you accidentally leave your mouse pointer for too long (one second or so) over a huge .zip backup archive. The machine locks up while listing the contents to display a summary. If the .zip is on a slow network share, you're fscked.

Hey, this buffer overflow vulnerability could theoretically be exploited in just about every type of file that Windows recognises and has a "preview" action for, right?! Scary.

Re:Except that C...

[21mhz]

In Java, arrays cannot change size. Though, an adjacent posting hit the nail on the head: leave the obvious optimizations to the optimizer.

New URL

[Compact Dick]

Foobar2000 has a new homepage. Version 0.3 has also been released.

For those wondering what to expect, foobar2000 has a minimalist interface, but it does the job. CPU usage is very frugal and your MP3s can sound noticeably better. Why? Because clipping prevention is built-in, removing any distortion induced by overly loud signals.

I am currently running 0.3, and it's a beautiful piece of work. If you want a multi-format player that runs unobtrusively in the background while you do your other stuff, then foobar2000 is for you. At 168 KB, it's worth trying out.

You are a smart man!

[toupsie]

I just gained 600MB of my hard drive back.

So, what you are saying, is that by coverting from MP3 to Ogg saved your 600MB of space on your hard drive. With 7200rpm, 80 gig IDE drives costing around $100, you just saved yourself 50 cents! Equiv to the cost of one CD from Staples in the generic 50 CD spindle.

Rock On!

Re:How does a buffer overflow allow code execution

[pclminion]

You could have done a Google search...

GCC Trampolines