Slashdot Mirror


Even Flash Can Get Viruses

Mechel Conrad writes: "Heise Online(German) writes about a Virus called SWF/LFM-926. It consists of a Macromedia Flash movie and seems to be the first of its kind. It uses Flash's scripting language in order to open a debug terminal creating and executing a file called V.COM, which infests other .SWF Files. Although the virus is not very dangerous and not widespread yet, it suggests clear security holes in Flash." The translation of the Heise article is quite readable, too. Update: 01/08 22:47 GMT by T : bdavenport adds: "this report on Yahoo lists a new Shockwave virus as low grade due to the need of manual downloading. infoworld is reporting that McAfee has upgraded to high risk after several Fortune 500 firms have reported it in the wild, arriving as an email attachment."

22 of 277 comments (clear)

  1. McAfee by hogsback · · Score: 5, Informative

    McAfee information is here

    Looks like it isn't very likely to succeed - it needs Windows NT and the stand alone version of the flash player.

    Just proof of concept really.

    1. Re:McAfee by PD · · Score: 3, Insightful

      On my systems, the damage would be limited to the account that I would accidentally run a virus in - my user account.

      Unfortunately, EVERYTHING that is important is under that account. Everything that's NOT under the account was installed from my Debian CD's.

      Limited damage means limited only to the most important files on my machine in this case.

  2. Build it, and they will... by Ethelred+Unraed · · Score: 5, Funny
    ...write a virus for it.

    Cheers,

    Ethelred

    --
    Everyone wants to be Ethelred. Even I want to be Ethelred.
  3. It may be readable but this is in english by BinaryAlchemy · · Score: 3, Informative

    The virus info from Sophos: http://www.sophos.com/virusinfo/analyses/swflfm926 .html

    --
    ----- The problem with browsing at +5 is that everyone thinks you're being redundant
  4. Re:Cross Platform? by hogsback · · Score: 3, Informative

    Not this one ... it uses cmd.exe (from Windows NT) to write a script for debug (the DOS/Windows so-called debugger). So it looks like it's NT/x86 specific.

  5. translation by twms2h · · Score: 3, Informative

    Just in case anybody reads the translation and wonders what the 'southwestern German broadcasting corporation' is about. It is just a mis-translation of SWF which used to be short for 'Suedwestfunk' (it doesn't exist any more, merged with another radio station). Of course in this case it just means the file extension of flash.

  6. Scripting Security by svwolfpack · · Score: 3, Interesting

    This pretty much shows that any type of program with a scripting language built in is prone to having viruses written for it. (word macros, VBS, etc...) It will be interesting to see what is done in the future to allow for the benefits of having scripting, but reducing the risks associated as well. A possible solution is simply reducing the power that scripting languages have, such as disabling file writing capabilities (although that's not really a legitimate solution, you see where i'm going with it...)

  7. Java applet viruses? by melquiades · · Score: 3, Interesting

    Has there ever been a Java applet virus? Java's very nice security / permissions model should theoretically make this impossible. However, considering that (1) that's only in theory, and (2) just about every browser implementation of Java is complete shit ... well, it could happen. Has it?

    1. Re:Java applet viruses? by C.+Mattix · · Score: 4, Interesting

      For Java to do anything bad it has to have explicit permission from the user. In that case, in my opinion, it isn't a virus, just a dangerous program and the user should acuatlly read the warning boxes.
      It could happen if some company would give away the private keys for a trusted company and then use that key to sign a modified and dangerous version. (Say like a rooted version of Yahoo chat or something like that, that has to be trusted to run right.)

  8. Many scanners don't scan .swf files by geirt · · Score: 5, Informative

    Many virus scanners don't scan .swf file by default, so you have update your virus signature file (which is automatic on most scanners) and reconfigure your scanner to scan .swf files (unless you already scan all files on your computer).

    This means that if advanced .swf viruses are created, they could become a real problem until system admins wakes up and gets a clue (and that takes a loooong time, look at Code Red)

    --

    RFC1925
  9. Finally! by kilrogg · · Score: 3, Funny

    Us Linux users can enjoy a flashy virus for once. We need more cross platform stuff like this.

  10. Re:two classes of files: by sqlrob · · Score: 3, Insightful

    Why are gif & jpg necessarily safe?

    If there's a buffer overflow in the program rendering it, it could very well be an infectious file.

  11. everything can get viruses by Twillerror · · Score: 4, Insightful

    Why is it that almost every system out there can get a virus? I'm under the opinion that it is the OS's fault, *nix, windows included.

    The reason anything can get a virus is because programs still have direct control over the IP ( instruction pointer ). This is a fatal flaw found in most OS's. Programs should be ran inside of a VM with tight security. Of course performance calls for some apps, especially servers to be ran in compiled code, but this should not be the default. If such an app needs to be installed or run the OS should prompt the user warning them of such activity.

    Another flaw is the fact that we are still using a basic file system. Whether it's fat32, ntfs, or ext2 it is still just placing a byte stream on a disk, managing the name, where it starts and where it ends. Lets evolve a little. The file system should be more like a database. It should be able attach any number of properties to a file. It should be able to manage security at any level, and it should be able to isolate files from process to process.

    Imagine if when a program installs it has access to it's portion of the file system and that is it. It couldn't see the rest if it wanted to. Installed programs could get quotas. They sure as hell wouldn't be able to start overwriting executables all over the place.

    You could argue that good user level security could solve these problems, but it's obviously not enough since so many viruses simply find away around it.

    I could go on and on about how OS's treat applications wrong. But the main point is that they treat them like friends when they are really strangers. The answer is to take control away from the app, and put it back in the OS. Perl and Java are a good start ( since they are both interrupted in a way), but obviously more work needs to be done.

    1. Re:everything can get viruses by Dirtside · · Score: 3, Informative

      The problem is, there's no way to algorithmically tell a virus from a badly written program, or a normal user command to overwrite a file or document data.

      Let's say we're using your theoretical virus-proof OS. Well, I still want to be able to open a shell window and run my programs that do things. Sometimes I'm going to want to delete files or overwrite older versions of files with newer ones.

      If the OS is designed to never let the user overwrite any data, that's not going to be a very useful OS! Basically, anything a user can do via stupidity (or obscure necessity) can be replicated with a virus. Remember, a virus is just a program that does nasty things instead of word processing -- there's no way for a nonsentient OS to tell, definitively, whether a program is supposed to be deleting files or not! Even if it prompts you for confirmation that you want to delete a given file, there's no way for the computer to be sure that it's really a sentient user hitting enter, and a virus simulating an "Enter" hit from the keyboard. (Well, there are specific ways around specific attacks, but I'm talking generally. OSes cannot pass the Turing test yet!)

      --
      "Destroy science and religion. Science would re-emerge exactly the same; but not religion." - Penn Jillette, paraphrased
  12. Infoworld is reporting on a *different virus* by philam3nt · · Score: 5, Informative

    It appears that the articles have not been read carefully. After comparing the the three, there are two Flash virii being spread around.

    Virus 1 (Conrad's submission) - SWF/LFM.926
    The virus, dubbed SWF/LFM.926...must be downloaded manually and cannot spread...over e-mail. (Yahoo)
    ...and after being run, infects other Flash movies while displaying the message "Loading Flash-Movie...". The virus exploits the scriptability of Macromedia Flash to generate a file V.COM, which gets executed afterwards without confirmation. (German trans. - thanks entrox!!)

    Virus 2 (bdavenport's infoworld submission) - Creative.exe
    The virus...arrives in an e-mail bearing the subject line, "A great shockwave flash movie."
    The worm, which first appeared Thursday, is delivered to users in the form of an e-mail attachment that appears to be a Shockwave Media Player. When a user tries to view the movie attachment, the worm sends a copy of itself to all people in the address book of the user's Microsoft Outlook e-mail program, potentially clogging e-mail networks.
    One reason the Creative.exe virus may be spreading so quickly is that it uses the Shockwave Flash movie icon.
    (Infoworld)
    ...but if you check the date of the Infoworld article, it's December 1, 2000.

    From Symantec:

    Discovered on: November 30, 2000
    Due to a recent decrease in world-wide infections of this worm, SARC has decreased the threat level of this worm to 3 and removed it from the Top Threats list.

    W32.Prolin.Worm uses Microsoft Outlook to email a copy of itself to everyone in the Outlook address book. The worm moves all .mp3, .jpg, and .zip files to the root folder. It renames each of these files and appends the following text to the extension of each file:

    change atleast now to LINUX

    Also Known As: TROJ_SHOCKWAVE.A, CREATIVE, TROJ_PROLIN.A


    So...Creative.exe is NOT a flash virus, and is old news, unrelated to SWF/LFM-926.

    --

    If I had a sig, this is where it would be.
  13. Re:two classes of files: by Rentar · · Score: 3, Informative

    The difference is that those are static formats that don't run any code (at least if you believe in the difference between code and date).

    Additionally there are quite some different gif and jpg parsers out there, but the number of usefull Flash-Players is rather limited (1 comes to my mind). So if you'd be able to make a gif file that runs arbitary code on the machine that views it, it would most probably be targeted only on this gif-reader software (and this version, and this platform, and ...).

    And I think the checks form alformed GIF and JPEGs are rather strict in most image-loading libraries, 'cause defect GIFs and JPEGs are known to exist.

  14. That vulnerability is purely theoretical... by chazR · · Score: 5, Funny

    The still-excellent l0pht once informed the world that Microsoft had a serious security problem in a product.MS responded with the famous "That vulnerability is purely theoretical.". So, l0pht released a real exploit for the vulnerability.

    Apologies, it's hard to find the original links since l0pht got up in the morning, put on a suit, and became @stake

    Hello. Wake up. Theoretical vulnerabilites become real, nasty, exploited vulnerabilites very fast. I assume you read comp.risks?

    Looks like it isn't very likely to succeed

    LOOKS LIKE? It's a done deal. Somebody has exploited a widely-distribited scripting engine. The people who did it as a "proof-of-concept" have proven that the interpreter for this language is wide-open and gagging for a jolly good rogering. I wonder how many unchecked buffers there are in that code. I wonder how it handles multi-byte characters. I desperately hope it wasn't written in C.

    I sit here as a smug old Unix hacker, secure in the knowledge that lisp and Smalltalk programs are unlikely to be attacked in the same way that C programs are.

    I'm also sure I'm wrong.

  15. Virus Names by CAIMLAS · · Score: 3, Interesting

    Who's the goon that actually names these viruses? Is there some organization that categorizes and files them, or is it done by the antivirus companies (Symantec, McAfee, etc) that find them? I've never quite understood the odd names that are ascribed to them.

    --
    ~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
  16. This can't happen via HTTP by Segfault+11 · · Score: 3, Informative
    I work in Flash, and I can explain exactly what this is.

    Formats like Flash, Director, or Toolbook are fairly safe when run in a browser, but when run locally, most gain much more functionality, including the ability to execute arbitrary commands. Many people have the Flash Player plugin, but no standalone executable to open the files locallly is supplied. 99% of all people that do have the standalone player are getting it from an installation of Macromedia Flash (the creation/editing application), and anyone else with a player isn't likely to have one that implements FSCommand calls, of which one of the functions is the ability to execute commands.

    --

    I registered my hate for Jon Katz

  17. Not a real WEB virus. by VAYKENT · · Score: 3, Informative

    Flash can only execute system commands in the stand-alone executable. Anybody can make an EXE that does worse... and if you're stupid enough to run an unknown EXE, then you don't deserve the computer that died because of it ('Virus' exe). The FSCommand in Flash (useable in the embedded SWF version we all see on web pages) can 'save' files - but they are only plain text files, and you can only save the name/value pairs that exist on the root imeline of the SWF (can anybody say - 'cookies' ???). Don't think that Macromedia was stupid enough to allow a virus like this. (Again - unless you're stupid enough to run an unknown exe!). What's wrong with the media today that they have to run bogus stories like this?? Did they even bother asking Macromedia if it was technically possible?? Bunch of morons. "Today on Virus Alert we've found out that a new Windows CE virus will make your PDA strangle you in your sleep..." Uhh... Ok.

  18. No vulnerability in Flash itself by silhouette · · Score: 5, Informative

    The reason the stand-alone Flash virus file is able to access CMD.EXE has nothing to do with any inherent security hole in the basic Flash player itself. The stand-alone file uses a fairly well known (in the Flash community) function that is only available in the stand-alone Flash player. In fact, Macromedia even has this function documented in their Flash support section. It's the "exec" command that takes an argument of the path to an application to execute.

    This virus really has more to do with running an unknown executable than it does exploiting some kind of vulnerability in Flash. This is because any stand-alone Flash player file is an .exe, not a .swf. The stand-alone .exe is composed of 1) The .swf file that runs and 2) The entire Flash player itself (~2megs) in executable form. By including the entire player within the file, the bundled .swf can be run anywhere without any necessary previous installation.

    What cracks me up personally is that the very possibility of a Flash virus has been discussed before on Flash community developer message boards. When the "exec" command for the stand-alone player was still undocumented and somebody posted about it (having "discovered" it somehow) there was quite a discussion about the new functionality uses. But, there was also some speculation on how it could be used for malicious purposes. This was around a year ago, IIRC.

    --
    Experts agree: everything is fine.
  19. Third lesson we learned in CS100 in college :-) by billstewart · · Score: 3, Interesting
    The first two lessons we learned were "here's what to do with a keypunch" and "if you don't comment your code we'll give you a bad mark even if it appears to work fine", but the first *real* lesson we learned was "Your program can *never* *ever* trust its input."

    And to make sure we got the point, they'd make us run our programs on their input decks, which often had maliciously designed explorations of the limits of programs - what if the input field is missing, or too short, or too short by 1, or precisely as long as the maximum, or maximum+1, or way too long, or not a number, or a negative number, or had spaces in it, or had magic-looking values like 999 or 32767, or duplicated things that were supposed to be unique, or used values that weren't on the list of the-only-values-the-user-can-input. This was on Evil Mainframes with EBCDIC, so there are some modern forms of Bad Input that didn't exist (like backspaces or carriage returns in alphabetic fields ) but there were other evil things that could be done, like bogus punchcards, or characters that weren't from the 48-character character set the old printer supported or the 64-character set that the new one supported, or had data that ran into columns 73-80 which are only for sequence numbers. One of many annoying things about punchcard-oriented systems was that the edit-compile-run cycle was very slow, but it forced you to think very carefully about what you were doing. On the other hand, there are kinds of Bad Input that come from lots of experiments of throwing Nasty Looking Stuff into a program to see what it does that you wouldn't bother with on a punchcard system.

    --

    Bill Stewart
    New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks