Human Vectored Scripting Worm

The IloveYouVirus worm works by tempting a human to double-click its icon. Then, in this user's security space, it plays with a combination of shell-level settings that, individually, are MostlyHarmless.

(In DialecticMode...)

Alice: Isn't this a stupid security hole? Surely a script shouldn't be able to override the restrictions applied to it by the environment in which its running?!?!?!

Bob: No. WScript is not intended to be a secure environment. So saying this is like saying "surely an executable shouldn't be able to...".

Alice: It does make sense to restrict the security privileges an executable has. Otherwise, you would have something akin to MS-DOS where the common behavior was to replace the operating system, overwrite other people's files, overwrite other applications' memory spaces and trash the hard drive. Consider also the JavaSecurityManager.

Bob: But the so-called "hole" is not that type of security breach. The security hole here is the people opening attachments, plain and simple.

Alice: Not true. The hole is that Outlook continues to permit unauthorized scripts/executables to access its address book and send mail. This opens the door to a worm. Which is the exact problem with IloveYou. All network access must be controlled, as well as disk activity, etc. Once again, the JavaSecurityManager comes to mind. Taken another way, all foreign applications should be treated as quarantined until validated by authorized personnel. At which point, it should only be raised to the security level of that personnel.

Bob: The security hole was giving hundreds of thousands of technology workers just enough training to click on things, but not enough to learn to recognize recently introduced executable file extensions. Everyone knows HAPPY.EXE is a virus by its extension, but VBS is not so familiar.

Alice: But the extension was ".TXT.vbs". Our IT guy read ".TXT file, OK" and clicked it. Anyway...if it doesn't pop up a big ugly box saying "Warning: You are about to do something immensely stupid", it's a bad UI IMHO. ''So that huge box that pops up asking if you'd like to save the file to disk or run it isn't enough?

I haven't seen it, but it may actually appear to be worth opening. For every dufus that opened an email from an unknown person, there were three or four people who opened an email from said dufus ( well known to them ). Then there were those who opened an email for someone who opened an email from a dufus. Etc. Given that EachPersonIsOnlySixAwayFromEveryOtherPerson?, the virus can quickly spread world wide based on only a handful of dufi.

I guess the solution is don't read your mail. Very sound advice in my opinion. -- ThaddeusOlczyk

Just think of it as EvolutionInAction.

Moved from ScriptingVirusProblem

MelissaVirus?, IloveYouVirus...

Less of a technical problem and more of a social one, these viruses rely on computer users to not understand what is going on in order to be spread. They prey on MicrosoftOutlook primarily because of its ubiquity, but also because it is scriptable in every way, shape, and form (by design, of course).

Seen as someone's signature on /.:

The guy responsible for the IloveYouVirus... they're probably going to split his company in two. (Wikization of virus name done by the editor.)

In some systems (including those using the CapabilitySecurityModel) this kind of virus would be impossible (unless the authors of the Email client would intentionally make a security hole -- and even then it would be limited to the privileges given to the Email client). You could just not give the various scripts the capability for Internet access, or better, give the user a warning message the first time the scripts tries to send anything, and monitor its behavior afterwards.

The security hole here is the people opening attachments, plain and simple.

In my opinion, when a person double-clicks on anything, the default should be to view that thing.

Why do so many people confuse viewing something with executing something? (For example, viewing .jpeg with some image viewer, viewing .html with a Web browser, viewing .txt with a text editor, viewing .ps with a PostScript viewer, "viewing" .mp3 with a audio player, etc.)

Are you writing an email application or some other applications where the user can double-click on arbitrary things? Please make it view those things, using the appropriate application that's already installed on the computer. If the thing I double-click on is an application, then the appropriate application is the "properties viewer" (which tells me the file version, the name of the company that made it, whether that application was digitally signed, ... etc.). The lowest-common-denominator -- if the machine can't tell which application is "appropriate" -- is a hex editor.

