Slashdot Mirror
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."
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.
Beware: In C++, your friends can see your privates!
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.
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?
I was sent and installed the fix before I read about the vulnerability.
It's Christmas everyday with BitTorrent.
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?
I don't need no instructions to know how to rock!!!!
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.
"I won't mod you down - I feel the need to call you a twit explicitly, rather than by implication."
The file winamp.exe is exactly the same.
As it should be. ID3 tags are handled by the in_mp3.dll plugin.
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.
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.
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
- For the complete works of Shakespeare: cat
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.
Jakob Breivik Grimstveit
"I love deadlines. I love the whooshing noise they make as they go by."
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.
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.