Maximum Security:
A Hacker's Guide to Protecting Your Internet Site and Network
  
19
VAX/VMS
In this chapter we are going to take a stroll down memory lane. In order to make
the trip pleasurable for all readers, I thought I would make this a truly historical
treatment. Therefore, we will start with the rise of Digital Equipment Corporation
(DEC), the company that manufactured the once-popular product the VAX.
In one way or another, DEC has always been there at critical moments in computer
history. (You may recall that Ken Thompson was first hacking UNIX on a DEC PDP-10.)
Cross Reference: To appreciate just how
long DEC has been delivering computer products to the industry, take a moment to
catch this link: http://www.cs.orst.edu/~crowl/history/.
This link will take you to Lawrence Crowl's wonderful computer history page, which
shows photographs of machines that mark milestones in our computer culture (starting
with the very first computer ever constructed by Charles Babbage, circa 1823). The
first DEC PDP-1 appears on that page.
Cross Reference: To get a full-screen
view of that machine, catch this link: http://www.cs.orst.edu/~crowl/history/dec_pdp1_2.full.jpg.
The machine looked, quite frankly, like a prop in some terrible B movie from the
1950s--something you would expect to see in the laboratory of a mad scientist. Incredibly,
there was a time when such "technology" was the state of the art. Well,
DEC moved on pretty quickly, to produce a wide range of products, including the very
first minicomputer, the DEC PDP-8.
Cross Reference: You can see this machine
on Crowl's page as well, located full size at http://www.cs.orst.edu/~crowl/history/dec_pdp8.full.jpg.
In 1978, DEC created the first VAX (virtual address extension), the Digital VAX
11/780. This machine offered 32-bit architecture and 1MIPS performance. By standards
of the day, the 11/780 was powerful and fast. (It was also backward compatible with
the PDP line that preceded it.) The pricetag? A mere $200,000.
NOTE: MIPS refers to million instructions
per second.
Curiously, the 11/780 became so popular that it would establish itself as the
benchmark for the MIPS index. In other words, it became the yardstick by which to
measure performance of all workstations that later followed. (This occurred despite
the fact that the IBM 370/158 was reportedly comparable in terms of speed and processing
power. For reasons unknown to me, the IBM 370/158 never reached the popularity status
of the 11/870.)
So, to reiterate, the 11/870 was a $200,000 machine that could do roughly 1 million
instructions per second. Fantastic. Today, if you were to advertise this machine
for sale on the Internet, you would have to pay the buyer to haul it away. It is
considered by today's standards either junk or, perhaps more charitably, a collector's
item. However, one thing made the 11/870 a special innovation and still singles it
out from other machines in computer history: The 11/870 could support two operating
systems. One was a system--UNIX--that was known reasonably well at the time. The
other system was something a little different. It was called VMS. We will be examining
VMS in just a moment. First, however, I want to give you an idea of what the VAX
was all about.
The VAX was a multiuser system. Many readers may not be old enough to remember
the VAXstations, so I'll offer a little description. The MicroVAX stands nearly 3
feet tall. On the right side of the machine is a panel that, when opened, reveals
the cards. These cards are quite large, although not nearly as large as the panels
of, say, a SPARCstation 4/330 VME deskside computer. (But certainly larger than most
modern motherboards for personal computers.)
The Terminal is a VT220, with a viewing screen of approximately 81/2
inches. At the back of the terminal are various connectors. These include a data
lead connection, a printer connection, and a serial port. The serial port could be
set to an amazing 19200 baud and terminal emulations available included VT220 and
VT100. If you connect a modem to the terminal, you have to set modem commands by
hand. (In other words, you would have to send raw modem commands from a blank screen
that sports a blinking cursor. Typically, you would dial by issuing the command ATDT5551212,
for example.)
Contained within the terminal is firmware. This is software hard-coded into the
board itself. (PC users should think of firmware in exactly the same way as the CMOS.
It is a small software module that performs a limited number of tasks, including
setting the machine's parameters.) Unfortunately, there is no facility by which to
capture a figure of the screen, so I must describe it. When the terminal boots, you
are presented with a copyright screen and then a blank screen with a blinking cursor.
The terminal is then ready to accept commands. To manipulate the settings in the
firmware, you choose the F3 (function 3, or Setup) key. This brings up a menu at
the bottom of the screen, where you can review and change various settings. These
include not only the way that communications are conducted, but also how the screen
is laid out and behaves. For example, you have a choice of either an amber background
and black foreground or the reverse. You can specify a typewriter keyboard or Data
mode, which is more commonly used when interfacing directly with the VAX. You can
also manipulate the number of characters per line and lines per screen. (Additionally,
the firmware has short help messages embedded within it. These generally appear at
the bottom of the screen, in the status area, as do the setting values for each facet
of your environment. These may indicate which printer you are using, whether you
want local echo, whether you want type-ahead mode, and so forth.) No mouse, hard
disk drive, floppy drive, or other components are either present or required.
You have a wide range of choices regarding communication. For example, you can
change the bits (typically 7 or 8) and also the parity of these (none, odd, even).
This makes the VT220 terminal valuable not only to interface with VAXen (slang for
VAX machines), but also a wide variety of UNIX machines. For example, you can use
a VT220 terminal as a "head" for a workstation that otherwise has no monitor.
This can generally be done by plugging the terminal into the first serial port of
the workstation. (For most versions of UNIX, you generally need to strip the eighth
bit.)
TIP: For Linux hackers: You can also "add"
an Internet node to your box using such a terminal. To do so, you plug the terminal
into either COM1 or COM2. You then edit inittab to respawn another instance
of getty on that port. For this to work, you need to ensure that the cable
used is a null modem cable. You also should set the emulation to VT100. When the
Linux box reboots, a login prompt will appear on the VT220. From there, log in as
any valid user, and you are ready. This is significantly valuable, especially if
you are trying to train someone in programming or navigation of the Net via a CLI
(command-line interface). It is important to note that if you are using the same
COM port that normally supports your mouse, you need to kill gpm (general
purpose mouse support).
These terminals, while intended for use with the VAX, can also be used as the
most inexpensive method ever of accessing the Internet. Naturally, you need an old-style
dial-up connection to do so (perhaps via Delphi), but there is no comparison in the
price. Such terminals can now be purchased for $20. Add to this the price of a 19200
baud modem, and you are done. They are also great for connecting to local BBSs.
TIP: An interesting point here: Such a
terminal does not have environment variables per se and therefore reports none. All
the environment variables are obtained from whatever shell you happen to acquire
on the remote machine.
These terminals are used to connect to the VAX. (Note, too, that I have described
only very early implementations of VT terminals. Much later models supported various
types of colors and graphics not available to the early VT100 and VT220 terminals.
These newer models are extremely functional but can run as high as several hundred
dollars. Good examples are the VT330 and VT340.)
Finally, you can connect to a VAX without such a terminal. Typically, this is
done using PC software that supports VT100 terminal emulation. (Kermit is another
popular and compatible emulation.)
VMS
The VMS (Virtual Memory System) operating system is unique, but bears similarities
to several others. Logging in works much as it does on a UNIX system. You are presented
with a login prompt (Username:) and a password prompt. If you enter the
correct information, you are dropped to a prompt represented by a dollar ($)
sign. You are also given a series of values when you log in, including your username,
your process ID, and so forth.
Some common VMS commands are listed in Table 19.1.
Table 19.1. Common VMS commands.
| Command |
Purpose |
| HELP [args] |
If issued alone (without arguments), this command will bring up the prompt Topic?.
The HELP command is generally followed by whatever command you want to learn
about. |
| COPY [arg1 arg2] |
Will copy an existing file or files to another file or directory. |
| DIRECTORY |
Works very much like the DOS command dir, giving the contents of a directory
and the attributes associated with the files therein. |
| MAIL |
Invokes the e-mail program interface for VAX. This works (roughly) like standard
mail in UNIX. When preparing to compose a message, you are prompted for recipient
and subject. |
| LOOK |
The VAX equivalent to the UNIX command ps, LOOK shows you your
current processes. |
TIP: There is a nice table of command
translations from VAX to UNIX. The table has been around for a while and basically
offers UNIX users and others a brief reference. It is located at http://egret.ma.iup.edu/~whmf/vms_to_unix.html.
You might want to examine that table now, because I will refer to a few of those
commands throughout this chapter.
VMS has many of the amenities of other operating systems. The commands may be
just slightly different. For example, the C shell in UNIX has a facility that will
recall commands previously typed at the prompt. This facility is called history.
(DOS has a similar command module, usually loaded at boot time, called DOSkey.)
In VMS, you can recall commands recently typed by holding down the Ctrl key and the
letter B. There are other key combinations that will stop a process, list all processes,
resume a process, report current user statistics, and edit the current command line.
There are still many VAX servers on the Internet, and VMS is still very much alive.
The newest version is called OpenVMS. OpenVMS is available for both VAX and Alpha
machines. Alphas are extremely fast workstations (now at speeds exceeding 400Mhz)
that can run Windows NT, OpenVMS, or Digital UNIX.
TIP: There is a complete online manual
on OpenVMS. It is almost 1MB, but offers comprehensive coverage of OpenVMS and its
capabilities. That document is available at http://www.ethz.ch/ETH/ID/KS.html.docs/SW_Distr/OpenVMS_AXP_Distr/9506-OpenVMS_AXP_new_features.html.
The majority of VAX servers on the Net are older. Many are machines located at
university libraries. These provide users with facilities for searching electronic
card catalogs. In all likelihood, most older VAX machines are at least as secure
as their UNIX workstation counterparts. This is because much is known about the VAX/VMS
system and its security. If there is a hole, it is because the system administrator
missed it.
Security in VMS
Security in VMS is well supported. For example, there is a strong model for access
control. (Whether that access control is properly implemented by the system administrator
is another matter.) Access control on VMS is at least as comprehensive as that on
the Novell NetWare platform. Here are some of the values that can be controlled:
- Time. You can control both the days of the week and the hours of the day
at which a user can access a given area of the system. (The default setting allows
the user access at any time, 24 hours a day, 7 days a week.) The time access feature
works similarly to a firewall: "That which is not expressly permitted is denied."
- Mode. This is an interesting feature. You can specify the mode in which
a user can connect and interact with the system. Therefore, you can restrict remote
network logins to certain times or eliminate them completely. Because this can be
done incisively by user, this feature makes remote security much stronger than on
many other platforms. You can hardly begin to crack if you are restricted from even
logging in. (Next, we'll discuss some utilities that also force callback verification
on remote dial-up users.)
- Resources. You can control the resources available to the user at login.
This is useful for setting directories beyond which the user may not be able to travel.
This is really just scratching the surface of the access control available in
VMS. In fact, there are multiple levels of privileges, and these can be applied to
groups. Groups can be restricted to certain resources, and so on. In other words,
access control is a complex issue with VMS. There are many, many options. It is for
this reason that crackers have a halfway decent chance of finding a hole. Sometimes,
complexity can be a security risk in itself. Crackers are well aware of this:
- The greatest advantage of VMS is its flexibility. The system manager can choose
to implement or ignore a wide range of security features, fortunately for the [cracker],
they all seem to ignore the important ones. It is possible to protect all, any or
none of the files created. It is also possible to provide general or restricted passwords,
or no passwords at all. Access codes can be global or limited. The use log can be
ignored, used only for record keeping, or be employed as a security control tool.
Cross Reference: The previous paragraph
is excerpted from Lex Luthor's "Advanced Hacking VAX's VMS" (Legion
of Doom, June 1, 1985). It can be found online at http://www.mdc.net/~trent/hackvax.txt.
This document is one of the definitive texts on cracking the VMS system. It was
authored by Lex Luthor (an alias, of course), who in 1984 established a bulletin
board called the Legion of Doom. From this (and through other means) Luthor gathered
together a loosely knit cracker group that went by the same name. Legion of Doom
(or LoD, as they are more commonly referred to) pulled off some of the most extraordinary
cracks ever done. LoD published many electronic journals on the Internet that simplified
the art of cracking, including the LoD Technical Journal. The federal government
waged a fleetingly successful war against members of the group. Today, former LoD
members are a little piece of Internet folklore.
Cross Reference: Perhaps one of the best
documents available on the Internet for information on how to secure a VMS box was
written by neither a cracker nor a hacker: Rob McMillan, "A Practical Exercise
in Securing an OpenVMS System," Prentice Centre, The University Of Queensland,
http://nsi.org/Library/Compsec/openvms.txt.
Attacking a VAX (or any VMS-based system) is quite different from attacking a
UNIX system. First, the concept of the password file is different and so is its structure.
UNIX systems maintain /etc/passwd, which defines the username, password,
login shell, and group. In contrast, the VMS system uses a file that defines many
other variables, not simply these values:
- Every DEC running VMS holds the user profiles in a file called SYSUAF (System
User Authorization File). For every user on the system, including the System Manager,
there is a record which tells the computer when and how a user can log onto the system.
It also gives details of password aging, password lengths and all the facilities
that a user has when they are logged on.
Cross Reference: The previous paragraph
is excerpted from "The Five Minute Guide to VMS Security: Product Review PC-DEC-AUDIT"
(AudIT Magazine, 1994). It can be found online at http://www.trillion.demon.co.uk/magrev.htm.
Note that this "comprehensive" approach to the password file has its
pitfalls. One is this: If a cracker gains access to the file and cracks it (using
the utilities described later in this chapter), the whole system is subject to breach,
then and there. However, the likelihood of that happening is poor.
The user, by the way, is identified through the use of a user identification code
(UIC). This is very similar in ways to the GID in UNIX. It identifies the user and
what groups that user may belong to. As you might have guessed, the UIC comes from
the centralized database:
- When you log in to a system, the operating system copies your UIC from your user
authorization (UAF) record in the system user authorization file (SYSUAF.DAT) and
assigns it to your process. It serves as an identification for the life of the process.
Cross Reference: The previous paragraph
is excerpted from "OpenVMS Guide to System Security: Contents of a User's Security
Profile. 4.1.1.3 How Your Process Acquires a UIC," which can be found online
at http://wawona.ethz.ch/OpenVMS_docu/ssb71/6346/6346p004.htm#heading_4.1.1.
Some Old Holes
Following is a discussion of some common holes.
The Mountd Hole
If two successive mount -d -s commands are sent within seconds of one
another (and before another host has issued such a request), the request will be
honored. This was originally reported by CERT in March 1994 and applies to VAX machines
running any variant of Digital UNIX.
The Monitor Utility Hole
In VMS there is a utility called Monitor. The purpose of the program is to monitor
classes of systemwide performance data (either from a process already running or
from a previously compiled monitor file). The hole was not a critical one, but did
bear some concern:
- Unauthorized privileges may be expanded to authorized users of a system under
certain conditions, via the Monitor utility. Should a system be compromised through
unauthorized access, there is a risk of potential damage to a system environment.
This problem will not permit unauthorized access entry, as individuals attempting
to gain unauthorized access will continue to be denied through the standard VMS security
mechanisms.
Cross Reference: The previous paragraph
is excerpted from a CERT advisory titled "VMS Monitor Vulnerability." It
can be found online at http://www.arc.com/database/Security_Bulletins/CERT/CA-92:16.VMS.Monitor.vulnerability.
This was a local problem and not a particularly critical one. For specific information
on that hole (and the fix), obtain the Defense Data Network Advisory concerning it.
Cross Reference: The Defense Data Network
Advisory concerning this hole is located at DDN Security Bulletin 9223, ftp://nic.mil/scc/sec-9223.txt.
Historical Problems: The Wank Worm Incident
Sometime in September or October 1989, a worm was released that compromised machines
on DecNet. On infected machines, the program would print to the terminal a message
relating that the machine had been "Wanked." The message purported to come
from Worms Against Nuclear Killers, or WANK. It was reported in the CERT advisory
about the Wank Worm:
- This worm affects only DEC VMS systems and is propagated via DecNet protocols,
not TCP/IP protocols. If a VMS system had other network connections, the worm was
not programmed to take advantage of those connections. The worm is very similar to
last year's HI.COM (or Father Christmas) worm.
Cross Reference: The previous paragraph
is excerpted from a CERT advisory titled "`WANK' Worm On SPAN Network."
It can be found online at http://www.arc.com/database/Security_Bulletins/CERT/CA-89:04.decnet.wank.worm.
In that advisory, an analysis of the worm was provided by R. Kevin Oberman of
the Engineering Department of Lawrence Livermore National Laboratory. Oberman's report
was apparently generated on-the-fly and in haste, but it was quite complete notwithstanding.
He reported that the worm was not incredibly complex but could be dangerous if it
compromised a privileged account. The worm would enter a system, check to see if
it was already infected, and if not, perform some or all of these procedures:
- Disable mail to certain accounts
- Change system passwords, using a random-number generator, and in doing so, lock
out the system operator
- Use the instant system as a launching pad to attack new ones
Oberman included within his analysis a quickly hacked program that would halt
the march of the Wank Worm. The source of that program can still be examined online
in the original advisories.
Cross Reference: The main advisory, issued
by CERT is located at http://www.arc.com/database/Security_Bulletins/CERT/CA-89:04.decnet.wank.worm.
What's really interesting is the degree of seriousness in the tone of the advisory.
Think about it for a moment. It was just less than one year before that the Morris
Worm incident sent a ripple through the Net. The mere mention of a worm during those
months could cause a panic. Oddly, though, because of the curious name of this particular
worm, some administrators initially took the warnings for a joke.
Also, the Wank Worm was irrelevant to a large portion of the Internet. Since the
worm only affected those running DEC protocols (and not TCP/IP), only a limited number
of potential victims existed. However, while that number was relatively small in
proportion to the entire Internet, there were a great many sites using DecNet.
An interesting treatment of the event can be found in "Approaching Zero:
The Extraordinary Underworld of Hackers, Phreakers, Virus Writers, and Keyboard Criminals":
- The arrival of the worm coincided with reports of protesters in Florida attempting
to disrupt the launch of a nuclear-powered shuttle payload. It is assumed that the
worm was also a protest against the launch. The WANK Worm spread itself at a more
leisurely rate than the Internet Worm, sending out fewer alarms and creating less
hysteria....A method for combating the worm was developed by Bernard Perrot of the
Institut de Physique Nucleaire at Orsay, France. Perrot's scheme was to create a
booby-trapped file of the type that the worm could be expected to attack. If the
worm tried to use information from the file, it would itself come under attack and
be blown up and killed.
Cross Reference: The previous excerpt
is from an article by Paul Mungo and Bryan Glough titled "Approaching Zero:
The Extraordinary Underworld of Hackers, Phreakers, Virus Writers, and Keyboard Criminals."
It can be found online at http://www.feist.com/~tqdb/h/aprozero.txt.
Audits and Monitoring
Auditing capabilities in the VMS environment are advanced. There are different
ways to implement auditing and this is basically a matter of the system operator's
taste. However, by default, VMS will log all logins, failures to log in, changes
in system privileges, and so forth. The default configuration provides a minimum
of logging.
That minimum, however, can be quickly surpassed if need be. The system operator
can apply special access controls on individual files and directories, a user account,
or processes. When undesirable or suspicious activity occurs in relation to these
access control policies, an alarm is generated. The system operator defines what
form the alarm will take. (For example, it is common for system operators to redirect
alarm information to a specific console so that such messages visibly appear and
can be quickly perused at any time.) Of course, severe paranoia in this type of environment
can add up to sacrificing a fair amount of disk space. For example, a system operator
can even have the system generate alarms on a mere attempt to access a file for which
the user has no privileges.
An example would be where a user attempted to view (or list) a file for which
he had no privileges. It would be the equivalent of issuing an alarm for each time
a shell user on a UNIX system tried accessing a root-owned file or directory. One
interesting thing about this is that the alarm can be generated in response to a
violation of policies set against the user, as opposed to global restrictions placed
on the file. I am not sure which model is actually more secure, but I would guess
it would be the VMS model.
The logging capabilities of VMS are quite granular. You can monitor almost anything
from users accessing a file to them starting a protocol-based process. (You can even
log users attempting to change the time.) In addition to this native monitoring,
there are several utilities (some of which I mention later in the chapter) that can
trap terminal sessions and monitor them for inactivity and perhaps other undesirable
behavior.
Various utilities make it easier to crack the VMS platform or, having cracked
it, to avoid detection. As with any other system, these utilities are sometimes of
significant advantage to both the root operator and the cracker.
watchdog.com
watchdog.com was written by a hacker with the handle Bagpuss. The purpose of watchdog.com
is simple: It keeps tabs on users logging in and out of the machine. It is an early
warning system that can alert you to when the system operator (or other similarly
privileged user) logs on.
Cross Reference: The source code and full
explanation of watchdog.com are located at http://www.wordserf.co.uk/mh/vaxhackpro.html.
Stealth
Stealth was also written by Bagpuss. The purpose of this utility is to evade detection
in the event that someone (the system operator, perhaps) issues the SHOW USER
command. This command is much like combining the W, WHO, and PS
commands in UNIX. It identifies the users currently logged to the machine and their
status. Stealth prevents the user from being visible on such a query.
Cross Reference: The source code for Stealth
is at http://www.wordserf.co.uk/mh/vaxhackpro.html.
GUESS_PASSWORD
GUESS_PASSWORD is designed to crack the password file of the VMS system. The program
works quite well, but you have to wonder about its actual value. These days, it is
unlikely that a system administrator would unprotect the SYSUAF.DAT file
(where the passwords are actually located). However, if a cracker could find such
an unprotected password file, this utility would assist in cracking it.
Cross Reference: GUESS_PASSWORD (with
source) is available at http://www.uniud.it/ftp/vms/uaf.zip.
WATCHER
WATCHER is a snooping utility, most commonly used by system administrators. Its
purpose is to watch terminal sessions. From a security point of view, WATCHER is
a good resource. It will monitor how long a terminal has been idle. The system administrator
(or the user) can set the time period after which idle sessions can be automatically
killed. (Idle terminal sessions are in themselves a security risk. Crackers watch
accounts that remain idle for long periods of time. These accounts are deemed good
targets.)
Cross Reference: WATCHER is available
at ftp://ftp.wku.edu/madgoat/WATCHER.zip.
Checkpass
Checkpass is a tool that examines the relative strength or weakness of a given
password in the SYSUAF.DAT file. It's good for versions 5.4 and onward.
Cross Reference: Checkpass is available
at ftp://www.decus.org/pub/lib/vs0127/checkpass/check.zip.
Crypt
As you might guess, Crypt is a DES encryption module for the VMS operating system.
Interestingly, it also provides support for UNIX and DOS. It was developed (along
with the previous utility) by M. Edward Nieland, who wrote these tools primarily
in C and FORTRAN.
Cross Reference: The CRYPT utility is
located at ftp://www.decus.org/pub/lib/vs0127/crypt/crypt.zip.
DIAL
A secure dialback module, DIAL is designed to prevent unauthorized remote users
from gaining access to your system. As explained in the DIAL user's guide:
- Only pre-authorized users and their work location telephone numbers can gain
access to the system through DIAL. Once access is granted the user is disconnected
from the incoming call and dialed back at the authorized telephone number. This provides
the user with free access to his accounts over public telephone lines.
The system works through the maintenance of a file that lists all valid users
and their telephone numbers. (Read: This could be one method of circumventing this
security. Reach that file and you reach DIAL.) It was written in C by Roger Talkov
at Emulex.
Cross Reference: DIAL is available at
ftp://www.decus.org/pub/lib/v00149/dial.zip.
CALLBACK.EXE
Written by Robert Eden of Texas Utilities, CALLBACK.EXE performs essentially the
same functions as DIAL. It was written in FORTRAN.
Cross Reference: CALLBACK.EXE is available
at http://www.openvms.digital.com/cd/CALLBACK/CALLBACK.EXE.
TCPFILTER (G. Gerard)
TCPFILTER is a utility that restricts outgoing connects. As described in the documentation,
the utility does the following:
- ...allows the filtering of outgoing UCX TCP/IP calls. Each attempt to open an
outgoing call is verified with a table of addresses, and is allowed or forbidden.
The validation of the call can be done with two different mechanisms: with ACL, or
with image names. The use of ACL allows controlling each user by the means of an
identifier.
Cross Reference: The previous paragraph
is excerpted from a file titled TCPFILTER.DOC ENGLISH by G. Gerard. It can be found
online at http://www.openvms.digital.com/cd/TCPFILTER/.
I should point out that the term calls means outgoing TCP/IP connect requests.
That is, you can restrict connect requests to specific IP addresses, based on user
information in the Access Control List. A pretty nifty utility. For example, you
could restrict any access to outside hacker or cracker boards. Hmm.
Cross Reference: TCPFILTER is located
at http://www.openvms.digital.com/cd/TCPFILTER/TCP.COM.
Changing Times
The VAX/VMS combination was once a very popular one. And, as I have already related,
OpenVMS is alive and well. However, changes in the computer industry and in public
demand have altered the Internet's climate with regard to VMS. When coupled with
Digital's commitment to Microsoft to provide a suitable architecture on which to
run Windows NT, these changes contributed to a decrease in the use of VMS. This is
curious because today the source code is available. As I have explained elsewhere
in this book, whenever the source of an operating system is available, the security
community has an opportunity to fine-tune it.
Because Digital Alpha stations now run both Microsoft Windows NT and Digital UNIX,
VMS is likely to take a backseat. This is especially so with regard to Digital UNIX
because it is a 64-bit system. Imagine for a moment a 64-bit system running at 400MHz.
In my opinion, this configuration is the most powerful currently available to the
average user. Such a machine (loaded with at least 64MB of RAM) is vastly superior
in my opinion to either the Pentium or the MMX. So the days of the old VAX/VMS are
probably over.
Today's cracker probably knows little about these systems. More concentration
has been allotted to UNIX and as of late, Windows NT. If I were going to contract
someone to crack a VAX, I would look for someone in his mid-30s or older. Certainly,
the advent of the PC has contributed to the lack of VMS security knowledge. Young
people today work mostly with PC- or Mac-based machines. It is therefore rare to
come in contact with a VAX anymore, except as library servers or other database machines.
A close friend of mine has a MicroVAX II in his garage. Each time I visit his
home, we talk about the prospect of cranking up that old machine. One day soon, we'll
probably do just that.
At day's end, VMS is an interesting, durable, and relatively secure platform.
Moreover, DEC was always exceptionally close-mouthed about the security weaknesses
of VAX/VMS. If you retrieve all the known advisories on VAX/VMS, you will see that
DEC routinely declined to include information that could potentially be used by crackers.
(Most often, DEC would advise that VAX users contact their local DEC representative.)
This was a smart move and one that has made it traditionally difficult to crack VAX
servers. If the system administrator of a VAX has been on his toes, after a cracker
has tried all the default passwords, there is nothing left to do but turn to social
engineering.
Summary
The VAX/VMS system is an antiquated one at this stage of the game. However, it
is not out of the race yet. OpenVMS has much to offer. If you are considering a career
in Internet security, you should at least take some brief courses in VMS. Or, if
you are like me and prefer the more direct approach, buy a used VAX and set yourself
to the task of cracking it. These can be acquired for practically nothing today in
misc.forsale.computers.workstation. Many sellers even have the original
installation media.
In closing, it is my opinion that the security of the VAX is advanced and even
somewhat elegant. Moreover, in many parts of the world, the VAX is still popular.
Time studying VAX security is probably time well spent.
Resources
VAX Security: Protecting the System and the Data. Sandler and Badgett.
John Wiley & Sons. ISBN 0-471-51507-8.
A Retrospective on the VAX VMM Security Kernel. Paul A. Karger, Mary E.
Zurko, Douglas W. Bonin, Andrew H. Mason, and Clifford E. Kahn. IEEE Transactions
on Software Engineering, 17(11):1147-1163, November 1991.
Database Security. S. Castano, M. G. Fugini, G. Martella, and P. Samarati.
Addison-Wesley Publishing Company. 1995. (Good chapter on VAX/VMS.)
Security Guidance for VAX/VMS Systems. Debra L. Banning. Sparta, Inc. 14th
National Computer Security Conference, Washington, DC, October, 1991.
A Practical Exercise in Securing an OpenVMS System. Rob McMillan, Prentice
Centre, The University Of Queensland.
How VMS Keeps Out Intruders. Tanya Candia. Computers & Security,
9(6):499-502, October 1990.
ESNET/DECNET Security Policy Procedures and Guidelines. D. T. Caruso and
C. E. Bemis, Jr., ESnet/DecNet Security Revised Draft, December 1989.
C.O.T.S. (Certified OpenVMS Technical Specialist) Examination.
Approaching Zero: The Extraordinary Underworld of Hackers, Phreakers, Virus
Writers, and Keyboard Criminals. Paul Mungo and Bryan Glough.
VMS Monitor Vulnerability. CERT advisory. CA-92:16. September 22, 1992.
© Copyright, Macmillan Computer Publishing. All
rights reserved.
|
