April 26, 2002

8:45 PM

Terminal Errorwas the schlock movie of the week tonight on the Pax network... featuring an intelligent virus spread by - wait for it - MP3 Files. How much do you suppose the RIAA pay for that gem?
posted by Maxor (24 comments total)

There really seems to be this widening gulf in the world, between people who understand and love technology and those who think it's some kind of beast out to steal your car and eat your children.
And there are those, like the RIAA, who will exploit that fear to their own ends.
This all saddens me because many of the technophobes I know are people who would be doing amazing shit with computers if they could take Chuck D's advice and not believe the hype.
posted by jonmc at 8:55 PM on April 26, 2002

It's just like a slasher film where all the copulating teens get cut in half...

Archtypes of horrible consequences befalling those who indulge in delicious sin (like sucking down whole albums online) are everywhere.
posted by scarabic at 8:58 PM on April 26, 2002

This, too, shall pass. Twenty years ago there were people who really believed that computers would become sentient and take over the world. Today there are probably people who think you can execute MP3 files. At least the misconceptions are becoming more sophisticated, which seems to me to be progress.
posted by kindall at 9:06 PM on April 26, 2002

despite the fact that mp3s spreading a virus (in and of themselves) to be absolutely preposterous. mp3s aren't run like a program for they are simply data files. (if an mp3 player were to collaborate, and an mp3 player was simply an executable file ending in .mp3, then i could see a virus hit.)
posted by moz at 9:06 PM on April 26, 2002

whoops; that second "mp3 player" should have been "mp3 file."
posted by moz at 9:06 PM on April 26, 2002

If you didn't see the movie, rest assured, it was hilarious.

As soon as the computer screen says "downloading music" the scary orchestra kicked in. The letters MP3 were in huge red letters. It's obviously a plot by the RIAA to scare the uninformed into thinking that MP3 is evil.

OMG! Run before the MP3 virus sends a nuclear missle hurtling towards you! (No joke, that was the movie's climax!)
posted by Maxor at 9:10 PM on April 26, 2002

It's not that far from the truth, thanks to Microsoft's freedom to innovate. Windows Media Player will open WMF content embedded in MP3s as they are played, according to a recent Bugtraq item. All we need are a few more hooks for executable scripting and MP3s can be as much of a security issue as e-mail read by Outlook Express.
posted by rcade at 9:11 PM on April 26, 2002

If you taped it (or downloaded it - ha!) save it - it will eventually be another classic.
posted by yhbc at 9:20 PM on April 26, 2002

I hate to break it to you folks, but it is not inconceivable for a virus to be spread by a stock mp3 player. All it would take is a buffer overrun exploit. Unlikely, but well within the realm of possibility.
posted by NortonDC at 9:53 PM on April 26, 2002

It could happen. Say someone finds a buffer overflow exploit in a popular *cough* winamp *cough* mp3 player. Get a nice random mp3 selection across all genres of music and enough bandwidth to serve these up on audiogalaxy/kazaa/winmx and you'll fuck up a lot of people's machines.

Err, what NortonDC said.
posted by skallas at 10:23 PM on April 26, 2002

for those who don't understand what a "buffer overflow" is, it's a term used to describe a scenario where a program attempts to access memory that the operating system hasn't expressly allowed it. the operating system can't let the program mess with the memory used outside of the program, so lacking any other course of action, it stops (crashes) the program.

buffer overflows are an issue mainly when you must log into a computer as a certain user. i don't understand how buffer overflows can be exploited on windows, for all of the stories i've heard of them as a security issue concern unix. some programs on unix require access to files that normal users typically don't have; unix allows some programs to promote themselves to administrator (or other user) level (these programs are often called "setuid"). when the program crashes, the access level of the program is retained. i could then write a program that runs the program, crashes it, and then do other stuff (like wipe out your hard drive).

after all that, my questions are:

1) wouldn't this only be an issue on unix (or mac osx) for the most part?
2) wouldn't this basically imply that winamp (or whatever mp3 player) must be run as the superuser? i'm not sure if normal users are allowed access to the sound card device on many unices, but certainly on osx normal users can play sound thus making the need for an admin-level mp3 player unnecessary.
posted by moz at 10:51 PM on April 26, 2002

A buffer overrun in an MP3 player is very, very unlikely due to the way MP3 files are typically loaded a piece at a time.
posted by kindall at 11:04 PM on April 26, 2002

