One of the reasons I don’t get MP3’s from P2P programs is that I’ve heard that they can contain viruses.
The question is: how can an MP3 song contain a virus? Isn’t an MP3 song just a file containing info on what sounds to play?
Is it done via the infamous buffer-overflow method?
If yes, can’t Microsoft once and for all fix this buffer-overflow problem? i.e. find a solution that stops all future buffer-overflow virus attempts, instead of issuing patches as virus attacks emerge.
If it’s the one I think you’re thinking of, then yeah.
Other operating systems notwithstanding, it’s not a Microsoft issue. If a program wants to overwrite it’s own code when reading in data, that’s up to it to do. ‘Best practices’ involve checking buffer sizes and using functions where the maximum length is known ahead of time, but this kind of thing still happens occasionally.
The Wikipedia page on buffer overflows shows how they occur, and has some current ideas on prevention.
Most of the virus and spyware problems with P2P apps is either spyware bundled to the p2p apps like Limewire or items that are titled like music that are actually executable files that a less saavy user might click on assuming it will open the default player when it actually installs a virus.
To add a note, such a file would most likey not work if it was opened within the music player, and the user would delete it just thinking they got a bad/corrupted download.
drachillix: True, but I’m pretty sure Polerius is thinking of the Winamp buffer overflow specifically.
And I’m posting again 'cause I knew there’d be at least one exception I’d forget:
While the standard Von Neumann machine treats data and code in a similar mannar, vario0us people in the industry think it’s time to stop that. Thus the introduction of the ‘No Execute’ bit. The idea being that you can mark the space you intend to use for memory as being non-executable, thus anyone attempting to store code there for use in a buffer-overflow attack won’t be able to run it. It’s supported to various degrees by various operating systems.
Yes it is possible to prevent. IBM’s AS400 has an architecture that does not allow the buffer overflow problem (it uses a similar feature to the one being introduced into the x86 world as mentioned by Nanonda).
The problem for Microsoft is one of history. Originally PC’s were not networked and security was not really an issue. Now it is an issue but it’s not something you can change overnight. If it was a priority for Microsoft (which I’m not sure it is), they would have a monumental effort to replace all of that code, coordinate with hardware vendors, re-train programmers in different techniques, build/change development tools, etc. etc. It may happen, but it won’t happen quickly.
It’s fixable, but Windows and x86 weren’t generally built with security as their top concern. Moreover, they’re held back by backwards compatibility and hardware diversity. Even Microsoft can’t force everyone to abandon the old ways overnight.
Windows is getting better and better. XP is a huge leap over previous versions ('cept maybe 2000), and hopefully Vista will be even better.
And Nanoda already talked about the hardware side of things, with DEP appearing in all the new AMD and Intel processors.
BTW, it’s not just MP3s that are subject to this problem. There have been buffer overflows in WMFs, JPGs, and probably others. At any given time, there’s always a shitload of attack methods, both discovered and undiscovered, patched and unpatched, waiting to break through your machine. I’d do what I can to protect myself, but I wouldn’t stop listening to MP3s or viewing images altogether.
There are enough people out there who will download SomeCoolSong.mp3.exe and double-click it to listen, rather than opening it from within a player application to make this an entirely worthwhile method for virus writers.
Just to add a bit of clarification:
Most ordinary computer users don’t change options in Windows to do things like display filename extensions, thus, most of the files on their computer are just filenames with no apparent extensions. The very simple exploit here is that anyone can write a virus or program, name it “somecoolsong.mp3.exe” and distribute it to hopefully just such unwary users. When such a user downloads such a file, because they never changed the option, they normally have file extensions hidden. Since Windows only treats the characters after the last period in a filename as the extension, and since a filename may contain as many periods as you please, anything that comes before the last period is displayed. Thus, “somecoolsong.mp3.exe” only shows up as “somecoolsong.mp3” on such a user’s machine. double-clicking it, obviously, will not queue it into one’s media player, since Window sees what it really is and executes it as a prorgam.
This is one of the first things I change when setting up anyone’s computer.
The design decision to hide known file extensions from users has cost countless hours of time and hassle for Windows users. If Vista does anything right it will get rid of that horribly deceptive default setting.
Thanks, this is is interesting.
Why couldn’t the stack frame just be split in to two distinct pieces: call stack and local variables? The processor then prevents direct memory access to the call stack and allows modifications only via dedicated call/return functions.