A 100 lines Visual Basic for Applications program that shuts down mail servers worldwide. A 200 lines Visual Basic Script program disrupting workflow at roughly 60% of the world's companies ?

That's a lever effect that would have astounded Aristotle himself.

In both cases, we "fortunately" have or will have culprits which we can blame, punish and despise. This is a moral story after all. Or is it ? Think again.

If there is something to learn from this mess, it is that the system as it exists today is incredibly fragile.

Scripts and embedded languages can do anything.

There will always be someone who thinks feature number 49578 is the greatest thing since sliced bread. There will always be someone to point out Windows Scripting Host is not to blame since the same program could have been written in Perl or C++. Sure, I guess it could. But look at this

set out=WScript.CreateObject("Outlook.Application")
set mapi=out.GetNameSpace("MAPI")

How do you program that in C++. Possible, yes, but fiendishly hard : programmers who could do it aren't script kiddies or bored students, they are talented and have a job. If scripts are as powerful, or more powerful, than conventional EXEs, they should be treated with the same restrictions, or even hasher ones.

Scripts and embedded languages can do anything, simultaneously..

Even if we needed all the features that scripting offers, couldn't we agree at least that the complete features set should not be fully available all the time ? Why would a script be allowed to launch executables, write files and access the network at the time you are accessing your on-line broker ? Script languages should be restricted. This is not a new notion, this is the called the Sandbox Security Model.

Scripts and embedded languages can BE anything.

Then what if we need all features anyway ? The solution already exists : certification and signing. Somehow, the notion that we need certification was obvious when we were considering executable : but it has progressively faded with the vague notion that scripts are less powerful and or dangerous than executables. Yet we do know that, in practice, scripts and embedded languages can do more than classical development tools by using high level building blocks. Scripts must be treated as executables and be certified and signed.

What about user education ?

Then there is the user : on average, an uneducated and stubborn animal. Yet, it has been argued that educating him could help. Yes, it could. But just as driving a car doesn't require a full understanding of the ABS electronics, using computers should be transparent and as safe as can be. In practice, what we are doing now is just the opposite : we are intentionally misleading the user for the sake of integration, we are hiding file extensions to make his life easier, we are diminishing his perception of the mechanisms involved. But just as a stop signal is universally understood, couldn't we devise some unequivocal visual feedback that flags ALL foreign executable code of ALL kind clearly ?

Is anti-virus software the answer ?

Partly. Quick reactions by the developers of signature based scanners limit the damage, but this approach does not prevent initial flares. Heuristics are just set of rules and, if a new virus breaks or go around them it will go undetected. "Generic" approaches completely miss their target when confronted with a new type of target. By its nature, anti-virus software can at best react to a threat, not prevent it. Sometimes it will get lucky by using clever heuristics or behavior blocking and other so called "generic" methods. These successes will be largely advertised by their developers. But we should not forget this simple fact : virus and worm writers have months and weeks to test their creatures against the most widely used products, while anti-virus writers are expected to react within a couple of hours... forever if the base model does not change. It is obvious that the fight is unfair. We cannot keep on relying on luck.

The dangers are many

The obvious ones : what if the Love Letter worm had targeted XLS and DOC files rather than images and MP3 ? 30 to 60% of the world's companies would have lost at least some of their documents. In the most optimistic scenario, they would have lost valuable time restoring those documents from perfect backups - we know how far this idyllic picture is if from the real world, don't we ? Immediate damage is one risk, but there is more. What if Love Letter's author had had more resources and a real intention to harm ? Such as a few hundred download sites to balance the download of his Trojans... What if his Trojan had been more complex, gathering sensitive information, encrypting it with some public key and posting it to Usenet, or some other distributed storage, to allow anonymous recovery by the owner of the private key. What and when would the real damage surface ? Who knows which other ways to hurt are currently devised ? If we fail to address the real issues today the obvious productivity gains the net has brought us are truly in danger.

Finally if nothing fundamental is done to prevent the occurrence of such large scale incidents, it is ultimately our freedom that will be at risk, as government will be more and more tempted to regulate harshly, eavesdrop blindly, ban and punish at random. Let's prevent that from happening.