Re rant about virii on VMS...

[Glenn and Mary Everhart <Everhart () gce com>]

> > Antivirus scanners typically work by matching against patterns of known
> > viruses.  For VMS that is the null set.
>
> Hope you don't mind me saying this, but that's essentially a null argument.
>
> All software sucks, that's a given.  All software has bugs, all software has
> security flaws, often the biggest of which is that all software is (at some
> point) used, configured and controlled by humans.
>
> If VMS has no known viruses, it's because of a combination of factors:
> 1. About ten people in the world use VMS.
> 2. A story about a virus infecting VMS is unlikely to make the evening news.
>
> If every Windows user switched to some other OS tomorrow, within a few days
> that system would be under attack from a whole host of new viruses.
>
> Unless you're going to point to specific _technical_ features of VMS (and
> I'm glad that you have) that prevent the spread of viruses, the argument
> that the system currently has no viruses is nothing better than a security
> by obscurity argument.  There are no viruses because there is no perceived
> benefit to the virus author.  Remember, the virus author can only have a few
> reasons for writing a virus:
> 1. To get some form of notoriety (even if it has to be anonymous notoriety,
> where it's only the author that gets to say "hey, I wrote that", and he only
> says it to himself).
> 2. As a destruction of existing systems - kind of a techno-Luddite, or one
> who hates an OS or app sufficiently much to want to harm everyone that uses
> it.
> 3. As a means of creating a vector for future attacks - this is happening
> more frequently.
>
> Note that only item 2 would allow for a cracker to consider writing a virus
> for a marginally popular OS.

Might help if you got some info before ranting so.

VMS implements 4 levels of privilege state protection. A minimum of
3 is needed for correct protection. (BTW VMS has the patent...).
VMS uses descriptors for most all string operations. That means
that the address and size of the available memory, and some type
info, get carried along so everything can check. In almost all cases
it does. (Once in a while something slips by and gets fixed.)
The culture of VMS engineering is security and customer data paranoid;
they have a word for issues that can jeapordize either: showstopper.

Manage to get a CLI (equivalent to shell) in VMS and you just drop
out of the priv'd context and get back to something relatively safe.

Totally different animal from unix; people have been working on securing
it for its entire history (it is almost as old as unix...difference of
maybe 3 years).

There is quite a lot more, but this argument that VMS is secure because
it has not been attacked is bull (and false besides: it got attacked
routinely some years ago, and many parts were redesigned to ensure those
attacks could not occur. The source code was totally available to people
who had VMS early on, and is available as listings on CDs for a not too
hideous fee now. The guts of the system were and are not obscure to anyone
who was interested enough, and many have been.

And NOT all software "sucks", or has bugs. Carefully built software will
do what it is supposed to.

The lack of virii does not indicate it is impossible to write them; there
have been 3 or 4 laboratory examples (and there were some real worms
very very early on reflecting the fact that until V6.0, VMS was not secure
out of the box but had to be tweaked. Most didn't tweak it. Nowadays, it
comes up secure, and if you want security holes you are given the drill
to drill them and instructions on what you're doing. Even then they tend to
be tiny. Remember the VMS system at DEFCON a couple years ago...got thru
the whole show with nary a breakin due to technical features. (I think one
guy did social engineer a password but didn't get to do much with it.)

The kinds of bugs you find in VMS (maybe once a year outside of VMS
engineering; rather more are found inside, but those builds never get
out the doors) tend to be in drivers that talk to hardware that only one
guy really knows. That makes the concept, design, and code reviews less
effective, because nobody else can really vet what is happening to the iron
and one person can sometimes make mistakes. (I've known only one guy who
essentially never did, but he left the field and became an MD.)

The same kinds of arguments will apply for a few other OSs around like z/OS,
os/400, and some less well known...systems written in cultures that care
about security and correctness. Before ranting about them, learn some details
about real, non-toy OSs and quit assuming that all OSs are like your toys...