VIRUS-L Digest Monday, 8 Apr 1991 Volume 4 : Issue 55

VIRUS-L Digest Monday, 8 Apr 1991 Volume 4 : Issue 55

Today's Topics:

HC viruses vs. Trojans (Mac)
Unix viruses and damaging programs (UNIX)
re: April Fool's Day virus (PC)
Mutation of Stoned/Implications for self check boot sectors(PC)
Virus Detectors for Suns running UNIX (UNIX)
1813 Virus on a PC (PC)
MDC questions
Joshi Virus in part. table (PC)
re: Unix viruses and damaging programs (UNIX)
Re: Zenith OEM MS-DOS (PC)
Questions re. UNIX viruses (UNIX)
How to kill Stoned in partition table (PC)
Re: More reviews on archives
Call for Papers - DPMA Virus Conference
Systems Security Certification information

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed. Contributions should be relevant, concise,
polite, etc. Please sign submissions with your real name. Send
contributions to [email protected] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks). Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list. Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [email protected].

Ken van Wyk

---------------------------------------------------------------------------

Date: Fri, 05 Apr 91 10:28:15 -0500
>From: Joe McMahon <[email protected]>
Subject: HC viruses vs. Trojans (Mac)

I'd argue that Dukakis was/is a virus. Why? The program created copies
of itself by infecting the Home stack script and them infecting the
stack scripts of other stacks. From my point of view, this fulfills
the qualifications of a virus - a self-reproducing program which uses
other programs as hosts.

A Trojan, on the other hand, is a program purporting to do one thing
and actually doing another. The Dukakis virus actually stated within
its source that it was a virus. I can't think of anything less like a
Trojan - the program did act exactly as it claimed it would.

I don't personally feel there's a "level of simplicity" below which a
piece of code is too simple to be a virus. Just because the
programming language used to write the virus is HyperTalk and not C or
assembly language doesn't mean it can't act like a virus. It's just
easier to detect and stop.

--- Joe M.

------------------------------

Date: 05 Apr 91 10:39:41 -0500
>From: "David.M.Chess" <[email protected]>
Subject: Unix viruses and damaging programs (UNIX)

[email protected] (Van Cleef Henry H):

> I have been asked to consider the possibility of virus, trojan horse,
> etc. attacks on a distributed Unix fileserver system...
>
> My study begins with some assumptions, which I should state here...
>
> b. That all "security" to read and write as a superuser has already
> been breached and that this breach has gone undetected.
>
> c. That one workstation with a bootable hard disk is accessible to the
> individual planning to damage the system...

Those are fine assumptions if you only want to worry about traditional
sorts of attacks (Bad Guy breaking into your system and doing Bad Things
by typing at his terminal/workstation). But if you also want to worry
about the new sorts of risks that come with viruses, you should make
assumptions that are more like:

< b'. That, although the technical security of the system may be intact
< and unbreached, there may be program-sharing patterns that would
< allow a spreading virus to get from an "exposed" user to one with
< superuser authority, through innocent actions of authorized users.
<
< c'. That, rather than a single individual actively attempting to do
< damage on your system, there may be viruses in the outside world
< that could inadvertantly be brought into the organization through
< the innocent actions of authorized users importing programs.

The new dangers that viruses add are that they can cause an "attacker's"
code to run with privileges on your system even if your system's
security is unbreached, no passwords have been guessed, everyone
with access to your system is well-intentioned, and the attacker has
in fact never touched a workstation attached to your system (he may
never even have *heard* of your system).

DC

------------------------------

Date: 05 Apr 91 10:58:43 -0500
>From: "David.M.Chess" <[email protected]>
Subject: re: April Fool's Day virus (PC)

[email protected] (Victoria Harkey):

> There was a posting on April 2 regarding a trojan horse that had activated
> on April 1, and was now a full force virus. Has this virus been identified?
> Has anyone been able to get rid of it?

There was? I don't recall/find any such posting. Perhaps it was a
forged posting, local to your site, and someone's playing an elaborate
joke on you? If not, and you're actually seeing symptoms of
something, perhaps you could post more details? DC

------------------------------

Date: Fri, 05 Apr 91 11:42:14 -0500
>From: padgett%[email protected] (A. Padgett Peterson)
Subject: Mutation of Stoned/Implications for self check boot sectors(PC)

>From: [email protected] (Fridrik Skulason)

>I think somebody may be confusing this with the practice of Zenith DOS
>(or at least some versions of it) to write to the DOS boot record -

Our experience with Zenith XT class machines (model 158 & 159) was that
they did write occasionally to the boot record (not the MBR) as Frisk says.
This action seemed to occur with Zenith DOS 3.0 through 3.2 and the location
written to varied with the O/S but was inside the "reserved" area of the boot
record.

As with Frisk's software, this surfaced when we began installing integrity
checking mechanisms in our PCs last year and started getting changes flagged
on each boot, before we had the checking software "fixed" to recognize that
it was dealing with a Zenith (ATs & 386s did not exhibit this).

Since then, I have been told that early HP Vectras are likely to exhibit this
same condition. For more detailed discussion, I posted a number of items to
Virus-L last year concerning this.

Possibly, the confusion seems to come from the number of different names
applied to the "Master Boot Record" (cyl 0 hd 0 setor 1) which contains both
executable code and the partition table. The DOS Boot Record (first sector
of any DOS partition - only the record of the partition marked "active" is
executed) is something else entirely. The DOS Boot Record can be accessed
with a "load" (L) command from DEBUG. The MBR cannot.

Padgett
------------------------------

Date: Fri, 5 Apr 91 11:42:14 -0500
>From: Padgett Peterson <padgett%[email protected]>
Subject: Virus Detectors for Suns running UNIX (UNIX)

>From: [email protected] (eRic Donaldson)

>From: [email protected] (Van Cleef Henry H)

>My study begins with some assumptions, which I should state here.

>a. That MS-Dos viruses (is this an all-encompassing term for things
>that tamper with and destroy the OS and programs?) have conceptual
>parallels in the Unix o/s. i.e. the kernel is equivalent to
>COMMAND.COM, the file system superblock is equivalent to the FAT, etc.

Kind of: COMMAND.COM is more of an analogue of the shell, the kernel
is closer to the BIOS while IO.SYS & MSDOS.SYS are more like a "run-time
library" - imperfect conceptulization but you get the idea. One reason
MS-DOS viruses flourish is that the O/S has zero integrity checking while
most multi-user systems have some means of defending one user from the
"errors" of another, what we usually term "robustness".

>b. That all "security" to read and write as a superuser has already
>been breached and that this breach has gone undetected.

Given this, an intruder can do anything the system is capable of. Period.
However, a worm or spoof is much more likely than a virus simply because it
is easier to write (UNIX performs some integrity checking of a file against
its header and directory information - MS-DOS does not). Similarly, users of
Sun OSes will be reasured to know that the diversity of Sun platforms
(based on Intel, Mororola, and SPARC architectures) makes it difficult for
an outsider to plant a virus unless it is in the form of source code that
the intruder can compile and execute at your location. Executable code that
will run on a Sun386i is gibberish to the Sun-3 family.

On the other hand, an insider or professional targetting a specific
organization can tailor the attack. Given B, anything is possible.
The only protection in this case is to make B impossible (or difficult,
or, at least detectable). You have to decide the risk/response for yourself.

>From your comments, it sounds like you have a specific workstation and
individual in mind. My minimum suggestion would be to monitor at the network
level (any number of devices can do this) every communication from this
station.

------------------------------

Date: Fri, 5 Apr 91 11:42:14 -0500
>From: Padgett Peterson <padgett%[email protected]>
Subject: 1813 Virus on a PC (PC)

>From: [email protected] (Joseph M Geigel)

1813 is IBM's apolitical way of referring to the JERUSALEM (must be using
VIRUSCAN).

------------------------------

Date: Fri, 5 Apr 91 11:42:14 -0500
>From: Padgett Peterson <padgett%[email protected]>
Subject: MDC questions

>From: [email protected] (James Kirkpatrick)

> Questions: does anybody have a better feel for the probable security
> of the multi-pass SNEFRU...

For discussion: a lifetime ago (when ASR-33 traffic was encrypted using the
tube-driven KY-26), I was involved with definition of such algorithms. The
impression was that for any single key multipass system, if transposition
was not used, a single-pass decryption was still possible. If transposition
was used, the same number of passes may be required to decrypt (if the
encryption is recursive, then the number is something between one and the
recursion frequency).

ANY continuous encryption method can be broken given enough horsepower (the
Intel i860 family makes it easier), the real fist question must be, "How much
is someone else willing to spend to break my system ?" and tailor your
response accordingly.

ps discontinuous cyphers are another subject but DES is continuous.

------------------------------

Date: Fri, 5 Apr 91 11:42:14 -0500
>From: Padgett Peterson <padgett%[email protected]>
Subject: Joshi Virus in part. table (PC)

>From: [email protected] (Tony Locke)

>We have a machine with Joshi on it and can't find something to kill
>it. Anyone have any ideas (have tried SCAN 74B)

As I recall, the Joshi stores the real MBR (partition table) code in
cyl 0 head 0 sector 9 (should be able to tell by looking).
To recover, just cold boot from a known clean write-protected floppy and
use DEBUG to copy the real MBR back to sector 1. The rest of the virus code
will still be on (hopefully) unused sectors on cyl 0 but will be cut off from
execution & harmless.

Warmly,
Padgett

------------------------------

Date: Fri, 05 Apr 91 12:03:16 -0500
>From: Valdis Kletnieks <[email protected]>
Subject: re: Unix viruses and damaging programs (UNIX)

>Date: Wed, 03 Apr 91 21:10:57 +0000
>From: [email protected] (Van Cleef Henry H)
>...
>b. That all "security" to read and write as a superuser has already
>been breached and that this breach has gone undetected.

If the first part of this is true, *all* bets are off. See Ken
Thompson' Turing Award lecture "On Trusting Trust" for an example.

If you are permitting the intruder super-user access and source
access, about the *only* way to recover is to scrub the disks and
re-install the system from known good tapes from the locked vault.
You will have to first format the disks, then convince yourself that
the distribution tapes are in fact clean - don't trust your backup
tapes, they might be bad. Then re-install the operating system. Then
restore user files, checking each one for any and all possible trojans
that might still be left in them.

Under Unix, if you don't trust your kernel, you can't trust ANYTHING.
Your only hope is if you can find a "trick" that the intruder didn't
trap against in his kernel hacking. However, Dijkstra once said:

"Testing can show the presence of bugs, but not their absence."

So if you DONT find anything, that does NOT prove your system is
clean, it only means that it's *either* clean *or* the intruder is a
step ahead of you.

The second part - the assertion that the breach is undetected - is
also quite suspect. Remember - we've only caught the second best
computer criminal. The best is so good that we'll never catch him.
If your system check (whatever its form) actually *finds* anything,
then it won't be an undetected breach anymore.

If you are planning a *serious* research effort on Unix, you should be
addressing the issues of access right compartmentalization - i.e.
work on closing the *holes* so that the guy can't *GET* to superuser
status...

Valdis Kletnieks
Computer Systems Engineer
Virginia Polytechnic Institute

------------------------------

Date: Fri, 05 Apr 91 15:02:00 -0400
>From: "Paul R. Coen" <[email protected]>
Subject: Re: Zenith OEM MS-DOS (PC)

The Zenith versions of MS-DOS are a little different than the
"standard" MS- and PC-DOS.

On earlier versions (3.2 and 3.21 -- I haven't used any earlier ones),
the current time and date was occasionally saved to the boot sector.
That's how the disks "remembered" the approximate time of last use on
boot-up (assuming no real-time-clock).

This caused the boot sector checksum to change. Frequently. It
really freaked me out the first time I noticed it :-).

Zenith DOS 3.3+ (equivalent to Compaq 3.31) does away with this. I
guess they assume that everyone has real-time clocks in their pc's
these days. All of the new Zeniths are shipped with them, anyway. By
the way, different releases of 3.3+ leave very different amounts of
free memory (some use up to 20K of RAM more than others).

I'd assume Zenith 4.01 acts the same way as 3.3+. I have this
aversion to to DOS 4.01, so I haven't tested it extensivly.
------------
Brought to you from Drew University, land of the 2,000+ Zeniths.
Paul Coen -- Drew University Academic Computer Center
[email protected] [email protected]

------------------------------

Date: Fri, 05 Apr 91 11:33:11 -0800
>From: [email protected] (Rob Slade)
Subject: Questions re. UNIX viruses (UNIX)

[email protected] (Dave Gilmour) writes:

> 3) What steps should I take in order to "reduce the risk" |-)

Others will likely give you better technical information, but the biggest
single "whole" that has been shown by the Morris/Internet/UNIX worm, the
WANK/VMS worm and Clifford Stoll's experience ("The Cuckoo's Egg") is the
failure to rename and reassign security files and system passwords. The
best (simple) protection you can give yourself is to change all standard
system defaults relating to system access.