there was a discussion on fark today and apparently winamp's mini browser can be exploited to cause some damage.
posted by pinto at 11:14 PM on April 26, 2002

Moz - the way you exploit buffer overflows on windows machine is to include executable code in the overflow. Basically, since all of the code can't be held in the space the programmer allowed for, it spills over into memory. It is as if the user actually executed the code.

An interesting history of buffer overflows here. Page 2 lightly touches on how they are used on Windows (usually you execute an HTTP request to download something like back orifice and execute it).

Some very techy details here.
posted by willnot at 11:41 PM on April 26, 2002

Kindall, the ID3 tag is a potential vector.

The essence of a buffer overflow is feeding a program more input than it's expecting. The excess beyond what's expected may be (in a sloppy program) shoved directly into RAM at an address within the boundaries assigned to the program reading the input, and then soon afterward the program goes back to that address to look for it's own next instruction to execute, but instead executes the code jammed in there by the buffer overflow.

Look here for a thoroughly explained and concrete example for Windows.

[reads pinto's link]
Huh, it was the ID3 tag.
posted by NortonDC at 11:41 PM on April 26, 2002

jinx
posted by NortonDC at 11:42 PM on April 26, 2002

I think this is one of the most informative threads I've ever read on MeFi. Thanks.
posted by Hackworth at 11:58 PM on April 26, 2002

Moz: That's only partially correct. Some types of buffer overflows can be used to run arbitrary code as the user of the program being run. Basically, you overwrite all the code in the program and run your own; this is a simplified and not-entirely-correct-either explanation but it's close. This affects all OS's (Windows has lots of these), and in fact is more dangerous on the old Win 9x systems (at least in a multi-user environment you should be able to limit the damage). For those with a technical bent, this article is a great explanation.
posted by elvolio at 9:33 AM on April 27, 2002

The other fact about buffer overflows is they should never happen in a properly written program. All inputs should be checked, and either truncated or discarded if they are longer than the buffer created to hold them. We've known this for years, and we still have people doing it -- and the fixes are usually trivial.

(Another problem is languages and compilers that assume that the best way to handle a 1000 byte input into a 900 byte buffer is to just let the 100 extra bytes go where they will. There's also the data-instruction problem, but fixing that would require us to toss the X86 and PPC boxes we use now and start over.)

I don't know how many 1-3 line patches I've seen that fix some overflow, but it's in the hundreds now. My life anymore at work is "Read Bugtraq, apply patch, recompile. Repeat until disgusted. Go home, read paper book, which rarely needs patching, and never takes over my water heater."
posted by eriko at 9:53 AM on April 27, 2002

elvolio:

Some types of buffer overflows can be used to run arbitrary code as the user of the program being run. Basically, you overwrite all the code in the program and run your own;

it seems to me that this exploit depends a great deal on the luck that

1) there is a buffer overrun condition in the program, and
2) the buffer in memory is stored in close proximity to the instruction area of memory where opcodes are held.

many buffer overruns in programs i've written crash the program because they aren't near any other area in my program; beyond the bound of the vector they access unassigned memory, which causes a core dump. i've had a few times when they don't crash, but have modified a variable in the program elsewhere, and i suppose if you write enough code you might come near the instruction stack (assuming that may follow the data heap). allocated memory, that being neither sequential nor guaranteeably close to any memory used by your program, would seem to be pretty safe from buffer overrun exploits even if the code itself were weak enough to allow a core dump.

even assuming you could write long enough to reach the instruction stack via buffer overrun, it would seem to be real tough to ensure that you'll know precisely when you've reached the proper place to be in the stack that your code can be executed. a shitty way to spend the afternoon.
posted by moz at 11:27 AM on April 27, 2002

moz - Buffer overruns/overflows are deep voodoo, but they are also real. My earlier link is a concrete example, if you wish to see their reality demonstrated.
posted by NortonDC at 11:44 AM on April 27, 2002

i know they are possible norton -- i have not doubted their existence -- i merely pointed out the difficulty in finding and exploiting them.
posted by moz at 12:29 PM on April 27, 2002

Just a note, if you want to fix the WinAmp vulnetability mentioned above upgrade to the newest version, 2.80 released a few days back.

I know I have.
posted by nedrichards at 4:21 PM on April 27, 2002

vulnetability

I'm going to steal that.
posted by NortonDC at 4:25 PM on April 27, 2002