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."

9 of 277 comments (clear)

  1. Cross Platform? by Mr.+Sketch · · Score: 2, Interesting

    Could this be one of the first true cross platform viruses?

  2. two classes of files: by Anonymous Coward · · Score: 1, Interesting

    safe files: gif, jpg, txt, ...
    unsafe files: vbs, exe, ...

    I cannot comprehend the shift towards risk (macros in .doc, scripting in .swf). Programmers, please keep the documents straightforward and powerless. I guess no one cares.

  3. 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...)

  4. Re:McAfee by hogsback · · Score: 2, Interesting

    By NT I meant NT/2K/XP - they're all the same really!

    It's probably a minor change for Win9x/WinMe.

    I don't know anything about the Flash scripting language - but it is using OS tools to do the actual infection of other files...this makes it less likely to be very cross-platform.

  5. 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.)

  6. It's easy to understand by Anonymous Coward · · Score: 1, Interesting

    Don't download and run files. If somebody gives you executable code, then consider whether you trust them.

    Flash in a browser is safe. It's an entirely separate issue.

    Just read the story, and think about what they're really trying to say.

  7. 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
  8. 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