Infection via playing an mp3?

Hi,

I guess I already know the answer to this (yes), but I would like a more information rationale behind my thinking. Is it possible to infect a Linux system by playing an mp3?

Consider the situation where there is some kind of bug processing the stream read from the mp3 file. What can someone realistically do? Maybe run a command? Is this even possible or has it been done before?

Thanks for any insight.

- stonee

First... I do not know of any such bugs, but if there were one...

It would be a hole in the player, so that would be a factor, and on Linux, there are so many players used it is not a likely path of attack...

Assuming that there is a bug that targets your player, and the file is infected... arbitrary code execution _might_ be possible. But it would be limited to the rights of your user account. You aren't using xmms while root? right?

There are too many ifs here. Gimme a more specific set of circumstances...

Consider the situation when you download an mp3 from some p2p application. You download the file and try to play it on xmms. What should you be concerned with?

As an alternative situation, consider someone having access to your system. Is it possible for them to infect one of your mp3s somehow? Lets say that chop up your mp3 in some way so that you can still hear the music playing, but there is some alternate processing going on that allows them to execute arbitrary code.

Is this possible or am I just too paranoid?

If xmms contains a bug it might be possible to take control.. But I highly doubt you'll still hear music.. It'll probably crash xmms in the process..

stonee,
its possible but extremly difficult to keep the music going and run the malicious executable code hidden in the stream.

Depending on the bitrate and sample rate, frames of mp3 stream are characterized by a sync word FF FA, FF FB or FF FC and so on. So what I would do to be sure no malicious code is present besides using antivirus, is open the mp3 file in hex editor and remove everything before the first FF FB(for 128kbps 44khz songs) or FF FA (try out and see for yourself what the bitrate and sample rate combinations are). Yes that will remove the id3 tag (famous for overflow attacks in the passed), then look into how big the frame chunks are (they should be constant size) and remove the end of the song if there is anyhting after tha last frame. Stuff can be hidden in between the frames or in the id3 tags. By making sure you have no executing code in between frames or in the id3 tag you're on the safe side.

But i guess even then, someone can overwrite the contents of any frame after the frame sync with a jump or some executing code while perserving the number of bytes between sync words (FFF). In that case the bitstream parser would crash stopping the music and starting the malicious code.
I guess you'd have to debug the mp3 decoder with the song you're suspicious about as input to be able to monitor and control behavior stopping the malicious code before it does any damage.

There is however one other way to keep the bitstram parser happy(playing the music) while code, originally hidden in the bitstream is executing. Watermarking...
To date I haven't seen or read anything about mp3 virus code hidden as watermark. For that to work you need watermark extracting code (usually a plugin) which itself is not malicious and not suspicious but extracts malicious payload hidden in the content of the music.