If the email application (or file viewer or whatever) is about to install some new application, or execute some new application ... then say that. Don't say you're "viewing" something when you're really executing something. Don't say you're executing something when you're really viewing it.

Using "open" (or a double-click) to mean execute sometimes, and view other times, without any way for me to tell the difference, really irks me.

-- DavidCary

I sympathize, and have been irked by this at times, but it's hard to pick a line of distinction to draw. Viewing and opening both ultimately mean "run an executable on this data"; in a computer environment, nothing is literally directly viewable without software mediation, of course.

I suppose one could make a hard-and-fast rule that "view" means "open read-only", whereas unqualified "open" means "open read-write-execute".

-- anon

There was a time when anybody with a little know-how could buy some parts and put together a transmitter. The governments of the world, recognizing that this would soon lead to chaos, started licensing both transmitters and the people who operate them. I wonder, could we see a day when one would have to be licensed to write code or run a server? Unenforceable? What if every silicon foundary were compelled to cooperate in the enforcement?

Do you mean "foundry", Ward?

A nitpick: there is no such thing as "viewing a file without executing it". All formatted data is a program of sorts. One can think of it as a continuum, starting with that simple bitmap file, moving through pngs and jpegs, then PDF, and ending up at postscript, which someone has written a webserver in. There was an evil gif file floating around a few years back, which would crash almost any viewer at the time. Somewhere in it's "pixel-painting routines", that gif had a "bug", which would cause the "interpreter" to crash.

As for "view" meaning "open-read-only"... So, it reads the file. Then what? Will it paint it to the screen?

-- MarkHubbart?

There's no standard or precise definition because it's just a matter of what a particular operating system allows. Where the file's content has direct use of the machine's hardware or operating system, that file is deemed to be being executed. Indirect execution, via some program, other than the operating system, which has read the file (especially when the file is opened in a "read only" mode), is somewhat arbitrarily termed "viewing", even when such viewing might not be any more secure. The term "viewing" may be extended to certain similar use of a file by the operating system itself.

Proposal:

'View' implies a read only access. Not of the viewing program, but of the capabilities available to the file.

'Executing' is everything else.

Next, we define that those terms apply in a specific 'context', and therefore making it possible to 'view' a binary executable by 'executing' it in a sandbox.

Of course, none of these terms or definitions are particularily novel, but :p.

It's interesting to note that some forms of data can be viewed with much more ease than others. A gif is nearly trivial, as it only needs access to bitmap to draw to. A copy of Microsoft office is a bit more complicated, but there's no theoretical reason why it's any different. It can get it's job done completely internally, and when you want to save the output, you simply do the copying yourself. As a side effect, this mandates the use of extension instead of embedding, as an app no longer has the privilege to attempt to emded (for example) a self-contained file system. No matter what they did, the final move from app-level sandboxed file system to trustable file-system would have to be performed by an agent of that trustable system (user or whatever).

<OperatingSystemsDesignPrinciples>I see no reason why this layering shouldn't be generalizable.</>

--WilliamUnderwood

It appears you've been brainwashed into believing that "viewing" an executable is the same thing as "executing" it.

There is so such thing as "viewing a file without executing it".

The line of distinction seems very clear to me.

My email program knows about my "favorite" viewers. Today, I want it to run Mozilla when I double-click on a ".html" file. Tomorrow, I may want Opera or Lynx or a text editor. Today, I want it to run a "properties viewer" program when I double-click on a ".exe" file. Tomorrow, I may a resource viewer or hex editor.

Viewing a ".exe" with a hex editor (or with a properties viewer) is not the same as running that file.

The email program should neither know nor care if an attachment is "executable" or not. It should always treat attachments as data. The only programs it should ever execute are the "viewers" on my list of "favorite" viewers.

-- DavidCary

I guess the solution is don't read your mail.

Ah, I see you've read EmailIsDangerous and ThrowawayEmailAndRidYourselfOfSpam.