Virus - Free Music



  • On this page it has this :

    Click BELOW for LEGITIMATE, HIGH QUALITY,
    VIRUS-FREE MUSIC from the WORLD'S TOP ARTISTS!

    Yah for virus free music !! I once listen to some music i downloaded that had a virus and i got really sick.

    Really, since when can music have viruses ?
    ( Yes, I am aware that there were some vulnerabilities in WMA that allowed this )



  • Well, I'm guessing these songs are not included, then: http://www.google.com/search?q=lyrics+virus, or maybe they've made sure the songs don't contain subliminal messages? [;)]

    There's one hoax MP3 Virus warning floating around still, and there was a recent exploit for winamp. That wasn't a virus, though, but simply an exploit of a winamp feature. Pretty much the same as you get some movies that claim to be DRM'ed and instead of retrieving a licence from the web site go and spawn dozens of popup windows, try to install Active-X controls and/or diallers on the victim's machine, when all he wanted was to watch some amateur pr0n.

    um

    At least that's what I heard. [:$]



  • I'm thinking that if you embed a virus in an mp3, your player would
    just play it as sound and your speakers would output peculiar-shaped
    static.



  • I just imagine that this is refering to the idea that you can download
    music from these people without fear of downloading viruses
    instead.  When I was young and stupid and, synonymously, a Kazaa
    user, I once downloaded a malicious program (poorly) disguised as an
    mp3 file.  It was named
    "ReallyLongNamedToDistractStupidPeopleLikeMeFromThisFilesExtension.mp3.vb"
    or something like that.  I ran it, and before I realized how
    stupid I had been, nearly every .jpg, .gif, .bmp, .mp3, .wma, and .avi
    file on my computer had been replaced by a copy of this program. 
    So, yeah, I'm betting you don't get that kind of crap from these
    people, or at least, that's what they're claiming.



  • I'd be instantly suspicious if someone claims to offer a 'virus-free' product. Might just be me though, but why state something that obvious?

    Drak



  • @dhromed said:

    I'm thinking that if you embed a virus in an mp3, your player would
    just play it as sound and your speakers would output peculiar-shaped
    static.




    Theoretically, yes. In practice, it's possible for a player to contain
    a vulnerability in its file parsing code such that a file containing
    certain malformed data would cause the player to execute part of that
    data. It's not really any different from your "regular" buffer overflow
    vulnerabilities where malformed user input can cause execution of
    malicious code embedded in it. IIRC not long ago a very similar thing
    occurred in some Windows JPEG decoding library, making it possible to
    embed a virus in a JPEG file.



  • @brazzy said:

    @dhromed said:
    I'm thinking that if you embed a virus in an mp3, your player would
    just play it as sound and your speakers would output peculiar-shaped
    static.




    Theoretically, yes. In practice, it's possible for a player to contain
    a vulnerability in its file parsing code such that a file containing
    certain malformed data would cause the player to execute part of that
    data. It's not really any different from your "regular" buffer overflow
    vulnerabilities where malformed user input can cause execution of
    malicious code embedded in it. IIRC not long ago a very similar thing
    occurred in some Windows JPEG decoding library, making it possible to
    embed a virus in a JPEG file.




    This type of thing has always comfused me.  Why would an
    application, upon receiving screwy data from a jpeg, mp3, or whatever,
    say, "Gee, this makes no sense...guess I'll go ahead and execute
    it."  Methinks I need to go read up on buffer overflow exploits,
    so it'll be less of a mystery to me.



  • I'd be instantly suspicious if someone claims to offer a 'virus-free' product. Might just be me though, but why state something that obvious?

    Drak

    I suspect it may have some thing to do with the number of people who use ( unpatched ) Windows/IE and think they get their viruses throught the mp3s they download.


  • @UncleMidriff said:

    This type of thing has always comfused me.  Why would an
    application, upon receiving screwy data from a jpeg, mp3, or whatever,
    say, "Gee, this makes no sense...guess I'll go ahead and execute
    it."  Methinks I need to go read up on buffer overflow exploits,
    so it'll be less of a mystery to me.


    Wikipedia has a nice page on it http://en.wikipedia.org/wiki/Buffer_overflow .



  • @UncleMidriff said:

    This type of thing has always comfused me.  Why would an application, upon receiving screwy data from a jpeg, mp3, or whatever, say, "Gee, this makes no sense...guess I'll go ahead and execute it."  Methinks I need to go read up on buffer overflow exploits, so it'll be less of a mystery to me.

    A older version of Winamp also had a buffer overflow exploit for MP3 files, although it was patched quickly and I only saw example exploits for it.

    That wikipedia page linked above seemss a bit hard to understand for non-programmers, so I'll take a stab at it:

    The real problem is that most computers don't have any real inherent difference between data that is "data" and data that is "executable code". So if you can trick the thing into running your data, you can run any code you like on there.

    How you do that varies, but generally you need to understand how computer programs work. They're running code in order. After they run one bit of code, they go to the next address in memory, read the instruction there, and run that. It's just instructions running one after another. But computer programs are organized into "functions". That is, you have some set of code off in it's own memory space that does one sort of thing. To call it, your code tells the computer to jump to that function. After it's done, the function tells the computer to jump back.

    But how does the function know where to jump back to? It can be called from anywhere in the code. The answer is that the bit of code that calls it tells it where to go back to when it's done. This generally happens via something called a "stack".

    The stack is basically what it sounds like, it's a stack of stuff. You can put stuff on top and take stuff off the top. So, before we go to a function, we "push" the return address on the stack. Then we go to the function. At the end of function, the last thing it does is to pull the address back off the top of the stack and return.

    But the stack is used for lots of things. Very notably, it's used for local variables. The function puts his variables on top of the stack when he starts running, and changes them there as needed, When he's done, he pulls them back off the stack before pulling the return address.

    A buffer overflow is when you give data to the function in such a way that the function, by accident, tries to put more data into the local variables than is actually allowed. If we have a 10 character string and the function tries to put 11 characters in it, then it'll just go ahead and do it. Whatever was after that 10 character space in memory just gets overwritten. When you do this to a local variable, it's called "smashing the stack", because those local variables are on the stack, and you just overwrote something else on the stack.

    If I design my data carefully to exploit a bug in some function, I can overwrite the return address. So when the function ends, instead of jumping back to where it was supposed to go, now it goes to where I want it to go. Since I want it to run code of my choosing, what I do is to include my code in that data, then overwrite that return address to force the computer to run that data, when the buggy function ends. And there you go, I've run my code on your computer. And my code can do anything I want it to do.

    That's how a buffer overflow works. It exploits a piece of code's failure to check that it doesn't try to put too much data into too small of a piece of memory for it. Many programming languages don't have this sort of thing automatically, the programmer has write the code to do that check for themselves.

    Attempts to fix that have been made, and some of them are starting to be more successful than others. Lots of modern languages do these checks automatically, and simply will not allow you to accidently do this. Problem with this is that these languages are made by compilers, and compilers are programs which can have bugs in them too.

    Another attempt to fix the problem is one via hardware. CPU's have had an "executable" flag on memory addressing for decades, it's just never been used. Some newer systems are using it, and if the computer tries to execute a piece of memory that hasn't been explictly marked as executable, it causes a fault and stops the program from running. Problem there is that some programs that need to write self-modifying code have not had this bit set in the past (since up until now it didn't get used for anything anyway), and so those programs have to be patched. XP supports this now, as do the newer processors from Intel and AMD.

    There's operating system level functionality to prevent this sort of thing too. One neat trick used in some systems is to push a random number onto the stack after the return address, and then to check that the number has not changed before returning. Any attempt to overwrite the return address will overwrite the random number as well, and so the function will see that and stop before it runs any malicious code.

    Anyway, buffer overflows will eventually go away one way or another, but there's other ways to insert code via data, this is simply the easiest and most well understood.

    Join me next week, in my upcoming diatribe: "Exploiting the heap for fun and profit". [H]



  • @Otto said:

    The real problem is that most computers don't
    have any real inherent difference between data that is "data" and
    data that is "executable code".





    That's not a problem, that's a feature - at least it is considered THE
    fundamental change of paradigm that John von Neumann introduced with
    the architecture named after him - after which all of today's computers
    are patterned. If you cannot treat data as executable code, you cannot
    have an OS and programs on the HD along with data, or download programs
    over a network. Software would probably never have developed the power
    and complexity it has today if we hadn't moved away from the early
    architectures where THE program (the concept of an OS did not yet
    exist)  was maintained in a  fundamentally different part of
    the computer than the data it operated on.



    And any attempt to "fix" the problems arising from this by
    reintroducing such a separation can only be partially and temporarily
    successful, because you can only ever fix certain narrow technical
    classes of exploits, while new ones keep getting introduced. Make all
    buffer overflow exploits impossible and it still helps you not one iota
    against scripting vulnerabilities. And at a very basic level, any
    program that reads data and does different things depending on the data
    (which is just about any program in existence) is executing some sort
    of script.






  • That's not a problem, that's a feature - at least it is considered THE fundamental change of paradigm that John von Neumann introduced...

    Okay, you read a little too much into that...

    There's a difference between treating data as code and having code with the ability to modify itself. While you're correct about the impact of the von Neumann machine concept of treating data and code as different forms of the same thing, there is very little reason in modern computing for code to actually be self-modifying.

    Code very, very rarely has to actually write other code programmatically. And the ability to do it is still there, you simply have to tell the computer "yes, I'm writing self modifying code" by setting a flag somewhere. Having the ability to write new code to memory and then run it by accident is the cause of this sort of exploit. That ability simply should not be available by default. You should explictly ask for it.

     


Log in to reply