(UNIX gurus, no flames please. you *know* I am not refering to "terminal
type".)

=============
Vancouver [email protected] | "Is it plugged in?"
Institute for [email protected] | "I can't see."
Research into (SUZY) INtegrity | "Why not?"
User Canada V7K 2G6 | "The power's off
Security | here."

------------------------------

Date: Fri, 05 Apr 91 11:41:36 -0800
>From: [email protected] (Rob Slade)
Subject: How to kill Stoned in partition table (PC)

[email protected] (Ken West - Entomology) writes:

> How does one kill the stoned virus when it resides in the partition
> table of a hard drive. Does McAfee's clean kill it? I've had no
> trouble killing in boot sectors with f-disinf but it won't get it in
> the PT. Thanks in advance!

Which version of FPROT are you using? I have had no trouble with
F-DISINF from version 1.11 on, although a recent posting did point out a
potential problem with OEM MS-DOS which has been fixed in 1.14.

=============
Vancouver [email protected] | "Is it plugged in?"
Institute for [email protected] | "I can't see."
Research into (SUZY) INtegrity | "Why not?"
User Canada V7K 2G6 | "The power's off
Security | here."

------------------------------

Date: Fri, 05 Apr 91 09:38:49 +0000
>From: [email protected] (Brian Aslakson)
Subject: Re: More reviews on archives

[email protected] (Kenneth R. van Wyk) writes:
>Chris McDonald, <[email protected]>, has graciously given
>us a series of product reviews which he has written on various
>anti-virus products for both the PC and the Mac. The reviews are all
>available by anonymous FTP on cert.sei.cmu.edu in
>pub/virus-l/docs/reviews. The following files are currently
>available:

>mcdonald.disinfectant - Disinfectant, version 1.5 (Mac)

Nice, but Disinfectant has been at version 2.4 for a long time. Version
2 was a big upgrade. Of course some things are the same. It's still free.

This review would be all but useless.

My one line review of Disinfectant 2.4:
Available from various ftp sites, free, you're wrong if you don't use it.*

__________________
Mac users that is...

[Ed. My mistake - I re-checked Chris's review after reading this
message and he indeed did update his review upon receiving
Disinfectant 2.4. My apologies for any inconvenience.]

- --
Brian Aslakson
[email protected] (mail)
[email protected] (talk)
[email protected] (Me!!)

------------------------------

Date: Mon, 08 Apr 91 08:56:47 -0400
>From: Kenneth R. van Wyk <[email protected]>
Subject: Call for Papers - DPMA Virus Conference

CALL FOR FIFTH ANNUAL COMPUTER
PAPERS VIRUS & SECURITY
CONFERENCE

Thursday-Friday, March 12-13, 1992
World Trade Center, New York City
Sponsored by DPMA Financial Ind. Ch. in
cooperation with

ACM SIGSAC, IEEE-CS [pdg],
Communications Mgrs. Assn.; ICCP, etc., credits

Your Audience: Past attendees have represented industry, military,
government, forensic and academic - creators and users of related
software and hardware.

They travel from U.S. and many international locations, and have
titles such as MIS Director, Security Analyst, Operations Manager,
Investigator, Programming Leader

Topics of Interest Include:

o Prevention, Detection, and Recovery from
Viruses and other Unauthorized Usage

o Case studies of mainframe, pc &/or network security

o Access control, accountability, audit, data recovery

o Surveys or demonstrations of products & techniques

o Particulars of LAN, UNIX, cryptography, military use

o Computer crime, law, data liability, related contexts

o US/international sharing of research & techniques

Paper Submission:
A submission may take the format of either a long abstract (3-5 double
spaced pages) or a draft final paper. Final papers will usually be
6-20 pages in length. Four copies of the submission should be
received regular mail by the Program Chair no later than Tuesday,
December 24, 1991. It's best to include a small photo and
introductory bio not exceeding 50 words. Successful submitters or
co-authors are expected to present in person. Presenters receive
Proceedings.

Paper Format:
Typed double spaced, with last name/page# below bottom line (may be
hand-written), brief (to 200 words) abstract following four centered
heading lines: TITLE (caps); Name; Position Affiliation; Telephone,
City/State/Zip, Electronic Address (optl). Notification: Written and
(where practicable) telephoned con-firmation will be initiated by
Monday, January 29, 1992, to facilitate low cost travel.

Those needing earlier notification should submit papers sooner and
attach a note to this effect. You may be asked to perform specific
revisions to be accepted. Nobody can guarantee you a place without an
acceptable paper.

At the Conference:
There are five tracks. Time your presentation to last 40 minutes and
have clear relation to your paper. A Committee member will preside
over your assigned room and adhere to schedule. Don't hesitate to
submit a presentation you've given elsewhere to a more specialized
audience: Most attendees will find it new - and necessary. On-site
Schedule is duplicated early on first day. If you may have a work
emergency you can reschedule or substitute your co-author.

COMMITTEE:

GENERAL CHAIRPERSON:
Judy S. Brand
Nationwide Computing
(800) 835-2246, x190
PROGRAM CHAIRPERSON:
Richard G. Lefkon
NYU, DPMA Fin. Ind. Ch.
609 West 114th Street
New York, NY 10025
(212) 663-2315
H. Carol Bernstein
IBM, Vassar
Klaus Brunnstein
U. of Hamburg
Tom Duff
AT&T Bell Laboratories
Frederick B. Cohen
ASP
Harold J. Highland
Computers & Security
Jack Holleran
NCSC
William H. Murray
Deloitte & Touche
Donn B. Parker
SRI International
A. Padgett Peterson
Martin-Marietta
Fridrick Skulason
U. of Iceland
Dennis D. Steinauer
NIST
Gail M. Thackeray
Maricopa County, AZ
Kenneth R. van Wyk
CERT, Carnegie-Mellon

------------------------------

Date: Fri, 05 Apr 91 11:58:58 -0500
>From: Kenneth R. van Wyk <[email protected]>
Subject: Systems Security Certification information

International Information Systems Security Certification Consortium, Inc.

Announces

Invitation for Test Question Writers

and

Waiver of Formal Examination

(ISC)2, the International Information Systems Security Certification
Consortium, Inc., is pleaseed to announce the opportunity for
qualified individuals to volunteer as Item Writers, i.e., test
question writers, for the Certified Information Systems Security
Professional (CISSP) examination. Individuals with significant
expertise in one or more of the seventeen topical areas in the Common
Body of Knowledge, are invited to apply for acceptance as an Item
Writer. The seventeen topical areas in which expertise is sought, are
as follows:

o Business Continuity Planning o System Program Security
o Data Classification o Access Control
o Security Awareness o Operations Security
o Computer and System Security o Physical Security
o Telecommunications Security o Information Ethics
o Organizational Structure o Cryptography
o Legal/Regulatory Requirements o Risk Management
o Application Program Security o Policy Development
o Investigation

Item Writer Applications will be reviewed as soon after receipt as
proactical, as test question writing must commence shortly. (ISC)2
will provide the necessary training for those selected, however, Item
Writers are expected to pay their own travel expenses to attend a
training session. Those selected who successfully complete their
duties as an Item Writer, will be publically recognized following the
completion of test development activities.

In addition, (ISC)2 also formally announces the opportunity for
qualified candidates to apply for Waiver of Formal Examination (WFE)
for the Certified Information Systems Security Professional (CISSP)
designation. The basic requirements for candidates to qualify is that
they must have a total of eight years of information security related
experience during the past ten years, with at least five of those
years working directly in information systems security. This must
include a minimum of one year in at least four different areas of
experience related to the topical areas in the Common Body of
Knowledge. Full information regarding this and other requirements to
qualify for Waiver of Formal Examination and/or acceptance as an Item
Writer is contained in the instructions and Application Forms that are
available as described below.

The Waiver of Formal Examination application period will be open for
only six months. WFE Applications are now being accepted, and must be
postmarked before midnight August 31, 1991 to be considered. The fee
for waiver of Formal Examination is $200, plus a non-refundable $50
application fee ($250 total). There is no fee for those who simply
wish to apply as an Item Writer. It should be noted that acceptance
as an Item Writer does not imply acceptance for WFE, as the years of
experience criteria must still be met.

Application Forms and instructions can be quickly obtained by sending
a self-addressed 9"x12" envelope, stamped with postage for 2 ounces
($.52 for domestic U.S., $.63 for Canada, $.55 for Mexico, $1.34 for
International Airmail), to:

(ISC)2, Inc., P.O. Box 98, Spencer, MA 01562, U.S.A.

Please do NOT send fees with your request.

ABOUT (ISC)2: The International Information Systems Security
Certification Consortium, or (ISC)2, was established as a non-profit
U.S. corporation specifically chartered to develop a certification
program for information systems security professionals. (ISC)2 was
founded by representatives of the following groups who are presently
serving as volunteer officers or members of the Board of Directors
(listed alphabetically): Canadian Information Processing Society
(CIPS); Computer Security Institute (CSI); Data Processing Management
Association (DPMA); Special Interest Group for Certified Professionals
& Special Interest Group for Computer Security; Information Systems
Security Association (ISSA); and, International Federation for
Information Processing (IFIP). Other interested membership
organizations are encouraged to contact (ISC)2 regarding cooperative
and mutually beneficial efforts.

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 55]
*****************************************

Downloaded From P-80 International Information Systems 304-744-2253