Re: The Register: OpenVMS among most-secure of operating systems

From: Keith Parris (keithparris_NOSPAM_at_yahoo.com)
Date: 01/09/04 

Date: 8 Jan 2004 17:21:51 -0800

Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> wrote in message news:<btk2br$a43$1@new-usenet.uk.sun.com>...
> Unfortunately its a pointless piece of research because OpenVMS
> security advisories do not get reliably reported to CERT, Bugtraq
> etc so counting the ones that do only catches the excpetions to
> the rule.

You're trying to convince us that because you claim CERT, etc. report
counts are not accurate, therefore the actual (unknown to you) number
of VMS security problems discovered must be large (or, for your
purposes, at least larger than the reported number for Solaris).

In the general computing world, there are some basic assumptions that
just don't apply to VMS (and I'll show you why):
1) A security bug won't be fixed (or at least not fixed in a timely
fashion) unless the vendor is publicly shamed or threatened by a
public report. Vendors can't be trusted to act in users' best
interests with regard to security.
2) Most security bugs are found by users or hackers
3) Operating systems are inherently insecure; the only way to secure
them is to apply patches as problems are found
4) Security through obscurity is worthless

I'll address each of these:
1) OpenVMS Engineering has been very quick and spared no expense to
develop and distribute security patches quickly whenever security bugs
have been found. Although it didn't happen very often, I've
experienced receiving a shipment unbidden with a security update that
I was advised to install immediately. I can't recall anyone reporting
a case where a security bug was reported and the vendor of VMS was
unresponsive or even slow in responding. It's always been apparent to
customers that with VMS, the vendor always acted quickly and
responsibly with respect to any and all security issues.
2) Although some VMS security vulnerabilities have been discovered and
reported by users, most are discovered by internal testing, internal
code reviews, access to VMS source listings by white-hat experts, etc.
 Even Kevin Mitnick publicly admitted the only way he got access to
VMS systems was by getting a password using social engineering.
3) It is impossible to patch security into an operating system -- it
must be designed to be secure from the start, and no feature which
introduces a vulnerability can be added. This is the way VMS was
designed from the beginning, and the way it was continued. I remember
when it was realized that although DEC's own terminals didn't have
this feature, hackers could use the feature of an answerback string on
a 3rd-party terminal to submit a harmful DCL command to VMS, and DEC
immediately modified all utilities in VMS so they could not generate
the requisite escape sequence. By making it impossible to do something
harmful, hackers are stymied. And by putting architectural defenses
into place, mistakes tend to get caught. For example, having 4 rings
of protection instead of just 2 allows VMS to catch some errors that
can slip through with only Kernel and User protection modes.
4) There are significant real-world practical advantages to not having
details of all security vulnerabilities published, and in not having
source-code freely available. Without the need to goad the vendor into
taking action, there is little benefit for publishing details of a
vulnerability. Publishing details of a vulnerability that is
discovered internally or by white-hat experts and thus unknown to
hackers would be foolish, and would put customers at significant
additional risk. And when source code is not readily available to
everyone, black hats find it much more difficult and time-consuming to
determine how a system works internally and the best avenues to attack
a system. With so much information available and with so many
vulnerabilities in Windows and Linux and UNIX systems, where are the
hackers going to spend their time? Not on VMS. If you look on the
Web for information on how to hack VMS, you'll come up very short.

I know of OpenVMS systems set up out-of-the-box and connected directly
to the Internet without a firewall, and yet remain unhacked. Why is
that, one might ask?

Real-world experience and practice don't bear out your claim of
numerous vulnerabilities in OpenVMS.

Relevant Pages

  • Re: DEFCON 16 and Hacking OpenVMS
    ... credible because you spoke "chinese" with terms that are foreign to VMS.. ... it is a common used description in SECURITY ... vulnerabilities and write PoC code to proof that the vulnerabilities ... we can't fix bugs that are found ...
    (comp.os.vms)
  • Re: DEFCON 16 and Hacking OpenVMS
    ... credible because you spoke "chinese" with terms that are foreign to VMS. ... it is a common used description in SECURITY ... you are correct that we don't know about all the terminology used by ... vulnerabilities and write PoC code to proof that the vulnerabilities ...
    (comp.os.vms)
  • Re: DEFCON 16 and Hacking OpenVMS
    ... we came to an VMS group that already discussed the vulnerabilities ... credible because you spoke "chinese" with terms that are foreign to VMS. ... it is a common used description in SECURITY ... you are correct that we don't know about all the terminology used by ...
    (comp.os.vms)
  • Re: LanSuite 2003 - Multiple Vulnerabilities
    ... I have found all the vulnerabilities you found plus, ... Of 21 security flaws I found in there product only ... the problems you reported applied in LanSuite ... > this vulnerability report regarding LanSuite software. ...
    (Bugtraq)
  • Re: OpenVMS security?
    ... OpenVMS is mostly written in a variety of type-safe languages, ... He is a security expert - ... The VMS kernel is mostly a DEC language claled BLISS and VAX Assembler. ... Getting privileges you don't have is ...
    (comp.os.vms)