er… Lite, not List.
It was just FUD from a major anti-virus company,over on slashdot.org they ripped the claims to shreds and pointed out how there is no way to execute the code just because it is there when this story was released.
My KazaaLite had .vbs files automatically blocked in the filtering section of the configuration.
~2 years ago, a buffer overflow was indeed found in the standard LZW* decompression code used in a lot of products including Zip, some MS decompressors, and many gif decompressors. There were urgent security updates issued for these programs. Because of the quick reaction once the problem was found, I don’t believe any exploits were distributed by the script kiddies.
The zlib compressor/decompressor library, which is used in a lot of packages including ones by MS, continues to have security/overflow issues. See the bottom of this page. I doubt that other codecs are magically without flaws.
Image files (and many others) can have bad code to exploit broken codecs.
*If you read about “LZW” compression, it really should be “WZL”.
Heh. Buffer overflows can occur anywhere someone grabbed some data for input and didn’t bother to check how much they got. Believe me, they can happen almost anyplace.
Not checking is fine for submitting to your TA, or for in-house use, but once something reaches the jerks outside, someone’s gonna see what happens when random entries in your config file reach 256 character long.
Anyhow, there are buffer overflows to be found. Beware the ID3 tag:
Winamp 2.79
Media Player
What exactly about an mp3 player do you think makes it immune to buffer overrun attacks? You think it’s impossible for someone writing an mp3 player to make an incorrect assumption about the input data which leads to an exploitable buffer overrun? Or is it that you don’t actually understand how a buffer overrun attack works, and are just making stuff up?
PS: Hate to break it to you, but Microsoft didn’t popularize the buffer overrun vulnerability. Maybe you meant to say “sendmail”.
if KaZaA did put viruses in the files, THEY’d probably gets sued. why not if a theif can sue the family who house he breaks into if he’s injured?
What exactly am I “making up”, sunshine?
Here’s what I said:
Please tell me what is incorrect about that. I asked a question - buffer overflow? And then I said that not every program or type of media is automatically susceptable to buffer problems.
And no, I certainly don’t think that programmers can fail to write bad software. I’ve written many things myself that have screwed up and over-run buffers. My chat server that I’ve written from scratch has such a serious buffer overrun problem that I’ve had to table it. And I’ve fixed many a bug related to buffer overruns caused by other people, like plopping a 1,000,000-byte char onto a statically sized 1,000 byte char. My favorite was the Unix geek who wrote about 250,000 lines of code for me and said “what do you mean strings need to be null-terminated? Unix doesn’t do that!” (he’s wrong, BTW, thought I would tell you that)
So tell me - I want to see your proof that every type of media and every program is susceptable to buffer problems. And try to do it without sounding like an asshole and taking another cheap shot at me, mmmkay?
Otherwise, we’ll finish our conversation in the Pit.
Anthracite
I seriously cannot think of any class of programs that has not in some incarnation or another suffered from buffer overrun problems.
Quick time has buffer overrun problems.
http://www.esecurityplanet.com/trends/article.php/1461221
Realplayer also has problems.
http://www.techtv.com/news/security/story/0,24195,3408953,00.html
winamp has issues.
http://archives.neohapsis.com/archives/win2ksecadvice/2001-q1/0046.html
I got out of bed for this thread? (actually, to use the loo, but oh well) 
Seriously, I’m not saying that it’s not possible, or has not already happened. I agree with you completely. But from talking to Fierra today about MP3 encoding algorithms, I just can’t see how one could make a generic MP3 hack which would cause buffer overruns in all players that could play it. Maybe I’m just being too literal here, and if so, I apologize to you for the misunderstanding. I mean, at heart, I’d really like to see how the MP3 code could be done in a way to affect all players - it would have to be a base CODEC flaw, wouldn’t it? 
Doesn’t have to be all players,who would want to exploit something like Zoomplayer with a couple thousand uses?
Windows media player and Winamp exploits would cover 95% of users.
Ok, so it’s not technology that gives you problems – it’s logic. You implied that it’s ridiculous to think an MP3 could be the source of a buffer overrun attack, and I took exception to that implication, because it’s wrong. Now you’re asking me for proof of something I don’t claim, because you’re confused.
Sorry if you think I was being an asshole, but you were pretty clearly suggesting that gazpacho was silly to think that a buffer overflow attack could occur from an MP3 file. How else can your post be interpreted? If you’re not disagreeing with gazpacho’s first post, you’ve got a funny way of showing it.
Ha ha! I am safe, once again, from the meddling of virus writers, through using obscure software.
oh, and a minor hijack: protecting yourself from common hacks can be as simple as changing the drive letter of your system drive. So many badly written viruses just look for C:$WIN\whatever. If you don’t have a C drive…
Did you not see my last post in this thread? It’s several hours after this one you made. I thought I explained myself perfectly well in there.
And you haven’t explained your “Or is it that you don’t actually understand how a buffer overrun attack works, and are just making stuff up?” crack either. You going to justify that one somehow? The ball’s still in your court.
Yes, it’s obvious that since posting your message where you erroneously implied that gazpacho was being ridiculous for saying mp3’s could have buffer overrun attacks, you’ve become educated and changed your mind about it. That doesn’t change the fact that you were spouting off in your first post, so my “just making stuff up” comment stands. If you have a problem with that, you need to justify what you said or admit it was wrong.
Specifically, when someone says “some mp3 players could suffer from a buffer overflow bug which might be exploitable”, and you respond “buffer overflow … in an MP3? ” and then go into a little rant about how everyone is so wrong to think buffer overflows can happen in any file type, you have no leg to stand on. It makes gazpacho look bad when he is, in fact, absolutely correct. In addition, someone less technical that doesn’t understand the absolute irrelevance of your statements is likely to come to the conclusion that mp3’s cannot have buffer overflow bugs. That’s something we like to call “spreading ignorance” (at the expense of someone who is trying to fight it) and that is why I called you on it.
Think about this: what points exactly did you intend to convey in that first post of yours? Were you intending to make it look as if gazpacho was wrong? Were you intending to imply that buffer overruns in mp3 files are impossible? Were you intending to make it sound as if a discussion of said buffer overruns was mindless hysteria? Because that’s what you did.
And just to be perfectly clear about your grasp of logic, the original argument was this:
and your current position boils down to:
Congratulations on disproving an argument that was never made. That’s called a “straw man”. What exactly are you disagreeing with?