VIRUS-L Digest Monday, 23 Apr 1990 Volume 3 : Issue 79
Today's Topics:
Writeable Executables
Re: Disinfecting a Macintosh
Re: Mainframe Viruses
Virus Summary Document
Stoned Found in shrink wrapped GEM/3 (PC)
Length field of ~.EXE header (PC)
Translation of ANARKIA virus description (PC)
Re: Disinfecting a Macintosh
Usenet "virus" {Ed. HOAX - no, that's *not* a UNIX variant...}
Virus listings
Viruses in text files (IBM VM/CMS)
Another virus from Germany (PC)
Twelve-Tricks (PC)
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
LEHIIBM1.BITNET for 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, 20 Apr 90 12:19:00 -0400
From:
[email protected]
Subject: Writeable Executables
The original argument as to wether executables was between Howard Aiken
and John von Neumann. Dave Chess and Dave Ihnat associate themselvees
with a long tradition when they debate it. A brief reading of history
tells you that Ihnat/Aiken were right, i.e., correct, but that Chess/von
Neumann carried the day. For reasons of economics most systems reserve
the flexibility for executables to be writeable, even by themselves.
Indeed, the only widely used systems that I am aware of that do not
permit this are the IBM S/3X and AS/400. That they do not is a well
kept secret, even in IBM. The mechanisms required to enforce this, and
other data-type rules, include hiding all physical storage from the user
and application, as well as a fully qualified program name that includes
the version.
While I have always championed Aiken, and, with Ihnat, am quick to
restrict write permission to executables, I am enough of a realist to
recognize that this strategy is hardly applicable to the problem at hand.
The problem at hand is to stop the geometric growth of existing viruses
in the existing environment.
In the long run, the requirement for trust in programs will drive us
inexorably in the direction of immutable programs and application
specific machines. As storage and cycles become cheaper, the apparent
penalty for this will vanish beneath the level of notice. Nonetheless,
writeable executables will never disappear, it won't solve the current
problem anyway, and in the long run, we are all dead.
William Hugh Murray, Executive Consultant, Information System Security
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
203 966 4769, WHMurray at DOCKMASTER.NCSC.MIL
------------------------------
Date: Fri, 20 Apr 90 15:31:18 +0000
From:
[email protected] (David H. Thornley)
Subject: Re: Disinfecting a Macintosh
[email protected] (Peter Jones) writes:
>This is probably a dumb question for the veteran MAC users but here
>goes. A friend of mine tells me he needs to disinfect his MAC. I can
>get hold of the anti-virus programs with no problem. But what bothers
>me is how does one prevent the memory from being reinfected from the
>hard disk, when the MAC is booted from a known good OS. On the PC, one
>boots from a clean DOS; the hard disk isn't accessed until an explicit
>command is given. Doesn't the MAC read its hard disk as soon as it
>finds it?
>
>I would appreciate very explicit instructions for my friend, as I may be
>able to be present at my friend's machine when the disinfection is done.
The best way is to boot the Mac from a secure diskette. This diskette
should have the system and the disinfecting program(s) on it, and should
have the write protect tab in the open position. Put the diskette in
and turn the Mac on. (The Mac is set up to boot from a floppy if offered.)
If the computer ejects it, push it back in. You will then have booted from
a secure system, and can proceed to disinfect the hard drive. Disinfecting
numerous diskettes can be tedious, of course.
David Thornley
------------------------------
Date: Fri, 20 Apr 90 13:26:00 -0400
From: <
[email protected]>
Subject: Re: Mainframe Viruses
About 6 years ago somebody at a California university (I think it was
UCLA) performed an experiment on mainframe viruses. I remember this
experiment because I incorporated it into a paper I was writing at the
time on national security, including security to government computers.
Unfortunately I don't have the paper any more, but I do remember
(vaguely) where I got the information from. There was a small write
up of the project in the Boston Globes Science section. I don't
remember the exact date, but it was between October 1984 and February
1985.
The experiment performed was as follows:
The mainframe (I don't recall what type) was "sealed off", meaning
that any network connections were removed, and all software was backed
up. A virus was then introduced into an account with normal user
privilages. The mainframe was then used in its normal way. By
"normal" I mean that the various programs on the computer were used as
if a group of typical users were doing what they usually do with the
computer.
While the computer was being put through its paces the activity of the
virus was monitored. I believe that this procedure was performed only
two or three times. The virus spread throughout the mainframe so
rapidly that system administrators refused to allow it to be run any
more. I believe that the fasted the virus propogated throughout the
entire computer was within a matter of minutes after it was activated.
Well, the above information is very sketchy. It's been 5 years since
I've seen it, so I don't remember if it is entirely correct. But to
anybody who really wants to find out more about mainframe viruses, I
suggest that you try to find this Boston Globe article. It was very
interesting.
Bruce Pennypacker
[email protected]
[email protected]
------------------------------
Date: Fri, 20 Apr 90 09:37:50 -0700
From:
[email protected]
Subject: Virus Summary Document
There was a request for information in yesterday's Virus-L for a
summary list of known viruses. The VSUM9004 document by Patricia
Hoffman is by far the most comprehensive and is available on most
FidoNet nodes, or on HomeBase at 408 988 4004. It is kept reasonably
up to date and provides information on: Type of Virus; Size; Origin;
Memory Resident Activity; encryption techniques; host types; and a
detailed description of how they work, what activates them and the
visual, disruptive or destructive activation symptoms. A very useful
document.
Alan Roberts
------------------------------
Date: Fri, 20 Apr 90 16:16:42 -0400
From: Jim Dunkin <
[email protected]>
Subject: Stoned Found in shrink wrapped GEM/3 (PC)
Shrink Wrapped Gem/3 Desktop Stoned
Yesterday afternoon I helped a user get rid of the stoned virus that
had infected his machine. This person believed that he had been
infected from a shrink wrapped copy of "Gem/3 Desktop" that he had
just purchased and tried to install. I was quite skeptical at first,
but the disks were write protected, the write protect tab was UNDER
the manufacturer's disk label, and the disk label appeared unaltered
in any way. Still not being a true believer, I went out and bought a
copy of GEM from the same store, and scanned the manufacturer's disks
straight out of the shrink wrap. Sure eneogh, disk three of a five
disk set contained the stoned virus, according to MacAfee's scan57.
This version of Gem/3 is labelled "Release 3.13 RDK 04/89" with a
serial number of 5153-1921.
A technical representative from Digital Research Inc. in Toronto,
Ontario, Canada indicated to me today that the disks I had were OEM
disks, and that the retail outlet I bought them from, was not
authorized to carry these disks. He is looking into the matter
further. The retail outlet I purchased the disks from indicated that
they will pull the disks as soon as they verify for themselves that
there is a problem.
Has anyone else out there stoned GEM disk???
------------------------------
Date: Fri, 20 Apr 90 12:22:48 -0700
From:
[email protected] (Michael Odawa)
Subject: Length field of ~.EXE header (PC)
Recently Fridrik Skulason stated,
> it is not always possible to detect if the program has been damaged beyond
> repair by the [Jerusalem] virus. This may happen if the information on
> the length of the file which is stored in the header is incorrect.
I believe Fridrik was referring to the information in bytes 02-03 and
04-05 of an ~.EXE file, and if so, I would like to agree with what he
said, but pick one small nit with the way he said it.
The information in these fields is not the length of the file, but the
length of the code image that is to be loaded prior to execution of
the file. In commercial programs this value is nearly always
"correct," though it may not coincide with the length of the file.
When a linker creates an executable program in which code segments are
overlaid upon each other, only a portion of the entire ~.EXE file need
be loaded prior to execution. The remaining segments are loaded (and
re-loaded) from either the ~.EXE or an auxiliary (e.g., ~.OVL) file
when called.
Michael Odawa
Software Development Council
[email protected]
------------------------------
Date: Fri, 20 Apr 90 15:59:00 -0400
From: Jim Shanesy <
[email protected]>
Subject: Translation of ANARKIA virus description (PC)
Virus Anarkia. It's a major variation of the Friday 13th virus. It
actuates the same as before, but it releases all of its operations on
the hour, not on the half hour like Friday 13th. In this variation of
the virus the destructive effect is the 12th of October. The choice
of this date is not clear, perhaps because the following day is a
Friday 13th and to give a scare one day before, or perhaps because the
12th is Hispanic day. It can be found easily by looking for the
string "ANARKIA".
[Ed. Thanks to everyone who sent in a translation of the Spanish text
that Frisk posted! I guess that there are indeed a lot of kind souls
out there. Unfortunately, I'd have to post several (!) digests today
just to send out all the translations that I received. Instead, I'm
just posting this one (the first that I received). If anyone has any
serious gripes/corrections in the translation, I'll post them.
Otherwise, the above is the "official" :-) translation. Thanks again
to all who responded! It's efforts like yours that make the networks
*worthwhile*!]
------------------------------
Date: 20 Apr 90 13:06:31 +0000
From:
[email protected]
Subject: Re: Disinfecting a Macintosh
[email protected] (Peter Jones) writes:
> This is probably a dumb question for the veteran MAC users but here
> goes. A friend of mine tells me he needs to disinfect his MAC. I can
> get hold of the anti-virus programs with no problem. But what bothers
> me is how does one prevent the memory from being reinfected from the
> hard disk, when the MAC is booted from a known good OS. On the PC, one
> boots from a clean DOS; the hard disk isn't accessed until an explicit
> command is given. Doesn't the MAC read its hard disk as soon as it
> finds it?
If you run Disinfectant, it will remove all (known) viruses, then ask if you
want to reboot (to clear the memory of potential resident virii).
Say 'Yes!'
I haven't seen any problems with reinfection using any of the major
antiviral programs on the Mac... and Disinfectant certainly helped us get
our lab virus problem under control...
Make sure you also check every disk that will be used in the machine...
Or get SAM (Symantec Antivirus for the Macintosh), or Gatekeeper, or one of
the other INIT/DA/CDEV type antivirals for the machine... saves lotsa trouble
later.
>
> I would appreciate very explicit instructions for my friend, as I may be
> able to be present at my friend's machine when the disinfection is done.
If it's Disinfectant, just hit the "About" button and read away... tells you
all you need to know.
Chad Irby "Lookout! it's a code
[email protected] resource, and it's
\c loaded!"
ac08@untvax
------------------------------
Date: Fri, 20 Apr 90 20:55:42 +0000
From:
[email protected] (Peter da Silva)
Subject: Usenet "virus" {Ed. HOAX - no, that's *not* a UNIX variant...}
> I have to believe that the same yahoos who think viruses are fun
> things on single-user OS machines like PCs and Macs would love to
> infect Unix and VMS systems, if they could.
They can.
> I really do believe that these systems are more difficult to
> circumvent, and this has, to some extent, accounted for great disparity
> in the number of successful attacks on these systems as compared to the
> single-user boxes.
I believe you're right, *but* source code has little to do with it.
It's been at least 6 months since I posted this little fable.
The Usenet virus: a case history.
A cautionary tale.
The Usenet virus was detected when a user discovered that
a program he had received from the net seemed to have two
versions of malloc included with the source. One version of
malloc might be odd, but people have never tired of reinventing
the wheel. Two versions were suspicious, particularly since they
lead to a name conflict when the program was linked.
The first, lmalloc.c, seemed to be identical to the
malloc listed in Kernighan and Ritchie. The second, bmalloc.c,
was rather strange, so we concentrated our efforts on it... this
time was later found to have been wasted.
After a little work during spare moments over the course
of a week we decided it was actually a clumsy version of the
buddy system (a fast but space-inefficient method of memory
allocation). It might make a good example of how not to write
readable code in some textbook, but it wasn't anything to get
worried about.
Back to the first. It made use of a routine named
speedhack() that was called before sbrk() the first time the
malloc() was called. There was a file speedhack.c, but it didn't
contain any code at all, just a comment saying that it would be
implemented in a future version. After some further digging,
speedhack was found at the end of main.c. The name was disguised
by some clever #defines, so it never showed up in tags and
couldn't be found just by grepping the source.
This program turned out to be a slow virus. When it was
run, it looked for a file 'lmalloc.c'. If it found it, or it
didn't find Makefile, it returned. From then on malloc ran
normally.
If it didn't find it, it reconstructed it using a series
of other routines with innocuous names tagged on to the end of
other files. This was apparently an attempt to avoid overly
increasing the size of any one of the files in the directory.
Then it went into Makefile or makefile (it looked for
both) and added lmalloc.o onto the end of the first list of '.o'
files it found. It then reconstructed each of the extra routines,
and speedhack itself, using techniques familiar to any reader of
the obfuscated 'C' contest. These were tagged onto the ends of
the '.c' files that corresponded to the '.o' files in this same
list. The program was now primed to reconstruct the virus.
On inspection, we discovered that about 40% of the
sources on our system were infected by the speedhack virus, We
also found it in one set of shell archives that we'd received
but never unpacked or used, which we took as evidence that it had
spread to a number of other systems.
We have no idea how our system was infected. Given the
frequency with which we make modifications and updates, it's
likely that the original speedhacked code is no longer on the
system. We urge you to inspect your programs for this virus in
an attempt to track it to its source. It almost slipped by
us... if the author had actually put a dummy speedhack in
speedhack.c we would have merely taken lmalloc.o out of the
Makefile and defused *this* copy of the virus without being any
the wiser.
There are other failings in this program that we have
thought of. We have decided not to describe them to avoid giving
the author of this program ideas we might regret. Some ways that
programs like this can be defeated include 'crc' checks of source
files and, of course, careful examination of sources received
from insecure sites.
- -----
Now I have to make a confession. This whole document is a hoax intended
to dramatize the problems involved with viruses and Usenet. I suspect that
most of you were clued to this by the Keywords line. While playing with the
idea and writing this article several things occurred to me:
First of all, this virus is a much more complex program than any of the
viruses that have been spotted on personal computers. I think it has to be,
based on the design goals that a REAL UNIX virus must satisfy. I have not
attempted to actually implement it because of this.
It must be small, to avoid detection. It must not cause files to
grow without bound.
It must infect foreign files, otherwise it's not a virus... just a
Trojan Horse (like the bogus ARC and FLAG programs on the PC). Trojan horses
are a dime-a-dozen.
It must infect source files, since this is the primary software
distribution channel for UNIX. A virus stuck on one machine is a boring
one.
It must not break the infected program (other than what it might
care to do deliberately).
It must not be obvious from a simple examination of the source (like,
changing main to Main and having a virus-main call Main).
I believe that given these goals (which are, of course, subject to
debate) a simpler program would be successful in infesting more than a
small fraction of the machines that (say) comp.sources.misc reaches.
There are systems immune to this particular attack, of course. Ones not
running UNIX, so sbrk() doesn't work. Or ones with radically different
versions of malloc(). Ones with no 'c' compiler. They are in the minority,
though.
On the other hand a virus of this type could infest a large proportion
of the net before it was found. The virus I described does not cause any
direct damage, except for using up a relatively small amount of disk
space. A more vicious virus is possible.
Other variations of this virus are obviously possible. For example, it
could be tagged onto any standard 'C' library routine... I chose malloc
merely because source was available and because it's something that people
complain about, so they wouldn't be likely to find an extra copy suspicious.
Another good routine would be perror(), for the same reason. This would have
the additional benefit of making the spread of the infection dependent on
an additional random factor, making it harder to detect the virus.
Do I think something like this is likely? No. Especially not now that
I've written this little piece of science fiction. I'm sure that
eventually someone will try something unlike this, I suspect that their
virus would get caught much sooner than 'speedhack', because I think
that more people look at the source than conventional wisdom would lead
you to believe. But, again, this is just my personal opinion. Debate is
welcomed... that's why I did this in the first place: to inject some
sense into the debate currently raging in comp.sys.amiga.
- --
_--_|\ `-_-' Peter da Silva. +1 713 274 5180. <
[email protected]>
/ \ 'U` Have you hugged your wolf today? <
[email protected]>
\_.--._/
v Disclaimer: People have opinions, organisations have policy.
------------------------------
Date: Sun, 22 Apr 90 20:38:00 -0400
From:
[email protected]
Subject: Virus listings
I am new in this discussion list, but in many ways old to the whole
subject, since I have been working on various disinfectants since 1988
in Greece (I am also a BBS SysOp in Athens for a BBS which specialises
in virus disinfectants).
I would like to ask a question, and why not, start a discussion about
the moral issue of publishing a virus listing for educational purposes
on a magazine or a book. I have been writing a book about viruses
(unfortunately it is in Greek but I hope to translate it when I finish
it :-) ) and I have been puzzled with this issue. Is it ethically
right to publish code that can create trouble for lots of people, even
if it might be very educational for the non-malicious types of
programmers? If not, is it right to publish disinfectant or vaccine
code? Because even the vaccine code can be easily transformed into a
virus itself, if you only reverse the procedures...
My opinion is that it is inevitable that malicious people will find
the way to write a virus. Therefore, it is OK (in some ways) to
publish code, because it will educate people so that they have the
tools to fight those viruses.
Anxiously waiting for your replies,
Lefteris Kalamaras
Vassar College
- -------------------
Of course, what I
think does not
represent Vassar
anytime!!!
- -------------------
------------------------------
Date: Sun, 22 Apr 90 20:22:00 -0400
From: Lynn R Grant <
[email protected]>
Subject: Viruses in text files (IBM VM/CMS)
Viruses certainly ought to be possible under VM, using the Waterloo
Script text formatter. This formatter has a .sy command that lets you
execute VM/CMS commands while your text file is being formatted. It
is handy for running EXECs to allocate files your document has to
include text from, but it could easily be put to more sinister uses.
------------------------------
Date: Mon, 23 Apr 90 08:28:00 -0500
From: Christoph Fischer <
[email protected]>
Subject: Another virus from Germany (PC)
Over the week end I disassemled a new virus, it was found in Stuttgart,
West-Germany during an anti-virus campaign of a computer magazine.
Here are the facts:
1. It infects COM and EXE type files via INT 21 (4b00)
2. It installs a TSR
3. after its trigger date it will play randomly one of 8 tunes
4. COM type files grow by 1971 bytes EXE will grow 1971 + up to 15 bytes
5. It uses INT 21 INT 08 INT 24
6. Its "music engine" is able to resolve 1/8 notes, doted notes, legato
non legato, stakato and so on
7. 4of the first 6 tunes are typical German hiking or roving songs dating back
to a "Back to Nature Movement" in the twenties. The 7th tune ist I think
garbage. The 8th tune is part of the coding of the virus itself.
(tune 1: "Jenseits des Tales ..." tune 2 : "Horch was kommt von drausen
rein" tune 3: "Auld lang syne" tune 4: "Wenn die bunten Fahnen wehen ..."
tune 5 : "Nobody knows the trouble I've seen" tune 6 : "Hoch auf dem gelben
wagen" tune 7 : garbage tune 8: INT 08 handler)
This is a preliminary analysis, more will follow.
Fridrik Skulason, Dr. Alan Solomon and John McAfee will or have already
included this virus in there scanners.
As a name I discussed with Dr. Alan Solomon "8-tunes".
Sincerely
Christoph Fischer
*****************************************************************
* Christoph Fischer and Torsten Boerstler and Rainer Stober *
* Micro-BIT Virus Team / University of Karlsruhe / West-Germany *
* D-7500 Karlsruhe 1, Zirkel 2, Tel.: (0)721-608-4041 or 2067 *
* E-Mail: RY15 at DKAUNI11.BITNET or RY12 at DKAUNI11.BITNET *
*****************************************************************
------------------------------
Date: Mon, 23 Apr 90 08:53:56 -0500
From: Christoph Fischer <
[email protected]>
Subject: Twelve-Tricks (PC)
Hi,
two questions connected to twelve tricks recently appeard on VIRUS-L
1.Someone has found "twelve tricks - B" on his disk.
well there is no such thing as twelve tricks - b the scanner from
H & B EDV looks for a string, that is expected in an infected partition
table, in normal files. They didn't read well Dr. Solomon and I published
an exact report on VALERT-L. This string can't be found in the "dropper"
program as well since the "dropper" program uses an encryption method
to hide its infection code!
2.The gentleman that claims he really has twelve tricks should check
if he isn't fooled by the same problem as above. If not I sugest
low-level format / fdisk / high-level format / restore from back-up
find the twelve tricks dropper and delete that file ( if it is something
else than a hacked version of the core-test programm please let me know!
We have hundreds of calls of people who run the above mentioned scanner,
it was distributed via a special edition of the CHIP magazine!!!
Sincerely
Christoph Fischer
*****************************************************************
* Christoph Fischer and Torsten Boerstler and Rainer Stober *
* Micro-BIT Virus Team / University of Karlsruhe / West-Germany *
* D-7500 Karlsruhe 1, Zirkel 2, Tel.: (0)721-608-4041 or 2067 *
* E-Mail: RY15 at DKAUNI11.BITNET or RY12 at DKAUNI11.BITNET *
*****************************************************************
------------------------------
End of VIRUS-L Digest
*********************
Downloaded From P-80 International Information Systems 304-744-2253
