Even Flash Can Get Viruses 277
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."
Cross Platform? (Score:2, Interesting)
two classes of files: (Score:1, Interesting)
unsafe files: vbs, exe,
I cannot comprehend the shift towards risk (macros in
Scripting Security (Score:3, Interesting)
Re:McAfee (Score:2, Interesting)
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.
Java applet viruses? (Score:3, Interesting)
Re:Java applet viruses? (Score:4, Interesting)
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.)
It's easy to understand (Score:1, Interesting)
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.
Virus Names (Score:3, Interesting)
Third lesson we learned in CS100 in college :-) (Score:3, Interesting)
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.