|
|
 |
|
|
|
register |
bbs |
search |
rss |
faq |
about
|
|
|
meet up |
add to del.icio.us |
digg it
|
|
|
|
VIRUS- L Digests - May, '88
NOTICE: TO ALL CONCERNED Certain text files and messages contained on this site deal with activities and devices which would be in violation of various Federal, State, and local laws if actually carried out or constructed. The webmasters of this site do not advocate the breaking of any law. Our text files and message bases are for informational purposes only. We recommend that you contact your local law enforcement officials before undertaking any project based upon any information obtained from this or any other web site. We do not guarantee that any of the information contained on this system is correct, workable, or factual. We are not responsible for, nor do we assume any liability for, damages resulting from the use of any information on this site.
=========================================================================
Date: Mon, 2 May 88 08:05:15 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
Comments: Resent-From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Comments: Originally-From: [email protected]
From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject: Viruses: another perspective
Here's a VIRUS-L submission that was forwarded to me:
Ken
------------------------------------------------------------------------
= Kenneth R. van Wyk = If found wandering aimlessly, =
= User Services Senior Consultant = please feed and return... =
= Lehigh University Computing Center =-------------------------------=
= Internet: <[email protected]> = This just in: =
= BITNET: <LUKEN@LEHIIBM1> = Humptey Dumptey was pushed! =
------------------------------------------------------------------------
----------------------------Original message----------------------------
One should not be surprised that the discussion of viruses
by computer users should focus on how to protect their own
systems. However, as I read RISKS I become concerned that
is how the problem is perceived.
A virus is a special case. It is a social disease. It
attacks not only a target system, but a population of
systems, and social order all at the same time. I am sure
that if you have imported one into your system and if it
does something destructive, you will see primarily in terms
of the destruction that it does. However, similar damage
could have been done by any Trojan Horse or even by your own
error.
The problem with the virus is not in the damage that it does
to one system, but with the damage that it does to a
population and to the fabric of trust that is essential to
the sharing of programs and other data and to commerce in
general.
Suppose that viruses become so pervasive that even those who
have never seen one become afraid to use any program that
they did not write themselves. Suppose that because of the
publicity received by viruses, the public at large were to
loose confidence in all computers, in the information they
generate, and in information in general.
If you think that that is far-fetched, then I ask you to
think back to the panic that followed the Tylenol
contamination. In a society in which 1500 hundred people a
year die early because of the use of asbestos, another 15000
from the use of fossil fuels, 40,000 from the use of the
automobile and 200,000 from the use of tobacco, the level of
concern was out of any realistic proportion to the number of
deaths. But it was not out of proportion to the effect of
the loss of confidence in the medicine supply or even of the
food supply. I suggest that it was the unconscious concern
for the effects of the potential loss of confidence that
caused the panic.
The perpetrators of the virus know very well how it will
behave in the target system, but they have no idea how it
will behave in the population. The XMASCARD program did not
do any damage in the user's machine, but it brought a
multi-million dollar network to its knees. The scope and
sensitivity of that network was not only beyond the
perpetrator's knowledge, but it was beyond his
comprehension.
The perpetrators of these toys are, like the sorcerors
apprentice, playing with powers far beyond their knowledge
or control. The potential for damage is far beyond their
puny powers to predict, skills, motives, or their intent.
They are toying with the mechanisms of cooperation and
coordination that characterize humanity. They are to be
pitied for their ignorance, but they are not to be
tolerated, much less admired or emulated. A society that
depends for its own proper functioning upon any mechanism,
dare not tolerate any interference with the intended
operation of that mechanism.
Bill Murray
WHMurray at DOCKMASTER
=========================================================================
Date: Mon, 2 May 88 08:05:47 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
Comments: Resent-From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Comments: Originally-From: [email protected]
From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject: "Write-protection" for hard disks
And another forwarded submission:
Ken
------------------------------------------------------------------------
= Kenneth R. van Wyk = If found wandering aimlessly, =
= User Services Senior Consultant = please feed and return... =
= Lehigh University Computing Center =-------------------------------=
= Internet: <[email protected]> = This just in: =
= BITNET: <LUKEN@LEHIIBM1> = Humptey Dumptey was pushed! =
------------------------------------------------------------------------
----------------------------Original message----------------------------
On April 22, 1988 I received two back issues of a
newsletter entitled "Computer Virology" along
with a product description for the Disk Defender (tm).
"Computer Virology is published in Evanston, Illinois by
Director Technologies, Inc. Director Technologies is the
manufacturer of DISK DEFENDER, a product which write
protects in hardware all or part of a personal computer hard
disk. It is our belief that hardware write protection is
the only 100% reliable virus protection for the operating
system and commonly used programs."
If you have any comments, questions, suggestions or article
submissions, please address them to:"
Director Technologies, Inc.
Technology Innovation Center
906 University Place
Evanston, IL 60201
312-491-2334
[Quoted without permission from the masthead of the newsletter. I am in no
way associated with this firm. This is not a recommendation or endorsement of
their product.]
The product appears to be a half-card that installs between
the drive and the hard disk drive controller card. It can
make a portion of the or all the hard disk
"write-protected." It has an outboard component with a
3-position switch which permits you to select between
"full|zone|none." The outboard switch can be removed in
order to remove the discretion from the user. In other
words, it is a hardware write-protect tab for a hard drive
zone. The size of the zone appears to be chosen by setting
dip-switches on the card itself.
To suggest that it is 100% effective against a virus is to
overstate. Studies in biology suggest that a virus can
thrive even in a population in which a large percentage of
the members are immune, if a there is sufficient commerce
among the non-immune members. This is not an argument
against vaccines but only a caution about the limits of
their effectiveness.
Depending upon design of the virus, the target system and
population, and the chosen distribution vector, the
effectiveness of this mechanism against the spread of the
virus might vary from high to none at all.
Good hygiene is the general defense against viruses, but
there are limits to how effective it can be. Nonetheless,
the individual can and should protect himself within those
limits.
Page 1
=========================================================================
Date: Mon, 2 May 88 09:32:17 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Jim Eshleman <LUJCE@LEHIIBM1>
>Date: Tue, 26 Apr 88 09:39:51 CDT
>From: Frank Peters <PETERS@MSSTATE>
>Subject: MacIntosh Virus Information Request
>To: <VIRUS-L@LEHIIBM1>
Hello,
We are interested in obtaining information about virus programs
(both causes and cures) on the Apple MacIntosh. There seems to be
information available on IBM PC problems but very information about
the Mac. Is this because there are fewer virus programs for the Mac
or because of smaller interest in the mac?
Thanks
Frank Peters
Mississippi State Computer Center
Jim Eshleman
Lehigh University Computing Center
=========================================================================
Date: Mon, 2 May 88 09:34:43 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Jim Eshleman <LUJCE@LEHIIBM1>
>From: "John D. Abolins" <OJA@NCCIBM1>
>To: Virus Discussion List <VIRUS-L%[email protected]
>Subject: LaSalle talk of 288 April 88 concerning the "viruses"
I did go to the lecture at LaSalle yesterday. I am still working on
translating my quick notes into readable text. This should ready some
time next week. Overall, the lecture was excellent and thourough without
giving too much detail (to any unscruplous people in the audience.)
After the talks by the panalists, MS-DOS anti-virus program disks were
made available to the public. The disks contain public domsain and share
ware software plus general virus text files. Three of the panalists
work with companies which produce virus detection software. More on this
later.
Incidentally, if anyone on this forum is interested in any printed items
from the forum or elsewhere, please leave me note. I can arrange for
copies of much of these items.
J. D. Abolins
Jim Eshleman
Lehigh University Computing Center
=========================================================================
Date: Mon, 2 May 88 15:12:41 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject: (old) Amiga virus information, for what it's worth...
I just found some information that I had sitting around concerning
an Amiga virus. It's kind of old, but it could be interesting to
some people, so here it is:
---------
From: [email protected] (Bill Koester CATS)
Newsgroups: comp.sys.amiga
Subject: Amiga VIRUS
Date: 13 Nov 87 19:32:05 GMT
Organization: Commodore Technology, West Chester, PA
THE AMIGA VIRUS - Bill Koester (CATS)
When I first got a copy of the Amiga VIRUS I was interested to see
how such a program worked. I dissassembled the code to a disk file and
hand commented it. This article will try to pass on some of the things
I have learned through my efforts.
1) Definition. 2) Dangers. 3) Mechanics 4) Prevention
1. - Definition.
The Amiga VIRUS is simply a modification of the boot block of an existing
DOS boot disk. Any disk that can be used to boot the Amiga (ie workbench)
has a reserved area called the boot block. On an Amiga floppy the bootblock
consists of the first two sectors on the disk. Each sector is 512 bytes long
so the boot block contains 1024 bytes. When KickStart is bringing up the
system the disk in drive 0 is checked to see if it is a valid DOS boot disk.
If it is, the first two sectors on the disk are loaded into memory and
executed. The boot block normally contains a small bit of code that loads
and initializes the DOS. If not for this BOOT CODE you would never see the
initial CLI. The normal BOOT CODE is very small and does nothing but call
the DOS initialization. Therefore, on a normal DOS boot disk there is plenty
of room left unused in the BOOT BLOCK.
The VIRUS is a replacement for the normal DOS BOOT CODE. In addition to
performing the normal DOS startup the VIRUS contains code for displaying
the VIRUS message and infecting other disks. Once the machine is booted from
an infected disk the VIRUS remains in memory even after a warm start.
Once the VIRUS is memory resident the warm start routine is affected, instead
of going through the normal startup the VIRUS checks the boot disk in drive
0 for itself. If the VIRUS in memory sees that the boot block is not
infected it copies itself into the boot block overwriting any code that was
there before. It is in this manner that the VIRUS propagates from one disk
to another. After a certain number of disks have been infected the VIRUS
will print a message telling you that Something wonderful has happened.
2. - Dangers.
When the VIRUS infects a disk the existing boot block is overwritten.
Since some commercial software packages and especially games store special
information in the boot block the VIRUS could damage these disks. When the
boot block is written with the VIRUS, any special information is lost
forever. If it was your only copy of the game then you are out of luck
and probably quite angry!!
3. - Mechanics.
Here is a more detailed description of what the virus does. This is
intended to be used for learning and understanding ONLY!! It is not the
authors intention that this description be used to create any new strains of
the VIRUS. What may have once been an innocent hack has turned into
a destructive pain in the #$@ for many people. Lets not make it any worse!!
a.) Infiltration.
This is the first stage of viral infection. The machine is
brought up normally by reading the boot block into memory. When
control is transferred to the boot block code, the virus code
immediately copies the entire boot block to $7EC00, it then JSR's
to the copied code to wedge into the CoolCapture vector. Once
wedged in, control returns to the loaded boot block which performs
the normal dos initialization. Control is then returned to the
system.
b.) Hiding Out.
At this point the system CoolCapture vector has been replaced
and points to code within the virus. When control is routed through
the CoolCapture vector the virus first checks for the left mouse
button, if it is down the virus clears the CoolCapture wedge and
returns to the system. If the left mouse button is not pressed
the virus replaces the DoIO code with its own version of DoIO
and returns to the system.
c.) Spreading.
The code so far has been concerned only with making sure that
at any given time the DoIO vector points to virus code. This is
where the real action takes place. On every call to DoIO the virus
checks the io_Length field of the IOB if this length is equal to
1024 bytes then it could possibly be a request to read the boot
block. If the io_Data field and A4 point to the same address
then we know we are in the strap code and this is a boot block
read request. If this is not a boot block read the normal
DoIO vector is executed as if the virus was not installed. If we
are reading the boot block we JSR to the old DoIO code to read
the boot block and then control returns to us. After reading,
the checksum for the virus boot block is compared to the checksum
for the block just read in. If they are equal this disk is already
infected so just return. If they are not equal a counter is
incremented and the copy of the virus at $7EC00 is written to
the boot block on the disk. If the counter ANDed with $F is equal
to 0 then a rastport and bitmap are constructed and the message
is displayed.
d.) Ha Ha.
< Something wonderful has happened >
< Your AMIGA is alive!!! >
< and even better >
< Some of your disks are infected by a VIRUS >
< Another masterpiece of the Mega-Mighty SCA >
4. - Prevention.
How do you protect yourself from the virus?
1) Never warm start the machine, always power down first.
(works but not to practical!)
2) Always hold down the left mouse button when rebooting.
(Also works, but only because the VIRUS code checks for
this special case. Future VIRUS's may not!)
3) Obtain a copy of VCheck1.1 and check all disks before use.
If any new virus's appear this program will be updated and released
into the public domain. VCheck1.1 was posted to usnet and will
also be posted to BIX.
( Just like the real thing the best course of action is
education and prevention!)
Bill Koester -- CBM >>Amiga Technical Support<<
UUCP ...{allegra|burdvax|rutgers|ihnp4}!cbmvax!bill
PHONE (215) 431-9355
------------------------------------------------------------------------
= Kenneth R. van Wyk = If found wandering aimlessly, =
= User Services Senior Consultant = please feed and return... =
= Lehigh University Computing Center =-------------------------------=
= Internet: <[email protected]> = This just in: =
= BITNET: <LUKEN@LEHIIBM1> = Humptey Dumptey was pushed! =
------------------------------------------------------------------------
=========================================================================
Date: Mon, 2 May 88 16:19:14 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Jim <15360JIM@MSU>
Subject: anti-virus program request procedures
I tried to get the lastest version of FLUSHOT, the anti-Virus/anti-Trojan progr
an for MSDOS. If anyone knows the exact procedures to download that, please
write to me at 15360jim@msu. Thank you!
=========================================================================
Date: Mon, 2 May 88 17:23:14 +0300
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Y. Radai" <RADAI1@HBUNOS>
Subject: The Israeli viruses
Loren Keim writes (25 Apr):
> Israeli Virus: Not much is known. It apparently attaches itself
> to all executable files, appending itself to the end of the file.
> Watch for growing files.
I must admit I find Loren's first sentence rather surprising. The one thing
that spreads faster than a virus is news *about* the virus. And since the
rather detailed report which I wrote on the Israeli virus for the Info-IBMPC
digest has apparently been reprinted in about a dozen other digests and news-
letters, I thought that as much was known about our virus as about others. But
I guess I was wrong, so here are the details:
It works in two stages: When you execute an infected EXE or COM file the
first time after booting, the virus captures interrupt 21h and inserts its own
code. After this has been done, every time any EXE file is executed, the virus
code is written to the end of that file, increasing its size by 1808 bytes. COM
files are also affected, but the 1808 bytes are written to the beginning of the
file, another 5 bytes (the string "MsDos") are written to the end, and this
extension occurs only once.
Symptoms: (1) Because of this continual increase in the size of EXE files
(apparently a bug), such programs eventually become too large to be loaded into
memory or there is insufficient room on the disk (hard disk or diskette) for
further extension. (2) After a certain interval of time (apparently 30 minutes
after infection of memory), delays are inserted so that execution of programs
takes up to 5 times as long. Also, some weird things happen on the screen.
(3) If memory becomes infected when the date is set to a Friday the 13th (the
next such date being May 13, 1988), any program file which is subsequently
executed on that date (without rebooting first) gets deleted. (Other files may
also be affected.)
Note that this virus infects even read-only files, that it does not change
the date and time of the files which it infects, and that while the virus cannot
infect a write-protected diskette, you get no clue that an attempt has been made
by a "Write protect error" message since the possibility of writing is checked
before an actual attempt to write is made.
Actually, this is only one of four viruses which have been discovered by us
so far, although the others are apparently only annoying, not destructive. One
of them is but a slight variant of the above virus; it behaves the same with
respect to (1), the 30 minutes in (2) is only 30 seconds, and the erasure in (3)
does not succeed, due to a bug. It is probably an earlier version of the above
virus.
There are several things you can do to detect, prevent, and/or eradicate this
virus even without any special software.
Detection: Choose one of your EXE files (preferably your most frequently
executed one), note its length, and execute it twice. If it does not grow, it
is not infected by this virus. If it does, the present file is infected, and
so, probably, are some of your other files. (Another way of detecting this
virus is to look for the string "sUMsDos" starting in the 4th byte of COM files
or about 1800 bytes before the end of EXE files; however, this method is less
reliable since this string can be altered without attenuating the virus. In the
variant, the corresponding string is "sURIV 3.00".)
Prevention: In addition to the usual general precautions, avoid running
programs on any Friday the 13th. Of course, you can fake the date. But if your
computer has been set to Friday the 13th by a clock-calendar card and one of the
programs in your AUTOEXEC.BAT file is infected, it will be too late to change
the date after completion of AUTOEXEC.
Cure for infected files: Replace each infected file by a healthy copy (if
you have one). However, note that even if you succeed in replacing all infected
files, the virus will recur if memory remains infected, so re-boot immediately
after replacement.
The two other viruses have April 1 as their target date. One of them affects
only COM files while the other affects only EXE files. If the date has been set
to April 1, they display the message "APRIL 1ST HA HA HA YOU HAVE A VIRUS". In
the EXE version this happens as soon as any infected EXE file is executed,
whereas in the COM version it happens only after (1) an infected COM file is
executed, thereby infecting memory, and (2) any other COM file is executed. In
either case they lock up, forcing you to cold boot. Moreover in the EXE version
there is also a lockup, without any message, one hour after infection of memory
on any day on which you use the default date of 1-1-80. However, to the best of
our knowledge they do not destroy any information. In both versions the file is
extended only once. The main identifying string (corresponding to "sUMsDos" in
the Friday the 13th virus) is "sURIV 1.01" in the COM version and "sURIV 2.01"
in the EXE version.
As a curiosity, all three viruses which attack EXE files write the year
"1984" into the 19th and 20th bytes of each EXE file which they infect (in the
form 84h 19h), replacing the checksum which normally appears there.
I hadn't heard of any occurrence of these four viruses outside of Israel
until I read (in Joseph Beckman's message of 29 April) that Fred Cohen stated
that the Hebrew U. virus (presumably meaning the original Friday the 13th
virus) has spread to the U. S.
Automatic detection, prevention and cure: A pair of programs has been
developed for these viruses by Yuval Rakavy, a student in our Computer Science
Dept., and Omri Mann. One of them, UNVIRUS, cures already infected files by
removing the virus code; it is specific to these four viruses. The other one,
IMMUNE (a RAM-resident program), prevents future infection of memory and dis-
plays a message when there is any attempt to infect it; it may also be useful
against some other viruses.
There are, of course, general-purpose programs which prevent file infection
by preventing writing and formatting of disks when such protection is desired.
I guess BOMBSQAD is sufficiently well known that I don't have to describe it.
Another program, PROTECT, prevents writing onto specific drives (e.g. C:). (I
have a slightly improved version of the program which first appeared in the Jan.
13, 1987 issue of PC Magazine.) The protection is easily toggled on and off
(even when you're not on the DOS command level if you've got something like
HOT-DOS available).
The weakness of programs such as these is that a virus or Trojan horse could
issue a write or format command directly to the controller of a hard disk. A
more secure protection would be a hardware device placed between the controller
and the drive. I am familiar with one such device, called Disk Defender. It
involves dividing the hard disk into two logical drives in any desired size
ratio, one of which is protected against *all* writes, while the other is
unprotected. (You can easily unprotect the protected drive temporarily in order
to transfer files to it.) The trouble with this system is its initial incon-
venience: it requires a complete reorganization of your hard disk (moving all
files and subdirectories into two separate directories according to whether they
are to be protected or not), followed (and preferably also preceded) by a
complete backup of the disk, followed by a re-format of the disk and restoration
of its contents.
* * * * *
The above-mentioned authors of the Israeli anti-viral software have now
developed a program which can detect infection of a file by *any* virus.
Probably most of you don't believe that such a thing is possible. But this
report is already getting too long, so I'll leave the description of that
program to a subsequent report.
Y. Radai
Computation Center
Hebrew Univ. of Jerusalem
[email protected]
=========================================================================
Date: Mon, 2 May 88 16:48:11 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "David M. Chess" <CHESS@YKTVMV>
Subject: The Israeli viruses
> (Other files may also be affected.)
Do you have anything in particular in mind when you say that? I've
heard from people who have done quite a bit of work disassembling
the creature that only EXE and COM files are altered. Have you
heard of it changing any others? DC
=========================================================================
Date: Mon, 2 May 88 15:34:39 EST
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Joe Simpson <JS05STAF@MIAMIU>
Subject: Miami computer virus infection
THIS IS A FIRST DRAFT OF A POSTING TO THE VIRUS-L LISTSERV GROUP.
PLEASE RESPOND WITH EDITORIAL COMMENTS.
MIAMI UNIVERSITY WAS HIT BY AN OUTBREAK OF MS-DOS AND MACINTOSH
VIRUS APPROXIMATELY 10 DAYS BEFORE THE END OF SEMESTER. VIRUS
APPEARED IN VIRTUALLY EVERY MICRO LAB ON CAMPUS WITHIN 2 DAYS OF
FIRST NOTICE. THE IBM VIRUS APPEARED TO BE A VARIANT OF BRAIN.
THE MAC VIRUSES APPEARED TO BE IDIOT AND SCORES.
SCREENING PROCEDURES WERE INSTITUTED IN THE LABS TO DETECT AND
QUASH VIRUS INFECTED DISKETTES. DETECTION BECAME MORE ACCURATE
OVER TIME. THE PROCEDURE USED TO DISINFECT DISKETTES IS:
1) COPY DATA FILES (WP, SPREADSHEET, DATABASE) TO "CLEAN MEDIA"
2) FORMAT INFECTED DISKETTE ABANDONING ANY DOS AND OTHER EXECUTABLE
FILES.
3) COPY DATA FILES BACK ONTO THE USER DISKETTE.
THERE IS SOME REASON TO BELIEVE THAT THIS PROCEDURE IS OVERLY CAUTIOUS.
IN THE MS-DOS WORLD:
SCREENING PROCEDURES STARTED WITH LOOKING FOR THE WORD "BRAIN" IN THE
DISKETTE LABEL. NOW WE LOOK FOR THREE OR MORE CONTIGUOUS BAD SECTORS
USING SOMETHING LIKE THE NORTON UTILITIES.
A STUDENT HAS WRITTEN A PROGRAM TO LOOK FOR VIRUS IN RAM. THE SAME
STUDENT IS ATTEMPTING TO REVERSE ENGINEER A SOLUTION. FRED COHEN
FROM UNIV. CINN. HAS BEEN UP TO ASSIST US AND WOULD PROBABLY HAVE
GOOD INFORMATION ON THE VIRUS IF HE HADN'T CONTRACTED ONE OF THE
HUMAN VARIETY LAST NIGHT. INFECTED DISKETTES HAVE BEEN POSTED TO
BOWLING GREEN FOR STUDY (AND OF COURSE TO FRED). AT THIS POINT WE
ARE NOT SURE HOW LONG THE DORMANT PHASE OF THIS VIRUS WAS. IT MAY
HAVE BEEN SEVERAL MONTHS.
SUBJECT TO FRED'S AND THE STUDENT'S NEW INFORMATION HERE IS WHAT
WE BELIEVE ABOUT THE MS-DOS VIRUS.
IT IS A VERSION OF PAKISTANI BRAIN.
IT PROBABLY CANNOT INFECT A HARD DISK. MORE ON THIS WHEN WE REALLY
KNOW.
PROPERLY INSTALLED LAN'S APPEAR TO OFFER PROTECTION(BECASE OF THE
ABOVE?)
IT LIVES IN THREE CONTIGUOUS CLUSTERS (FIVE SECTORS) MARKED BAD IN
THE FAT.
THE VIRUS INSTALLS IN HIGH RAM AND CAN BE DETECTED
THERE USING STANDARD DOS CALLS.
WE HAVE DISASSEMBLED APPROXIMATELY 1/3RD OF THE CODE. IT MAY INFECT
THE FOLLOWING FILES: COMMAND.COM, PRINT.COM, FORMAT.COM. FRED HAS
A CHECKSUM PROGRAM THAT WE USED TO DIAGNOSE THIS BEHAVIOR. WE
HAVEN'T FOUND THE CODE THAT DOES THIS. IT DOES ALTER THE BOOT RECORD
ON BOTH SYSTEM DISKETTES AND DATA DISKETTES. BOOTING, EVEN WITH A
DATA DISKETTE! LOADS BRAIN INTO RAM TO SPREAD INFECTION.
DAVID KARIPEDES HAS DISASSEMBLED APPROXIMATELY ONE THIRD OF THE VIRUS
AND HAS COME TO THE FOLLOWING CONCLUSIONS:
1. WHEN AN INFECTED BOOT SECTOR IS PROCESSED, BRAIN LOADS IN TO 7
K AT HIGH RAM. 3K OF PROGRAM, THE BRAIN BOOT BLOCK, AND THE
ORIGIONAL BOOT BLOCK ARE LOADED WITH 2 I/O BUFFERS.
2. BRAIN POINTS THE $13 DISK INTERRUPT TO ITSELF AND MEDIATES ALL
DISK I/O VIA AN INTERRUPT IT INSTALLS AT $6D. BRAIN ONLY
ACTS AGAINST DISK READS. PROBABLY USING A COUNTDOWN TIMER IT
CHECKS THE BOOT RECORD OF THE DISKETTE WITH POSTED I/O FOR INFECTION
IF NOT INFECTED IT INFECTS FLOPPIES.
3. BRAIN CHECKS THE DL REGISTER ON READS AND ONLY INTERVENES IF 0,1, OR
2. THUS, IT PROBABLY CANNOT INFECT A HARD DISK.
4. THE INFECTED BOOT RECORD LOADS BRAIN FROM THREE CONSECUTIVE SECTORS
THAT ARE MARKED BAD IN THE FAT. FIVE SECTORS ARE ACTUALLY USED, 3
FOR THE EXECUTABLE CODE, ONE FOR BRAINS BOOT RECORD, AND ONE FOR THE
ORIGIONAL BOOT RECORD.
5. IF RAM IS INFECTED, EVEN USING LOW LEVEL DISK UTILITIES BRAIN WILL
FEED YOU THE FALSE (ORIGONAL) BOOT RECORD!
6. AT PRESENT YOU MUST COMMUNICATE WITH DAVID VIA MY BITNET ACCOUNT.
7. A STAFF MEMBER IS WRITING A DISKETTE SANITIZING PROGRAM WHICH WE
WILL POST TO VIRUS-L.
THE VIRUS WILL PLACE BRAIN IN THE DISKETTE VOLUME LABEL AND
REMOVE IT PERIODICALLY. THUS, ABSCENCE OF BRAIN IS NOT ASSURANCE OF A
CLEAN DISKETTE.
SOME OF THE THINGS THAT THE PRUDENT COMPUTER USER SHOULD DO IN THE
COMPUTER AGE (SAGE WISDOM SUBJECT TO FREQUENT REVISION):
USE ATTRIB TO MAKE COMMAND.COM AND MANY OTHER FILES READ ONLY.
THIS LIST SHOULD PROBABLY INCLUDE PROGRAMS.
BACKUP, BACKUP, BACKUP, BACKUP. I KEEP A 3 WEEK ROLLING BACKUP
TO PROTECT MYSELF FROM DORMANT PHASE VIRUSES AS OBSERVED IN THE
MAC WORLD.
WRITE PROTECT ALL ORIGIONAL DISKETTES WITHIN SECONDS OF OPENING THE
SHRINK WRAP.
WHEN TRANSFERRING INFORMATION BETWEEN COMPUTERS USE DISKETTES THAT
CONTAIN NO EXECUTABLES (SYSTEM AND APPLICATIONS SOFTWARE).
WHERE POSSIBLE BOOT FLOPPIES SHOULD BE WRITE PROTECTED. IT IS NOT
KNOWN AT THIS TIME WHETHER WRITE PROTECTION IS HARDWARE OR SOFTWARE
MEDIATED. WE ARE FOLLOWING UP WITH IBM.
IN THE MACINTOSH WORLD WE SUSPECT THAT WE WERE INFECTED BY SCORES AND
IDIOT. MAC USERS ARE MUCH MORE ATONOMOUS AND OUR INFORMATION IS NOT
AS GOOD. WE ARE STILL TRYING TO OBTAIN COPIES OF INFECTED MACINTOSH
DISKETTES. IN THE MEAN TIME WE ARE DISTRIBUTING KILLVIRUS, VACCINE,
AND FERRET 1.1.
DIAGNOSIS RELIES UPON FINDING CHARACTERISTIC SIGNATURE FILES.
PRESENT RECOMMENDATIONS FOR PREVENTION INCLUDE ALL OF THE ABOVE
RECOMMENDATIONS FOR THE MS-DOS WORLD PLUS RUNNING KILLVIRUS OR
VACCINE.
SOME THINGS WE ARE CONSIDERING FOR NEXT YEAR.
ENCOURAGE STUDENTS TO EXCHANGE INFORMATION ON DATA DISKETTES THAT
DO NOT INCLUDE EXECUTABLES.
MORE WRITE PROTECTION AT DOS ATTRIB LEVEL AND HARDWARE LEVEL.
INVESTIGATE VIRUS PROTECTION SOFTWARE. IN THE MAC WORLD WE ARE
USING VACCINE AND LOOKING AT VIRUSDETECTIVE AND KILLVIRUS.
INVESTIGATE VIRUS PROTECTION IN THE MS-DOS WORLD? USE LOCAL
HACKS TO PERIODICALLY LOOK FOR RAM RESIDENT SOFTWARE THAT SHOULDN'T
BE THERE?
=========================================================================
Date: Mon, 2 May 88 16:54:24 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Peter G. Neumann" <[email protected]>
Subject: Re: (old) Amiga virus information, for what it's worth...
In-Reply-To: <[email protected]>
Gee, That was in RISKS-5.71, 7 December 1987! But thanks anyway.
And many thanks for VIRUS-L. Should be lively for you to keep
track of everything. Should I mention it in RISKS, or would that
FLOOD YOU with overhead? Maintaining mailing lists is a bear, even
with LISTSERVE! P.
-------
=========================================================================
Date: Mon, 2 May 88 17:16:32 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: OJA@NCCIBM1
Subject: A request for virus info
In a recent issue of RISKS, a Congressional aide asked for
information concerning computer viruses and their possible
impact on national security. If you have input concerning this
subject, you can contact-
Herb Lin
House Armed Services Committee
2120 Rayburn House Office Building
Washington, DC 20515
(215) 951-1255
J.D. Abolins
=========================================================================
Date: Mon, 2 May 88 17:18:35 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Peter G. Neumann" <[email protected]>
Subject: Re: (old) Amiga virus information, for what it's worth...
In-Reply-To: <[email protected]>
Terrrific. I have your contribution about VIRUS-L and will post it.
By the way, is it not Humpty Dumpty? P.
-------
=========================================================================
Date: Tue, 3 May 88 07:06:26 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Vin McLellan <SIDNEY.G.VIN%[email protected]>
Subject: The Fate of PD Code
PD need not die -- despite the virus plague; and despite the
obituaries the virus threat has led so many vendor-supported
publications to so (gleefully?) publish. "Public Domain" software
may, however, tend to lean more into "shareware" and away from
"freeware."
Freeware, of course, is inherently cheapest... but now we have the
problem of never really being certain that the code is clean and
free of hidden danger (not in itself a new problem.) Shareware --
which circulates through the same public domain/freeware channels --
is copyrighted and typically accompanied by a request from its
author for a (usually minimal) payment for licensed user rights.
And, more than in the past, a shareware license will likely be
accompanied by a disk with a clean copy of the purchased program.
Nothing is likely to ever displace the PD circuit on the nets
and bulletin boards as the cheapest and easiest way to both
circulate new code and check out what's the newest. Even with
infected code circulating, this can be done safely and intelligently
on an isolated machine without a hard disk.
Obviously, no responsible institution or group (or even an
individual) is going to mix freeware code with working disks
or files. The best defense against infected code is to obtain
a legitimate shareware license -- and a guarranteed clean
copy of the code, directly from the author. For a corporation
or institution, that *contractual* link becomes essential for
its internal security and ease of mind.(This may be lead to
some strange scenes. More than a few programmers who just
tossed out a now-popular freeware program onto a BBS system
years ago may be surprised to find firms or institutions
insisting on the right to pay them -- to establish a contractual
relationship -- but they'll probably survive the shock.) Site or
corporate licenses, now scorned by the industry, may be widely used
here.
In an institutional or user community, it will be up to
local management to either buy enough guarranteed clean copies
on disks... or arrange for trusted reproduction of an original
received directly from the author. But the contract must and
should be the foundation of safe software distribution. So
freeware will inevitably be transformed into shareware; a
craft cult into an profit-making industry sector; hackers
into capitalists -- willy-nilly. (Some skateboard champs may
have to open banks accounts, pay taxes, etc.)
With that, Freeware/Shareware is likely to continue for
the benefit of us all...and to bedevil a software industry
whose pricing policies are more akin to Merlin's mumbled
incantations than to any objective economic factors.
Vin McLellan
The Privacy Guild (Sidney.g.vin%[email protected])
Boston, Ma. 02111 (617) 426 2487
-------
=========================================================================
Date: Tue, 3 May 88 08:17:00 EST
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: J_CERNY@UNHH
Subject: Question related to Macs.
At the risk of exposing my ignorance, I'll ask the following
question.
In reading about methods to disinfect or vaccinate an infected
(or suspected) system, people talk about either throwing away
infected files or running code (macrophage?!) to gobble up the
infected parts.
In thinking of the Macintosh, I'm wondering if there is yet
another place where a virus could lurk -- the parameter RAM??
I don't even know if it is possible to write into that RAM,
except that I have the impression that is where date/time is
stored and the fact that the CHOOSER can update/set date/time
implies it can be written to.
Jim Cerny, University Computing, University of N.H.
=========================================================================
Date: Tue, 3 May 88 08:59:28 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject: LISTSERV options
A couple people have asked me why they don't get a copy of their own
submissions to the VIRUS-L list. Well, that's the default way that
LISTSERV is set up. There's two ways around it; I can set up the entire
list such that everyone receives their own messages, or each user can
set their own LISTSERV options, at their discretion. I prefer the latter.
To tell the LISTSERV program to send you your own submissions, send the
following mail message to LISTSERV@LEHIIBM1:
SET VIRUS-L REPRO
Ok, it's a bit cryptic, but that's the way it works... :-)
Note: Please do not send the above message to the list itself!!!
Ken
------------------------------------------------------------------------
= Kenneth R. van Wyk = =
= User Services Senior Consultant = I can't believe you fell for =
= Lehigh University Computing Center = the oldest trick in the book =
= Internet: <[email protected]> = Lone Star! =
= BITNET: <LUKEN@LEHIIBM1> = =
------------------------------------------------------------------------
=========================================================================
Date: Tue, 3 May 88 10:42:49 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Jim <15360JIM@MSU>
Subject: download FSP UUEARC to Micros
I have the anti-virus file call FSP UUEARC at my IBM 3090 minidisk.
I try to download it to micros. Please tell what additional UNARC file(s) I
need, where to get it, and procedures to actually download it. I knew the way
to download regular files through KERMIT. Thank You All! /Jim
=========================================================================
Date: Tue, 3 May 88 10:50:23 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject: Re: download FSP UUEARC to Micros
In-Reply-To: Message of Tue, 3 May 88 10:42:49 EDT from <15360JIM@MSU>
>I have the anti-virus file call FSP UUEARC at my IBM 3090 minidisk.
>I try to download it to micros. Please tell what additional UNARC file(s) I
>need, where to get it, and procedures to actually download it. I knew the way
>to download regular files through KERMIT. Thank You All! /Jim
Just a guess, but it sounds as if the file is a uuencoded arc file.
Uuencode/uudecode are two programs for converting a binary file into
an ascii file and then back; thus making it easier to transfer binary
files over networks. Once the uuencoded file has been uudecoded, it
should be a standard arc file extractable by PKXARC or ARC. You can
get a copy of uudecode from SIMTEL20.ARPA if you have Internet access,
or I can send you a Turbo Pascal source code version. Please reply by
direct e-mail if you want the Turbo source.
I assume that FSP is Flu_Shot+? I'd be happy to make copies of Flu_Shot+,
uuencode & uudecode, etc. available via this LISTSERV if there's sufficient
interest. Comments anyone? That's not an endorsement of public domain
anti-virus programs; rather, it'd be providing a place where people on this
list could download these programs with a reasonable degree of certainty
as to the integrity of the program.
Ken
------------------------------------------------------------------------
= Kenneth R. van Wyk = =
= User Services Senior Consultant = I can't believe you fell for =
= Lehigh University Computing Center = the oldest trick in the book =
= Internet: <[email protected]> = Lone Star! =
= BITNET: <LUKEN@LEHIIBM1> = =
------------------------------------------------------------------------
=========================================================================
Date: Tue, 3 May 88 13:37:56 EST
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Joe Simpson <JS05STAF@MIAMIU>
Subject: BRAIN virus
We have completely disassembled virus. It behaves as previously
discussed. In the absence of programming bugs it only installs
itself. It definately lives in the boot block plus 3 bad sectors.
It does not infect any "normal" dos files.
I specifically checks for and infects 5.25 inch floppies, no 3.5 ,
no hard disk.
We have a simple brain remover program. Source will be posted to the
list (assembly language) when the author thinks it is pretty enough.
Disassembly and program work done by David Karipedes, a Miami student.
To contact him use my bitnet mailbox.
P.S. Since we have some diskettes with evenly spaced bad clusters in
them, the search is on for the existance of another virus at M.U. We
really don't have useful info one way or another at this time.
=========================================================================
Date: Wed, 4 May 88 09:46:00 URZ
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: BG0@DHDURZ2
Subject: European viruses") from(forum)
=========================================================================
Date: Wed, 4 May 88 09:57:00 URZ
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: BG0@DHDURZ2
Subject: European viruses
Hi folks,
I am working on computer viruses (and protection) for 2 years now,
so I hope that I can contribute some interesting facts on viruses
to this list. Although the description of known computer viruses
should not be the only topic of this list, I like to start with
a quick summary on the viruses I know that are not mentioned here
before. We here in Europe have our own "virus" culture :-) so
it may be of interest for you to have a look across the atlantic:
The first viruses I heard of two years ago are written to show
the THREAT of computer viruses. The first one, VIRDEM.COM is
a non-replacing (not overwriting), not memory-residend MS-DOS
virus. It infects all .COM files on drive A: only. The damage
ias to ask a user for a number between 0 and n (n is the generation
of the virus) if he starts an infected program. If he was wrong,
the program terminates, if he was right, the program starts its
work. This program was distributed to all interested computer
users, especially computer and software manufactures.
The second one was written by myself. It only infects the file
KEYBGR.COM (the device driver for a german keyboard of the MS-DOS
version 2.11, loaded every time you boot your computer). After
15 min. it drives the internal speaker do emit noise every time
a character is send to the screen (Therefore I called this virus
RUSH HOUR :-) ). It was easily to be detected and removed -
because it was for demonstration only.
This two viruses were written in Summer 1986. Ralf Burger (the
author of the first virus VIRDEM.COM) and I get contact in Aug.
1986 and we decided that it is time to inform the public (and not
only professional computer users) of the *threatening* possibilities
of computer viruses. In collaboration with the Hamburger CHAOS
COMPUTER CLUB we organized a public forum on computer viruses
on Dec. 27, 1986. That was the first time the topic of computer
viruses was discussed in an open event here in Europe. We earned
a lot of consolation from the press and all the people there.
Four month later we had a meeting with all the folks again to
see how the things are going. In the meantime the topic of
viruses was discussed in nearly all german computer magazines.
One magazine published a computer virus and a protection program
for a 680x0 machine (Atari) called MILZBRAND. I dont know if it
is good to publish a virus source code but it was not my decision.
Ralf Burger started to write a virus protection program (that is
available now, further comments on it see below) which should not
be able *find* virus programs but to hinder the propagation of
viruses on MS-DOS machines. I think he has done good work.
In spring 1987 I started to think about viruses on mainframes.
The result was a replacing virus for IBM/370 mainframes called
VP/370 (No, I dont send you a copy of this exept you can state
a *REAL* interest in it, e.g. you are a OWNER of such a machine!
I dont want to be the one who is responsible for a damage I cant
figure out.) Since that time I am working (nearly) exclusivly on
virus protection methods.
But now lets return to the viruses I know.
The next virus was a virus written in high level language (TURBO
PASCAL 3.xx) called NUMBER ONE. It only infects compiled Pascal
programs because it needs the Pascal run time library. It is only
100 lines in size.
In winter 1987 I heared of a new virus in Vienna(Austria) and has
the possibility to analyse it. I wrote a flow chart generator for
.COM files and was able to see how it works. Nothing special on it.
Thats all I can say definitly, although a lot of rumors are out here.
But I dont want to talk about rumors.
Ralf edited a book about computer viruses ("Das grosse Computer-
Viren Buch", will be available in English in the near future). He
wrote a lot of demonstration viruses in different languages (MS-DOS
Batch Language, Basic). The Internation Standard Book Number is
ISBN 3-89011-200-5 for the first edition, but you better ask for
the revised second edition.
My next point is on protection methods. I think it is a unsatisfying
work to write programs that can *detect* ALL kind of viruses. So
I think it will be the best to catch viruses (that means hindering
their propagation) by looking at their principles. All viruses have
to *change* program code (in a file or on the disk) if they want
to work the way they are designed. A straight forward method is to
detect changes on files. Take a good checksum algorithm that cant be
forged in a simple way. Run this program on all your files (and/or
entire disk) every time you boot your machine. Make sure that the
checking program is on a write protected disk (TAB!) and you can
detect all changes in .COM and .EXE files. If a program has changed
try to find out why. This is the method Ralf uses for his software-
based protection program.
An other method is to keep ALL executable files encipherd on mass
storage devices, but make sure the ciphering algorithm is GOOD.
GOOD means that it should be an algorithm that allows a quick
decipher but a complicated encipher (trapdoor in the opposite
direction, come on mathematicians: Find a good one!). Write a
new program loader that deciphers loaded programs before execution.
So the executable file only exists in RAM but never on storage
devices. A virus program has to write its *executable* code to
files on disk but this code cant be executed because it is *destroyed*
by the program loader during deciphering. If the ciphering method
is good (see above) a virus cant encipher itself before writing
its own code to a file on disk. This method is just an idea of mine.
A test version for MS-DOS machines works quite well, but I think
my ciphering algorithm is not GOOD in the above sence. Of course
the perfomance of loading programs slows down, so this will be
satisfactory only on fast machines.
The last method I want to mention is a hardware protection. It is
based on optical disks (WORMs). Files on such a device cant be
"overwritten" in common sence, you have to mark the old program
"erased" or "unvalid" and have to store the new version somewhere
else on the disk. If you have a (ROM-)program that checks where
an executable file on the disk is located you are able to detect
infections (or *other* changes in the software -> software revision!)
because the forged program is located at the wrong place. This method
is implemented in Ralf's last project and the results are encouraging.
That's all for today. I hope all of you find it intersting to hear
about the facts here in good ol' germany. If you are intersted in
more you can have a look in a book on computer viruses (ed. by Ralf,
with lot of programs and further information and a lot of articals
from virus programmers, software and security managers and so on.)
Its great to have a forum where the topic of computer viruses can be
discussed in such an open way. Keep on the good work.
All the best for you,
Bernd Fix.
=========================================================================
Date: Wed, 4 May 88 08:04:55 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
Comments: Resent-From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Comments: Originally-From: [email protected]
From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject: ERIC and VULT identified
Here's a forwarded submission:
Ken
------------------------------------------------------------------------
= Kenneth R. van Wyk = =
= User Services Senior Consultant = I can't believe you fell for =
= Lehigh University Computing Center = the oldest trick in the book =
= Internet: <[email protected]> = Lone Star! =
= BITNET: <LUKEN@LEHIIBM1> = =
------------------------------------------------------------------------
----------------------------Original message----------------------------
"ERIC" and "VULT" Identified
ERIC and VULT, the specific targets of the SCORES Apple MacIntosh virus,
were internal projects at EDS in Dallas according to EDS spokesman Bill
Wright. These labels identify proprietary trade secret programs that were
once, but no longer used at EDS.
While SCORES was specifically designed to destroy these applications, it
would infect anything.
All the above was gleaned from "Macintosh Today," May 2, 1988 which also
contained a highly speculative article entitiled "Viruses: Nothing to
sneeze at." If you believe this article, computers have seen their day. In
the future, viruses will make them unuseable.
William Hugh Murray, Fellow, Information System Security, Ernst & Whinney
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
=========================================================================
Date: Wed, 4 May 88 08:46:38 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject: LaSalle talk
A few people have asked me about obtaining any written information on
last week's virus talk at LaSalle College. I'm afraid that I don't
have any written summaries; does anyone out there have anything more
than what's already been sent to the list? If so, please forward it
to the list - it'd be much appreciated! Thanks!
Ken
------------------------------------------------------------------------
= Kenneth R. van Wyk = =
= User Services Senior Consultant = I can't believe you fell for =
= Lehigh University Computing Center = the oldest trick in the book =
= Internet: <[email protected]> = Lone Star! =
= BITNET: <LUKEN@LEHIIBM1> = =
------------------------------------------------------------------------
=========================================================================
Date: Wed, 4 May 88 09:33:44 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject: files are now available
Well, after saying that I'd make uuencode/uudecode and Flu_Shot+
available, I got a whole lot of requests for them, so I've placed
them here on the LISTSERV for public copying. The filenames are:
UUENCODE PAS (note the space, *NOT* a period! This is CMS!)
UUDECODE PAS
FSP UUE
PKX35A35 UUE
FSP UUE is a uuencoded ARC file. PKX35A35 UUE is the PKARC package.
PKXARC is required to unARC the files in FSP.ARC. The uuencode
and uudecode files are in Turbo Pascal v 3.x.
Both of these files are *shareware* and you are encouraged to send
the authors the money that they request for the use of their programs -
see the license agreements of each package for more information.
Ok, now you probably want to try to get these files... Well, it's
similar to signing onto or off of a LISTSERV group; you send a
message to LISTSERV@LEHIIBM1. The message should say:
GET filename filetype listname
For example:
GET PKX35A35 UUE VIRUS-L
This would send you the PKARC package.
Once you've gotten all the files that you want, you would do the
following to uudecode and extract FSP:
compile uudecode into a .COM file.
UUDECODE PKX35A35
PKX35A35 (this step unarcs the self-extracting PKARC package.)
UUDECODE FSP
PKXARC FSP
And after all that, you *should* have a working copy of Flu_Shot+ and
PKARC. If you already have PKARC, this can be a whole lot simpler...
I hope I haven't overly confused everyone. :-)
By the way, you can always get a current list of all files available
on VIRUS-L by sending an INDEX VIRUS-L command to LISTSERV@LEHIIBM1.
Finally, please don't send any of these commands to the list itself!
Enjoy,
Ken
------------------------------------------------------------------------
= Kenneth R. van Wyk = =
= User Services Senior Consultant = I can't believe you fell for =
= Lehigh University Computing Center = the oldest trick in the book =
= Internet: <[email protected]> = Lone Star! =
= BITNET: <LUKEN@LEHIIBM1> = =
------------------------------------------------------------------------
=========================================================================
Date: Wed, 4 May 88 10:46:53 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject: PC security programs
Here's another forwarded submission to the list:
From: <[email protected]> "Scott D. Green, Classroom Services"
Return-path: [email protected]
Date: Wed, 4 May 88 10:10 EST
From: "Scott D. Green, Classroom Services" <[email protected]>
Does anyone have any experience with hard disk security software? Two
that we have for evaluation are "DiskManager PC" and "PC/DACS." Both claim
to be able to prevent a drive or just directories and files from being
tampered with. Out goal is to try to minimize software maintenance on
public lab machines by limiting students' write privileges to the hard
dirve, protecting batch files, etx. Both packages claim to superced
DOS attrib commands and foil Norton Utilities. They also provide "boot
lock": if you boot from a floppy, the hard drive does not exist for you.
Though they don't specifically mention virus protection, it seems a
reasonable side effect.
[I've been evaluating PC/DACS, and it looks pretty nice, although
it's not specifically targetted as being an anti-virus program.
It gives a PC security much like on, for example, a VAX, whereby
you can have separate users - each with different access to different
drives/directories/files/resources. It includes boot protection and
full disk encryption. If you don't install all the boot protection
and encryption features, it's *VERY* easy to get around.
This is not an endorsement of this product - merely a statement of
its features. - Ken ]
------------------------------------------------------------------------
= Kenneth R. van Wyk = =
= User Services Senior Consultant = I can't believe you fell for =
= Lehigh University Computing Center = the oldest trick in the book =
= Internet: <[email protected]> = Lone Star! =
= BITNET: <LUKEN@LEHIIBM1> = =
------------------------------------------------------------------------
=========================================================================
Date: Wed, 4 May 88 10:10:00 CDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: GREENY <MISS026@ECNCDC>
Subject: Viral Code
Hi all....
I have recently been given the task of making sure that all of the software
and/or data that we have in my department is clean and free of viruses. Due
to the fact that I feel that I can't really trust anyone's outside applications
anymore without source code (that I'm able to comprehend as well..), I ahve
decided to write my own stuff. But what I need is the means to test it out.
Copies of the SCORES and/or IDIOT viruses for the macintosh would be very
helpful as we have a number of Macs here, viruses for the IBM PC would also
be helpful as there are even more IBM's in the dept (much to my chagrin! :-> )
At any rate, I am willing to get copies of the virus(es) via EMAIL, US
Mail, tape, or whatever, and once written I will post copies of my disinfectioon
programs to the net -- along with the source code.
Any help would be greatly appreciated.
bye for now but not for long...
David S. "Greeny" Greenberg
Departmental Technician
Department of Learning Resources
Western Illinois University
Bitnet: MISS026@ECNCDC
Internet: MISS026%[email protected]
Disclaimer: My department takes no responsibility for what I say....it's
all supposed to be my opinions....
=========================================================================
Date: Wed, 4 May 88 12:12:00 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Dr. Woody" <WWEAVER@DREW>
Subject: COREWARS, the Scientific American game implemented on a macintosh
Greetings everyone,
There was some inquiry into the Scientific American game "CoreWars". I've
a version for the macintosh. The help manual gives a pretty good feel for
what the game is about. The program is shareware, and the manual includes
the authors name and address - I don't know if it is still current, but
the author says he will send you the source code (in C) for $15. The file
is a trifle long, so I will send it to the list moderator - he can then
put in on the list or in the archives (or throw it away :-) ) as he sees fit.
woody
WWEAVER@DREW
* This is not an endorsement of the product - I've never played it, except to
verify that it ran (on a 512K mac with an old system). But if we ever
succeed in getting viruses off of disk storage and force them to live in RAM,
COREWARS is an interesting metaphor. *
=========================================================================
Date: Wed, 4 May 88 18:10:15 PDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Joseph Sieczkowski <[email protected].lehigh.edu>
Subject: Brain Virus info
I have some specific information on the brain virus. I'd though that
I'd share it with you by forwarding it to the list. Also, I'm sending
the source code to programs called "nobrain.c" and "checkmem.c" to the
owner of the list so he can make them publically avalible. Nobrain
supposedly finds and kills the brain virus if present (memory and floppy).
And checkmem is just a utility to see if its resident.
Hope this is helpful,
------------------------------------------------------------------------------
Comments on the "© Brain" Virus
The virus is benign. All it does is propogate itself. The only way
it can spread is by booting an infected diskette. Once booted, the
virus installs itself in memory and will proceed to infect an DSDD
floppies it can "find".
Diskettes
When infecting a diskette, the virus replaces the boot record (trk 0,
side 0, sect 1) with its own boot record. This is the code that
actually installs the virus into memory. It then locates 3 "free"
clusters from the FAT, loads the actual virus code into those clusters
along with a copy of the "real" boot record, and then marks those 3
clusters as "bad". Finally, it installs a diskette volume label
of "© Brain" on the infected diskette. However, the volume label
format isn't 100% correct so utilities such as Norton's will show it
as a "bogus" directory entry format but DOS will display it.
In the 3 custers (6 sectors), the "good" boot record is in the first
sector and the virus itself is in sectors 2-6 of the 3 clusters.
(Actually, the virus doesn't apprear to need all that space).
Operation
- looks to see if infected (1234H will be in 0004 & 0005 of record)
- it will load itself into the last 7K of ram and then set the
DOS available ram value down by 7... eg 640 will become 633,
so that the virus in memory will be "safe".
- changes the disk read/write vector (13 Hex) to point to his virus
- stores the original 13H vector at a new vector (6D hex) which he
invokes when a "real" read or write is needed.
- the original boot record is moved to the 1st sector of the 3 bad
clusters he as marked (so he can still boot the PC after he has
done his "dirty work")
- his boot code is installed in original boot record location
(Trk Hd Sct = 0 0 1).
- 3 free clusters found, virus and boot rec place here, and marked
as bad.
- while checking FAT, he checks ID byte to insure that this is a
DSDD diskette... won't infect any other kind (which also precludes
hard drives)
- His "© Brain" label is written but he allows for the 2 hidden bios
(he doesn't check if they are present). The result is, if a completely
empty diskette is infected, the label doesn't show up until at least
2 files are on the diskette.
At this point diskette is completely infected. His infection of
new diskettes is sort of random or "haphazard".
- If a disk write occurs, he allows it to proceed as usual.
- After 32 disk reads, he will infect a diskette and then every 4
reads there after... UNLESS, it is a read of trk 0 side 0 (ie
directory area, FAT, etc.). Then he immediately checks if infection
is needed and does so if not already infected. He resets the
4-counter at this point. This results in the virus spreading
rather quickly while somewhat reducing the noticable degradation
from the virus' overhead... tho' it can be seen if you are looking
for it)
That's about it. If you are reading this, I hope it was of some use.
Carl Fussell
------------------------------------------------------------------------------
=========================================================================
Date: Thu, 5 May 88 08:25:29 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject: new files available
I just posted three new files to VIRUS-L. They are:
DIRTY DOZEN
NOBRAIN C
CHECKMEM C
Thanks to James Ford for sending in the Dirty Dozen list, and to
Joe Sieczkowski for sending in the anti-Brain programs. The
Dirty Dozen is the "standard" listing of known trojan/virus programs.
The two C files are as Joe described - Brain killers. I don't
have a Brain damaged :-) disk to test these with, so I'd appreciate
any comments (e-mail them to me please) from anyone who tries them
out. Thanks again guys!
Ken
------------------------------------------------------------------------
= Kenneth R. van Wyk = _ /| =
= User Services Senior Consultant = Ack Thippfft! \'o.O` =
= Lehigh University Computing Center = =(___)= =
= Internet: <[email protected]> = U =
= BITNET: <LUKEN@LEHIIBM1> = Bill 'n Opus in '88! =
------------------------------------------------------------------------
=========================================================================
Date: Thu, 5 May 88 10:52:00 EST
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: J_CERNY@UNHH
Subject: The Shockwave Rider.
As a "literary" note on viruses, I thought some readers might be
interested in a few quoted fragments from John Brunner's science
fiction novel THE SHOCKWAVE RIDER. TSR was published wayyyy-back in
1975! One of the interwoven, though somewhat obscure, themes is of
computer worms and viruses used to protect and attack computer data.
[p. 24] "Then the answer dawned on him, and he almost laughed.
Fluckner had resorted to one of the oldest tricks in the store and
turned loose in the continental net a self-perpetuating tapeworm ... .
It could take days to kill a worm like that, and sometimes weeks."
[p. 25] "Promptly he sent a retaliatory worm chasing Fluckner's. ...
According to recent report, there were so many worms and counterworms
loose in the data-net now, the machines had been instructed to give
them low priority unless they related to a medical emergency."
[p. 173] " ... I'd have written the worm as an explosive scrambler,
probably about half a million bits long, with a backup virus facility
and a last-ditch infinitely replicating tail."
[p. 174] "What you need is a worm with a completely different
structure. The type they call a replicating phage. And the first
thing you must give it to eat is your original worm."
Jim Cerny, University Computing, University of N.H.
=========================================================================
Date: Thu, 5 May 88 10:45:00 CDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: GREENY <MISS026@ECNCDC>
Subject: A thought...
Internet: MISS026%[email protected]
Disclaimer: #include<std_legal_mumbo_jumbo.h>
What with all of the recent discussions on how giving out viral code and
copies of viruses being dangerous, it occured to me that this could be
true. An unscrupulous person could very well pervert such code for his/
her/it's own purposes. The solution that most of netland has seemed to
arrived at is to not distribute such code, but to distribute the techniques
for removing viruses from systems, as well as source code for such removal.
Now stop and think about this for a minute, if I am given the technique
for removing some infection, it also tells me HOW TO INFECT the system
in a similar manner by exposing weak points in the OS. This is as good
as releasing the virus in question, and any unscrupulous persons out there
with a modicum of intelligence will be able to engineer a virus (which may
or may not be even more potent than the one being destroyed...) from the
provided information. Therefore, it makes just as much sense not to release
any techniques on how to kill the viruses as well as programs that do the
actual removal (they could be disassembled and perverted as well).
Of course, this is all not possible, since we all must work together in the
eradication of these beasties, and as such viral code and viruses should
be released to the general public if we are to be able to work on a cure
to this problem. You don't see the US government saying "well AIDS is
pretty nasty stuff, no one can touch it but us, and we'll get back to
ya with our results later..." --- EVERYONE IS WORKING TOGETHER on the
eradication of that deadly disease and it should also be such with computer
viruses....
* flame off *
Bye for now but not for long
Greeny
Bitnet: MISS026@ECNCDC
=========================================================================
Date: Thu, 5 May 88 13:03:14 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
Comments: In-Reply-To: Message of Thu,
05 May 88 12:04:28 EDT from <MISS026@ECNCDC>
From: "David M. Chess 862-2245" <CHESS@YKTVMV>
Subject: A thought...
That's probably a good philosophical point, but the practical point
behind it isn't quite true. Since the only "weaknesses" that a
virus needs to exploit are things like "it's possible for a program
to alter another program" and "it's possible to start a process
that can intercept I/O calls to the OS", and since those are
things that most programmers already know, anti-virus programs
don't have to "give away" anything that would help a virus
writer.
One typical kind of virus-detector just notices (by a checksum
or whatever) what executable files have changed since the last
time it was run. All that reveals about viruses is that some
of them change executable files. More specific anti-virus
programs look for certain (meaningless-in-isolation) data in
certain places in executable files, and tell you that the file
is infected with Virus X if it finds it. All that reveals is
that, for instance, "some virus puts the bytes F1 02 97 BC 00 90
at offset 011E in infected COM files" (no, that's not a real
example).
So it is possible to distribute a certain amount of anti-virus
information without spreading any how-to-write-a-virus information.
(Note that I have carefully avoided giving any opinion about whether
any of the latter sort of information ought to be spread!)
Dave Chess
Watson Research
* Nothing in this posting is an Official Statement of anybody,
* whether I work for them or not.
=========================================================================
Date: Thu, 5 May 88 16:04:00 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject: Another file available
I've posted another file here on VIRUS-L. The filename is:
RISKS LOG
It contains a complete set of all of the computer virus discussions
that have taken place on the RISKS forum over the past year or so.
The file is very large, so it was not a good idea to send it to the
entire list. Because of the file size, please only retrieve this file
if you *really* want it, just to keep unnecessary network traffic to
a minimum.
For the benifit of newcomers to the list, you can retrieve a file on
the list by sending a message to LISTSERV@LEHIIBM1 containing:
GET filename filetype
For the above file, RISKS LOG, you would send:
GET RISKS LOG
To get a list of available files, send, also to LISTSERV@LEHIIBM1:
INDEX VIRUS-L
The available files include a per month log of all of the messages
sent to VIRUS-L.
Ken
------------------------------------------------------------------------
= Kenneth R. van Wyk = _ /| =
= User Services Senior Consultant = Ack Thippfft! \'o.O` =
= Lehigh University Computing Center = =(___)= =
= Internet: <[email protected]> = U =
= BITNET: <LUKEN@LEHIIBM1> = Bill 'n Opus in '88! =
------------------------------------------------------------------------
=========================================================================
Date: Thu, 5 May 88 16:07:00 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: EAE114@URIMVS
Subject: DISSEMINATING SOURCE CODE
Greeny <MISS026@ECNCDC> comments that it is possible to
analyze the code for a virus hunter, and thereby develope
another, more virulant virus. By way of analogy, he comments
that the US government has not declared a monopoly on AIDS
research.
- - Initial Reaction: Good point.
However, while there is no monopoly on the virus, there IS
a definate effort to restric access to samples of the virus
itself, and rightly so. In terms of distributing source-code
of viruses (Virae?) If I have the source code to a virus-killer,
I can reverse engineer it, and get a virus; OR i can run it, as
is, to hunt viruses. If I have the source code for a VIRUS,
I can reverse-engineer it, to make a virus-killer; OR i can
run it as is, to infect other systems.
-
Since I can distribute code that makes it EASY to hunt viruses,
and HARD to create them, why distribute code that does the reverse?
The only reason I can see for wanting a virus is to test your
virus killer, and it seems as if, if you're good enough to
write the killer, you ought to be able to write the virus from the
description.
(PRose: EAE114@URIMVS)
-------------------------------------------------------
Disclaimer: My opinions are supported, dictated, and ghost-
written by the University, the state, the federal government,
The CIA, and the POPE. If you don't like it, sue them.
=========================================================================
Date: Thu, 5 May 88 16:44:00 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject: Virus source code
I suppose we can argue until our fingers bleed as to why or why not
distribute source code to viruses; and there are probably valid
arguments for both sides. But, as a matter of somewhat arbitrary
policy, I don't think that virus source code should be distributed
to the list. Discussion of *how* a particular virus works is great,
but distributing the source code is, in my opinion, not a good idea.
Distributing source code to a program which "hunts and kills" viruses,
however, could be benificial because it is for the common good.
So, that's the official standpoint. Comments/suggestions/flames are
invited *IF* you e-mail them to me directly and not to the list;
it *is* possible to change policy. But, I feel that we've had enough
discussion on this matter on the list already. Everyone made good
valid points...
Ken
------------------------------------------------------------------------
= Kenneth R. van Wyk = _ /| =
= User Services Senior Consultant = Ack Thippfft! \'o.O` =
= Lehigh University Computing Center = =(___)= =
= Internet: <[email protected]> = U =
= BITNET: <LUKEN@LEHIIBM1> = Bill 'n Opus in '88! =
------------------------------------------------------------------------
=========================================================================
Date: Thu, 5 May 88 09:35:00 URZ
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: BG0@DHDURZ2
Subject: Virus Construction Set
Hi folks,
bad news from Germany. I have forgotten to tell you something in my
last message: Not all people concerned with computer viruses (esp.
virus programmers) over here are aware of what they are doing. In April
this year a unbelievable program called "VIRUS CONSTRUCTION SET (VCS)"
was released at the Hannover computer faire CeBIT.
The VCS is a program written for the Atari ST series and allows *EVERY*
Atari user to create his "own" virus. The program is menue driven -
you can select different infection methods, damage initialisers, damages,
and target files. You dont have no know how a virus work to create one,
you just have to know how to turn on your Atari and how to start the VCS
program!!!
No further comments --
All the best to you all,
Bernd.
=========================================================================
Date: Thu, 5 May 88 12:32:36 EST
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Joe Simpson <JS05STAF@MIAMIU>
Subject: Ethics and information
I'd like to respond to three thoughts posted to virus-l.
1. The virus that kills the virus. At first thought seems anathema, but
I see no problem with it if it follows the
ethical restraint: It must not write to a disk without the explicit
permission of the disk operator. This includes, of course, "virus
removal."
2. There has been a lot of discussion about the need to hide information,
and especially code, permitting easy development of viruses. My personal
opinion is that it requires little imagination and readily available
information to write a virus. Say $30 in manuals and some simple
hacking around. If this opinion is accurate, hiding information has
little benefit.
3. There is an opinion that no one should download code from bulletin boards.
Only source code should be distributed. For most people a virus hidden
in source code is just as undetectable as a virus hidden in a machine
image. I hope that this opinion will not prevent virus-l from storing
useful machine images. If computing society becomes overly protective
in response to this anti-social behavior, then we all loose. The
analogy with radical revolutionary doctrine is straigforward.
=========================================================================
Date: Fri, 6 May 88 12:31:00 LCL
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Michael Wagner new! +49 228 8199645 <WAGNER@DBNGMD21>
Subject: Re: A thought...
A number of things were said in this posting that were addressed
by others, so I won't repeat it, but one bears comment still:
> From: GREENY <MISS026@ECNCDC>
>
> ...we all must work together in the eradication of ...(viruses)...
> You don't see the US government saying "well AIDS is pretty nasty
> stuff, no one can touch it but us, and we'll get back to ya with
> our results later..."
Actually, that is exactly what I saw the US government doing for
the longest time. In fact, for several years, the government
solution to AIDS was 'a hope and a prayer'. Stop promiscuity and
AIDS will go away by itself. And besides, AIDS only strikes
people who are non-white, or homosexual or drug abusers. Nothing
there for decent people to worry about. Why should we research
the thing? Why should we provide care for the afflicted? Nobody
we care about is affected!
> --- EVERYONE IS WORKING TOGETHER on the eradication of that deadly
> disease and it should also be such with computer viruses....
This is a relatively new phenomenon that real research is being
done on AIDS, and recent studies have shown that the delay will be
responsible for untold deaths. The stakes are clearly different
with computers, but the idea isn't much different. Work done now
to understand and limit virus spread will save much pain later.
Michael
=========================================================================
Date: Fri, 6 May 88 08:42:58 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject: A reader's description of LaSalle talk.
I just got this description of the LaSalle virus seminar from
J.D. Abolins - thanks J.D.!
Ken
-----------------
Computer Virus Seminar at La Salle University
reported by J.D. Abolins
OVERVIEW
(Philadelphia,PA) On Thursday, 28 April 1988, the Philadelphia Area Computer
Society (PACS) and La Salle University Academic Computing presented a seminar
on computer viruses. The panelists for the seminar were-
- John Hagman, a Personal Computer (PC) Support Analyst with the Phildelphia
Electric Company (PEC)
- Donald Montabana, a MacIntosh and PC support specialist at the University of
Pennsylvania
- Steve Weissman, vice-president of PACS and a systems operator (sysop) for
one of PACS bulletin borard system's (BBS) sections.
- Raymond Glath, president of RG Software Systems, Inc.
- Pam Kane and Andy Hopkins, both from Panda Systems.
Steve Longo, the president of PACS and the director of La Salle University
Academic Computing, moderated the seminar.
The panelists took turns speaking, Instead of using a rigid, subject-based
outline for the presentations, the presentations focused on the speakers' own
experiences and viewpoints. At certain points, the audience was given a chance
to ask questions and to make comments. The audience participation was lively.
(15 minutes before the seminar began, there were only a few people in the
audience but by the time the seminar got under way, the room was filled.)
After the seminar, copies of virus literature was distributed. PACS had an
anti-virus/anti-Trojan programs disk available for purchase.
THE PRESENTATIONS
RAY GLATH: Ray Glath, the first speaker, told how when he started working
with computers over 20 years ago, there were some cases of malicious programs.
But in those days, those programs did not go far. Today, several factors have
contributed to the ability of such programs to move rapidly. First is the
proliferation of the microcomputers; in short, there are far more computers
than in 1964. The other factor is the "pass around" attitude towards software
along with a casual attitude towards software piracy. Mr. Glath described
shareware and freeware as good marketing approaches but warned that there are
some nasty people who modify good programs, making harmful copies of them.
A virus, as defined by Mr. Glath, is "a nasty" that replicates itself. But
whether the nasty program is a virus or a Trojan Horse, it all boils down to
computer sabotage. He outlined the types of nasty programs-
- MASSIVE DESTRUCTIVE which destroy the whole computer system.
- PARTIAL DESTRUCTIVE which may attack the File Allocation Table (FAT) or the
boot sector of a hard disk.
- SELECTIVE ATTACK which attacks specific files (eg.; COMMAND.COM or .EXE
files.)
- RANDOM ATTACK which are elusive. They have no easily discerned mode of
attack and, thus, escape detection for a long time.
- NON_DESTRUCTIVE which are annoyances. They usually produce messages or
modify disk labels.
Mr. Glath closed his presentation by noting that the virus proliferation is
a real trend that is getting considerable attention, but one will be quite
safe if one takes precautions.
DONALD MONTABANA: Mr. Montabana reviewed his experiences with computer viruses
at the University of Pennsylvania. Since January 1988, the number of virus
incidents had not been severe. On average day, he would get five to seven
calls about possible virus attacks; most of them were false alarms. On the
University's campus, only 10% or less of the calls are actual virus attacks.
Most of the recent cases involve ASHAR, BRAIN, or their variants. These
types have been prevalent on several other campus as well. These programs will
modify disk volume labels; some of them are quite destructive. They get their
names from the names they will put into the volume labels. Mr. Montabana noted
that the BRAIN virus will infect only the 360K format disks. Other formats,
such as the 720K and 1.44M, are immune to the current version of BRAIN. He
noted that BRAIN, unfortunately, can eat away at the FAT and that it resides
on the boot sector of a hard disk.
Mr. Montabana also described some of the precautions used at the University
for "safe computing". Certain of the Local Area Networks (LAN's) are isolated.
Their users are restricted in what diskettes they can use on these systems.
Even blank, formatted diskettes are off-limits. Only unformatted diskettes are
allowed to be brought in; they are formatted on these "clean" computers.
The arrogance of some virus writers was noted by Mr. Montabana when he told
about the threats by virus writers aimed at Tom Brown, the author of VACCINE
for the MacIntosh. The virus writers threaten to unleash nastier programs that
will circumvent VACCINE's defenses if Tom Brown continues developing anti-
virus programs.
He noted that the National Computer Security division of the National
Security Agency (NSA) is tracking down the perpetrators, intending to
prosecute them. Mr. Montabana, along with the other panelists, hope that the
sucessful prosecution of virus writers will deter future virus makers. Also,
he forsees specific anti-virus legislation down the line.
JOHN HAGMAN: Mr. Hagman explained how he became interested in malicious
programs after several "hard cards" (hard disks mounted on a card) crashed
within weeks of installation at his office. The disks had their boot sectors
wiped out. Although the cause of these crashes is still unknown, the incidents
perked his curiousity. PEC asked Mr. Hagman to research available defenses
against viruses and other malicious programs. So he looked into the various
commercial and non-commercial programs. He commented, "There is no piece of
software that is going to be the answer." The most popular of these program
protect the operating system by checking it periodically against a backup or
by using numeric checksum methods. Others look for direct reads and writes to
disks. Besides anti-virus software, Mr. Hagman mentioned several other
safeguards. Write-protect one's original DOS diskette. Periodically, re-
install the systems files on one's hard disk. Computer installations may
consider the policy used by PEC- no unauthorized software on the company's
machines.
STEVE WEISSMAN: He started his presentation by saying that he himself has not
seen a virus and that he is somewhat of a "doubting Thomas". He proceeded to
describe his experience as a computer systems administrator for a large
company and as one of the sysops for the PACS BBS. In both areas, he has not
encountered a virus. Mr. Weissman described several factors that has kept his
section of the PACS BBS virus-free. The first safeguard is that PACS gets its
public domain/shareware software from large software distributors which, for
their own protection, check the software. Second, the PAC BBS is a closed BBS;
only PACS members can get access. Each uploaded file can be traced back to the
person who uploaded it. During the seminar, Mr. Weissman emphasized, "Backup.
Backup. Backup," ones data. Regarding the future of the viruses, he said that
he does not know but he hopes that well-publicized prosecutions will stop the
trend.
PAM KANE: The two represenatives from Panda Systems covered separate aspects
of the virus problems. Ms. Kane dealt with them from the human resources
aspect while Mr. Hopkins covered the technical aspects. Ms. Kane expressed her
concern that "BBS's and shareware are getting the image of being the 'public
baths' of the computer world." She admonished computerists not to panic but,
rather, to take wise precautions. Comparing the viruses to the AIDS situation,
she advised that if one is "monogamous" with one's computer, one will be quite
safe. She also noted that main mode of virus infection is through innocent
spreading by people who are unaware of the viruses. Two of the most prominant
categories of innocent carriers are 1) the people who take computer work home
with them, and 2) the people who do not have a computer at home and are using
their office computers for computer course homework. Both of these categories
represent some of the most valuable workers in a corporation. Ms. Kane
mentioned some of the precautions to prevent virus spread. One of these
methods is to boot from floppy when preparing to call a BBS to download files.
The files should be downloaded to a floppy, not to the hard disk. If one does
get a virus, remember to use low-level format when cleaning up the hard disk.
She emphasized the importance of keeping aware of the files on one's hard
disk- "Be in touch with your hard drive."
ANDY HOPKINS: Mr. Hopkins told how the popular Trojan Horse and virus detctor
programs CHK4BOMB and BOMBSQAD were both unauthorized releases of software
developed by Panda Systems. Some versions of these programs, he warns, have
been modified and made into destructive programs. He explained how the Doctor
Panda Utilities ultilize the methods similar to the two programs, but with
additional features. The Utilities have a three-part approach-
- PHYSICAL which creates a "clean model" of the computer system and uses the
"model" to check for abnormal alterations of systems files and any other files
specified by the user.
- LABTEST which reads a specified file, checks for commands bypassing DOS, and
displays any embedded ASCII characters.
- MONITOR which loads into the memory and monitors for specified types of disk
activity, stopping the system if any are encountered.
CONCLUSION
From the presentations and the discussions, one could glean much
information about computer viruses. While the speakers agreed that nobody can
be sure about the future, they agreed that computerists are reasonably safe if
they take reasonable precautions. The seminar was well worth the time and
effort to get there.
As I am writing the finish to this article, I am reminded of a concern
expressed by many of the panelists. They were alarmed by the irresponsible
computer journalists who have gone beyond informing the public about the
viruses by giving "how-to" guides for writing viruses. It is a phenomenon that
is especially prevalent in the MacIntosh field. (Perhaps because it appears to
be easier to write a MacIntosh virus than a MSDOS one.) This is valid one,
since it is important to inform computerists but there is no need to give
aspiring virus writers their start.
------------------------------------------------------------------------
= Kenneth R. van Wyk = _ /| =
= User Services Senior Consultant = Ack Thippfft! \'o.O` =
= Lehigh University Computing Center = =(___)= =
= Internet: <[email protected]> = U =
= BITNET: <LUKEN@LEHIIBM1> = Bill 'n Opus in '88! =
------------------------------------------------------------------------
=========================================================================
Date: Fri, 6 May 88 08:24:05 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Jim Frost <[email protected]>
Subject: Re: The Shockwave Rider.
|As a "literary" note on viruses [...]
Intrepid readers might like the book "P1" which is probably the first
book dealing withh the topic ofviruses/worms. I've also read
"Valentina" but the former is much better.
Now back to your regularly scheduled virus reports....
jim frost
[email protected]
=========================================================================
Date: Fri, 6 May 88 08:32:11 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Jim Frost <[email protected]>
Subject: Re: Virus Construction Set
|bad news from Germany. I have forgotten to tell you something in my
|last message: Not all people concerned with computer viruses (esp.
|virus programmers) over here are aware of what they are doing. In April
|this year a unbelievable program called "VIRUS CONSTRUCTION SET (VCS)"
|was released at the Hannover computer faire CeBIT.
I don't know about in Germany, but it's my bet that anyone releasing
such a beast in the United States would get a handful of lawsuits.
I'd be in on sueing the hell out of them!
What would prompt someone to write such a damaging "utility"?
jim frost
[email protected]
=========================================================================
Date: Fri, 6 May 88 09:37:19 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject: files
A couple people have made some great suggestions for improving
the uuencoding/uudecoding process here on VIRUS-L. So, I've
included a BASIC version of uudecode (filename UUDECODE BAS) as
well as a new improved uuencode/uudecode package called uu213
(filename UU213 UUE). The BASIC uudecoder will work with any
GW-BASIC compatible BASIC interpreter...slowly. It is *not*
...er...shall I say, fast. But, for those of you who don't have
Turbo Pascal, you can get the BASIC uudecoder, and the UU213
package. UU213, by the way, is a uuencoded ARC file containing
a very fast uuencode and uudecode in executable form. Both of
these files were obtained from the MS-DOS archives on SIMTEL20.ARPA.
Thanks to all who sent in these suggestions and files! Hopefully,
this will be the uuencode/uudecode to end all uuencode/uudecode's. :-)
Ken
------------------------------------------------------------------------
= Kenneth R. van Wyk = _ /| =
= User Services Senior Consultant = Ack Thippfft! \'o.O` =
= Lehigh University Computing Center = =(___)= =
= Internet: <[email protected]> = U =
= BITNET: <LUKEN@LEHIIBM1> = Bill 'n Opus in '88! =
------------------------------------------------------------------------
=========================================================================
Date: Fri, 6 May 88 14:12:40 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: OJA@NCCIBM1
One of the things mentioned in the discussions during the
La Salle virus seminar was the existence of malicious program that
would rewrite or erase firmware but rapid reads and writes which
would heat up the EPROMs and erase them. I haven't heard of this
before so I am putting out for comments, etc.
The only form of hardward damage from a malicious program that I know of
is an old Trojan Horse for the early Commodore PETs. It would burn out
their monitors if allowed to run for a while. Just a quirk of the
beastie.
J. D. Abolins
=========================================================================
Date: Fri, 6 May 88 13:59:00 EST
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Mitchel Ludwig <[email protected]>
Subject: RE: Re: Virus Construction Set
>|bad news from Germany. I have forgotten to tell you something in my
>|last message: Not all people concerned with computer viruses (esp.
>|virus programmers) over here are aware of what they are doing. In April
>|this year a unbelievable program called "VIRUS CONSTRUCTION SET (VCS)"
>|was released at the Hannover computer faire CeBIT.
>
>I don't know about in Germany, but it's my bet that anyone releasing
>such a beast in the United States would get a handful of lawsuits.
>I'd be in on sueing the hell out of them!
>
>What would prompt someone to write such a damaging "utility"?
Jim,
Not that you (or anyone for that matter) will want to hear
this, but chances are good that anyone wishing to market such a
program in the U.S. will have no problem doing so. It's probably
comparable to those selling the copy boards and such which would seem
to be in direct violation of the shrink wrap laws (are those the
correct laws?)
Unfortunately, as I see it, the free speech laws (of the
press... etc) allow such programs to be sold... We don't have to like
it... But we do have to deal with it...
Mitch
Tag... You're it
____________ ____/--\____ //-n-\\
\______ ___) ( _ ____) _____---=======---_____
__\ \____/ / `--' ====____\ /.. ..\ /____====
) `|=(- - - - - - - - - - -*// ---\__O__/--- \\
\------------' \_\ /_/
BITnet : [email protected] Phonet : 215-758-1381
INTnet : [email protected] Slonet : Box 72 Lehigh Univ.
Bethlehem, PA 18015
=========================================================================
Date: Fri, 6 May 88 13:30:00 CDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: GREENY <MISS026@ECNCDC>
Subject: re: hardware damage
> The only form of hardward [sic] damage from a malicious program that I know of
> is an old Trojan Horse for the early Commodore PETs...
Hmmm....I seem to remember a program for the Commodore VIC 20's that would
fry out a ROM or two. Also the old tale from the days of core memory, of
a nutty programmer that continually accessed a location in memory until the
core that represented this memory location heated up. The core was directly
over an overheat sensor. When the core got hot enuf, the sensor tripped, and
the machine shut down. Good thing we don't use core memory anymore!
Bye for now but not for long...
Greeny
Bitnet: MISS026@ECNCDC
Internet: MISS026%[email protected]
Disclaimer: What?? Who? Me? Nope...not me! It's that guy over there!
=========================================================================
Date: Fri, 6 May 88 14:28:03 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Jim Frost <[email protected]>
Subject: Re:
|The only form of hardward damage from a malicious program that I know of
| is an old Trojan Horse for the early Commodore PETs. It would burn out
|their monitors if allowed to run for a while.
Another such problem exists with the old monochrome boards for PC's.
I haven't heard of any trojan horses/viruses which take advantage of
it, but it exists.
jim
=========================================================================
Date: Fri, 6 May 88 14:39:22 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Jim Frost <[email protected]>
Subject: RE: Re: Virus Construction Set
|>What would prompt someone to write such a damaging "utility"?
| Not that you (or anyone for that matter) will want to hear
|this, but chances are good that anyone wishing to market such a
|program in the U.S. will have no problem doing so. It's probably
|comparable to those selling the copy boards and such which would seem
|to be in direct violation of the shrink wrap laws (are those the
|correct laws?)
It's not the same thing. You have a right to archive programs for
your own use, which is why the copy people haven't been knocked out of
business. Copying something does no harm to another person, unless
it's illegal copying and there are laws against that. A virus
can (is supposed to?) cause harm. The question isn't whether or not
someone can be sued for it, but rather who gets sued. Should it be
the person that sent out the virus, or should it be the company that
made the virus creation program? In any case, the company has aided
in the crime and may be at fault (although it might be possible to use
a "people kill with guns but gun companies aren't held responsible"
argument to get around this).
I guess we'll never know until it happens.
jim
=========================================================================
Date: Fri, 6 May 88 14:52:38 edt
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Travis Lee Winfrey <[email protected]>
In-Reply-To: OJA%[email protected]'s message of Fri,
6 May 88 14:12:40 EDT <[email protected]>
Hi all; I'm new to this list. A few questions which may have been answered
before:
Is there a list anywhere of known viruses, malicious or otherwise? or of
hardware/software combinations for which virus programs exist?
Also, is there a list of antibody- and immunization-type programs, including
those like chk4bomb that have been tampered with and re-released? it would be
useful to have checksums published with these programs, although I suppose a
virus writer wouldn't be too troubled to make a checksum balance out. perhaps
multiple checksums could be used to foil simple padding.
based on what has been discovered so far, does anyone have any feel for the
percentages of malicious vs. nonmalicious/humorous/political viruses out
there?
can anyone recommend a beginning text on epidemiological analysis? :-), but I
would really be interested in such a book.
t
=========================================================================
Date: Fri, 6 May 88 14:56:50 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
In-Reply-To: Message of Fri,
6 May 88 14:52:38 edt from <[email protected]>
>Is there a list anywhere of known viruses, malicious or otherwise? or of
>hardware/software combinations for which virus programs exist?
Wouldn't be too bad to start with DIRTY DOZEN, available here on VIRUS-L.
It seems to be *reasonably* thorough. If you don't know how to get files
from here, e-mail me directly and I'll let you know.
Ken
------------------------------------------------------------------------
= Kenneth R. van Wyk = _ /| =
= User Services Senior Consultant = Ack Thippfft! \'o.O` =
= Lehigh University Computing Center = =(___)= =
= Internet: <[email protected]> = U =
= BITNET: <LUKEN@LEHIIBM1> = Bill 'n Opus in '88! =
------------------------------------------------------------------------
=========================================================================
Date: Fri, 6 May 88 13:10:00 CST
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: LOWEY@SASK
Subject: How can we protect programs from viruses?
Hi,
I have written a number of utilities and programs which I put into the
public domain. Usually they are written in Turbo Pascal, and the
source code is distributed as well.
One thought I had was include a CRC check in the program. Randomly
throughout the code, the program would do a CRC check on its .EXE or
.COM file (or optionally the executing image). If it didn't pass the
test, then it would display a message that the program was tampered
with and exit. I think Lotus 1-2-3 does this as part of its copy
protection scheme.
If something like this was added to the MS-DOS utilities and public
domain programs, it could stop the spread of some viruses. For
instance, if COMMAND.COM had such a check, it would be much harder for
a hacker to patch a virus into it.
Does anyone know of any method that protects your programs even if
the hacker knows the method used to do the protection? In otherwords,
a hacker can know how it was done, but not how to defeat it?
Thanks,
Kevin Lowey -- University of Saskatchewan Computing Services
=========================================================================
Date: Fri, 6 May 88 19:38:00 MDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
Comments: Warning -- original Sender: tag was [email protected]
From: Keith Petersen <[email protected]>
Subject: Flushot-Plus version 1.2 now available from SIMTEL20
The latest version of FLUSHOT, the anti-Virus/anti-Trojan program for
MSDOS, is available via standard anonymous FTP from SIMTEL20 as...
Filename Type Bytes CRC
Directory PD1:<MSDOS.TROJAN-PRO>
FSP_12.ARC.1 BINARY 45646 2AD5H
This is Flushot-Plus, version 1.2. It was obtained directly from the
author, Ross Greenberg, to assure its validity.
--Keith Petersen
Maintainer of the MSDOS archives at SIMTEL20.ARPA
=========================================================================
Date: Mon, 9 May 88 16:05:00 CET
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Karl-L. Noell" <NOELL@DWIFH1>
Subject: hunting up infected files
Now we have come to the point where it's even possible to infect files
without altering their size or their time date stamps. So I'd like to
recall the well known, efficient and approved cyclic redundancy check
(CRC). It should be good practice, to compute the CRC remainder every
week for all files on harddisk drives.
For this purpose I'm using the very helpful tool FILECRC written by
Ted H. Emigh. It's in SIMTEL20 / RPICICGE <MSDOS.FILUTL>FILECRC.ARC .
Running FILECRC computes the individual checksums and leads over to
compare them with the CRCs obtained from the previous run. This will
uncover all files which have been altered since the last run, especially
those modified in a 'non-DOS-manner'. And all *new* files are shown,
revealing unwanted descendants born by trojanic creatures or hatched
out of any cuckoo egg.
Karl Noell
fhw (Wiesbaden, W.Germany)
=========================================================================
Date: Mon, 9 May 88 10:52:00 EST
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Jerry Leichter ([email protected])" <LEICHTER@YALEVMS>
Subject: CRC's for detecting viruses
Unfortunately, it is very easy to modify a file so that any given CRC remains
unaltered. The protection you get by using a CRC is thus quite limited - it
stops those virus-writers who aren't clever enough to work around it.
Stepping back a bit and looking at the bigger picture: Given a program P,
viewed as a bitstring (or a very large number or a polynomial over Z mod 2 or
whatever is convenient), we want to compute a signature S(P) which is (a) fairly
small; (b) chosen so that it is "highly likely" that, if Q != P, S(Q) != S(P).
An example of a simple signature function is "number of bits (bytes, blocks)
in P" - the size of the file. This simple function also points out the weak-
ness that a given S may have: "Highly likely" must refer to a given set of
ways of chosing Q != P. Virus makers at first did not go out of their way to
chose Q's the same size as P, so this S worked fine. Now they know better, and
this S is useless.
There are many other possible S functions: Sum of the bytes of P, XOR of P
viewed as a vector of 16-bit words, various weighted sums (given by something
like S[0] = 0; S[i+1] = k*S[i] + P[i], where P[i] is the i'th byte/word of P
and S = S[size(P)]), and so on. CRC is yet another possibility. All these
choices of S have uses given particular ways of chosing Q. CRC is good if Q
is what comes out after sending P over a noisy telephone line - the kinds of
changes that that process induces to form Q from P are "highly likely" (in a
very precise sense) to change the CRC. However, when you are talking about a
change due to an intelligent opponent, the story is very different.
There exist "cryptographically strong" S functions, in the sense that, given
P and S(P), it is "very difficult" - as hard as breaking some code - to find
ANY Q != P with S(Q) = S(P). DES, the Data Encryption Standard, provides a
mode of use, called CKS (checksum) mode, in which you chose a secret key K,
then compute S(P) = DES_CKS(P,K). This is cryptographically strong - it is
as hard to break as DES itself. Unfortunately, it requires that K be kept
secret - given K, it is no more secure than, say, XOR. What this means is
that an individual can chose a secret K and use this technique to checksum
his own files - but there is no way to publish a list of (P,S(P)) values that
would do anyone any good in determining whether a program they received was
intact, since to test it they would need to know K - and then the bad guys would
know K, too.
DES requires fairly slow computation. It turns out that CRC CAN be used this
way, if you chose a random, secret CRC polynomial. There's a paper by Michael
Rabin called "Fingerprinting by Random Polynomials" - sorry, I don't have a
handy reference - that shows how to do this, and proves that the result is
cryptographically strong - as long as the polynomial is kept secret.
It is also possible to construct cryptographically strong signatures that do
NOT require that a secret be kept. These are essentially one-way functions
that are thought, for good reason, to be hard to invert. It isn't hard to
build one of these using DES, or any good encryption function. Unfortunately,
they tend to require a LOT of slow computation - what happens is that pieces of
P get fed in to the encryption function, not as data, but as keys. Encryption
algorithms are designed for reasonable implementation for a FIXED key and
VARIABLE data - changing the key all the time is hard, since fast implementa-
tions usually rely on munging on the key for a while to set things up just
right. (BTW, the security of such schemes comes from the difficulty, in a
good encryption system, of learning the key, even given a lot of plaintext/
ciphertext pairs.)
I would suggest a compromise: A mechanism that, while not completely secure,
makes things very hard on a virus-maker while not requiring huge amounts of
computation. When a program is published, a large number of random polynomials
(say, 100 or 1000) are chosen, using the techniques of Rabin's paper. The CRC
of the program with ALL the polynomials is published. To check a program, you
chose any two of the polynomials - also published - compute the CRC's, and
compare. (You must, of course, chose those two at random.) The virus maker
must make his program have the same CRC with respect to ALL the 100 or 1000
polynomials - which is possible, but requires (I believe, this would need to be
studied) a LOT of computation. (The length should probably be checked - it's
going to be a lot easier on the virus maker if he can add extra stuff to the
end of the program to make the CRC's come out right.)
-- Jerry
=========================================================================
Date: Mon, 9 May 88 12:50:00 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Atul Butte <ST602397@BROWNVM>
Subject: Preventing public domain software contamination
With all the problems with virus infected public domain and shareware
software, I propose the following solution (for the Macintosh):
There exists a shareware program called StuffIt 1.4 which was designed
to group multiple files into one file which can then be uploaded.
StuffIt 1.4 is for the Macintosh, and is turning into a sort of standard
for packing. StuffIt 1.4, in addition to grouping files can compress
them and can encrypt them.
The proposal:
How about adding a new feature to StuffIt that encrypts files, but in
such a way that they can only be decrypted and not encrypted again? This
can be done with the following method. StuffIt could prompt the
uploading user to enter an encrypting code which is used to encrypt the
files. Along with the files, another code is included. This code is the
decrypting code, which downloading users can use to decrypt the file.
The decrypting code could be hashed by some secret function into the
original encrypting code. This method is similar to the "trapdoor"
functions used for Public-Key Cryptosystems with one-way functions.
The advantage of this is that the original author of a program can
encrypt his or her software and place it in the public domain without
the fear of others downloading the file, contaminating it with a virus,
and then uploading the file as the original.
Atul Butte /----------\ /----------\
Brown University ! OK ! ! CANCEL !
[email protected] \----------/ \----------/
=========================================================================
Date: Mon, 9 May 88 13:31:33 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject: file confusion
There appears to be quite some confusion as to how to get files
from the VIRUS-L archives - I've gotten a *lot* of requests to
better explain myself.
Everyone on this list subscribed to the list by sending a message
to LISTSERV@LEHIIBM1 stating SUB VIRUS-L your name. Well, retrieving
files is very similar to this. Specifically, you will once again be
sending a message to LISTSERV@LEHIIBM1, but instead of SUBscribing,
you will be GETting a specific file. So, to get a particular file,
like DIRTY DOZEN, send mail to LISTSERV@LEHIIBM1 containing:
GET DIRTY DOZEN VIRUS-L
That's all. You'll get the file DIRTY DOZEN in your mail shortly
afterwards. If you want to *see* what files are available, send
INDEX VIRUS-L
Also to LISTSERV@LEHIIBM1.
Care should be taken to *NOT* send the message to VIRUS-L@LEHIIBM1 since
it will go out to the entire list and not reflect favorably upon
yourself... :-)
Hope this clears things up. Sorry for the repetition to those who already
know all about this.
Ken
------------------------------------------------------------------------
= Kenneth R. van Wyk = _ /| =
= User Services Senior Consultant = Ack Thippfft! \'o.O` =
= Lehigh University Computing Center = =(___)= =
= Internet: <[email protected]> = U =
= BITNET: <LUKEN@LEHIIBM1> = Bill 'n Opus in '88! =
------------------------------------------------------------------------
=========================================================================
Date: Mon, 9 May 88 17:19:52 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Jim <15360JIM@MSU>
Subject: Request FSP_12.ARC.1 (Newest Flushot-Plus Program)
I tried to get a lastest copy of fsp_12.arc.1 I read a message that
I can get a clear copy from simtel20.arpa. But I don't know how to access
to simtel20.arpa directly. By the way, I checked listserv at rpicicge and
couldn't find any fsp_12.arc.1 there. Please help me out!
=========================================================================
Date: Mon, 9 May 88 17:30:34 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: OJA@NCCIBM1
In-Reply-To: Travis Lee Winfrey's message of 6 May 88
Regarding the inquiry of a list of known viruses, malicious,
or otherwise.... first check the dirty dozen listing available
as a file from VIRUS-L. In a few weeks or earlier, I can get a
quick amalgam of couple of articles listing many of the viruses.
In a month or so, I hope to make a "VIRLOG" patterned after the
"dirty dozen" listings. It will be helpful but I can't gaurantee it
will 100% comprehensive. But I will be seeking to compile whatever
info I get here, from RISKS, and elsewhere that can be published.
With that listing will be a list of anti-virus/bomb programs.
BOMBSQAD and CHK4BOMB have been mentioned. On the files areas,
there are several good programs. As for tampered programs, well...
it is hard to keep up with that. However, I can warn you about
FLUSHOT4. It is a tampered version; that is why Ross Greenberg
calls his program FLUSHOT+ or (FSP). But the DOS REName command
makes tracking these nasties impossible. Whatever the name of the
FLUSHOT type program, watch for ones with executable text files
(ie.; COM or EXE files to run so the documentation will be
displayed.) Ross Greenberg uses ASCII files for the documentation.
Other than that and the suspect NOTROJ program (another story in
itself), I don't know of other tampered "cures".
Regarding books, I have heard of a "Hacker's Manual" but I haven't
seen it. There is no major book yet that I know of which deals
specifically and in detail about malicious programs.
J.D. Abolins
=========================================================================
Date: Mon, 9 May 88 18:25:27 edt
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Travis Lee Winfrey <[email protected]>
In-Reply-To: OJA%[email protected]'s message of Mon,
9 May 88 17:30:34 EDT <[email protected]>
Regarding books, I have heard of a "Hacker's Manual" but I haven't
seen it. There is no major book yet that I know of which deals
specifically and in detail about malicious programs.
yes, I've seen the hacker's manual at a bookstore nearby. it pre-dates
viruses, and is more for breaking into computers over networks or dialup lines.
it was surprisingly accurate, listing for each os: the login procedure, how to
find out user ids, what the privileged ids are (root, system, operator). I
didn't see any lists of security bugs, but I was just glancing through it.
there was also a lot of phone-phreaking information in it. the techniques are
mostly for game-seeking kids playing around with modems, but they do good job
of stripping away any security-by-ignorance schemes.
t
=========================================================================
Date: Mon, 9 May 88 15:40:00 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Joseph M. Beckman" <[email protected]>
Subject: Re: hunting up infected files
In-Reply-To: Message of 9 May 88 11:05 EDT from "Karl-L. Noell"
As an employee of the National Computer Security Center, I must point
out that we do *NOT* attempt to track perpetrators for prosecution or
for *ANY* other reason!
We are not a law enforcement Agency, and are prohibited by law to take
any such action.
We are interested in tracking the viruses (or ordinary Trojan Horses) as
they infect different sites.
As a matter of professional interest, I would be curious as to the
motivations of perpetrators of malicious code, or whether they are
members of "Hacker Clubs;" but that is information that may be conveyed
without identifying the people/organizations involved.
Joseph
=========================================================================
Date: Tue, 10 May 88 11:35:32 edt
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Travis Lee Winfrey <[email protected]>
From: LOWEY%[email protected]
Subject: How can we protect programs from viruses?
If something like this was added to the MS-DOS utilities and public
domain programs, it could stop the spread of some viruses. For
instance, if COMMAND.COM had such a check, it would be much harder for
a hacker to patch a virus into it.
yes, but as with all checks built in to programs, if the test(s) can be found
in the code, executable or source, it can be patched and circumvented.
however, such checks would be very useful in slowing the spread of a virus.
t
=========================================================================
Date: Tue, 10 May 88 17:41:00 LCL
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Michael Wagner new! +49 228 8199645 <WAGNER@DBNGMD21>
Subject: Re: Virus Construction Set
> I don't know about in Germany, but it's my bet that anyone
> releasing such a beast in the United States would get a handful of
> lawsuits. I'd be in on sueing the hell out of them!
You'd have a hard time even finding a ground. The fact that a
crowbar can be used for burglary doesn't make it illegal to make
crowbars. Similarly, selling copy protection defeaters isn't
illegal nor key making machines. So it isn't per se illegal
In terms of suing, you'd have to show that the manufacturer made
something so unsafe that the owner of the program could not handle
it safely. I don't know how you'd go about doing that. So suing
the manufacturer is likely to be unprofitable.
There are certain tools, the mere possession of which is a crime.
The law justifies this by saying that there is no legitimate use
for the tool, only the illegal one. However, I think these must
be explicitely listed, and I bet virus makers aren't on the list
Perhaps you could them added.
Michael
=========================================================================
Date: Tue, 10 May 88 17:19:00 LCL
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Michael Wagner new! +49 228 8199645 <WAGNER@DBNGMD21>
Subject: Re: Virus Construction Set
> bad news from Germany. ... In April this year a unbelievable
> program called "VIRUS CONSTRUCTION SET (VCS)" was released at the
> Hannover computer faire CeBIT.
Actually, at least on a certain philosophical plane, I see this as
a good thing. I have grown sick and tired of hearing, for most of
the past decade, that security exposures are 'no problem' because
no one except a real expert will be able to find them, let alone
exploit them. "No one will discover that back door and so we are
safe". This innocent, cute approach to a real problem is really a
disservice to the community.
Babies are innocent and naive. They start out their lives shoving
anything that fits in their mouth into their mouth. They have to
be taught to only put food into their mouths, and to accept food
only from trustable sources. If not, they can get very sick, and
perhaps die.
Basically, for the last few years, we computer people been living
in a dream world. It seems that we, as adults, still have to
learn that, just because something fits, you don't *have* to try
sticking it in (we can skip the obvious sexual parallels) and
doing so might just be dangerous.
If VCS does nothing else, it will demonstrate:
> You dont have no know how a virus work to create one, you just
> have to know how to turn on your Atari and how to start the VCS
> program!!!
Maybe, as a result, manufacturers (hardware and software) will no
longer be able to rely on the principle that complexity and
secrecy are adequate protection. When the consumer population
understands the implications of 'toys' like VCS, even little kids
will laugh at manufacturers who are silly enough to continue to
tell their consumers such nonsense.
Michael
=========================================================================
Date: Tue, 10 May 88 12:47:26 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Jim Frost <[email protected]>
Subject: software self-checks
| If something like [a self-integrity check] was added to the
| MS-DOS utilities and public domain programs, it could stop the
| spread of some viruses. For instance, if COMMAND.COM had such a
| check, it would be much harder for a hacker to patch a virus into
| it.
|
|yes, but as with all checks built in to programs, if the test(s) can be found
|in the code, executable or source, it can be patched and circumvented.
|however, such checks would be very useful in slowing the spread of a virus.
A couple of comments to this. Yes, it'd slow the spread of viruses,
but it would also make you less paranoid about them (and thus less
likely to catch them), make viruses more likely to be obnoxious (what
kind of person would spend the time to work around the protections?),
and slow the system down as well.
This is a classic argument about security. The advent of a "secure"
system will make users forget about security. When security is
breached, the breach may never be found because no one is looking for
it.
Also, a word about intermittent security. Users of the PClone utility
FLUSHOT (or its relatives) should be aware that just because a program
doesn't do anything while you're running with protection doesn't mean
it won't while you're not. It is trivial to add code to check to see
if the FLUSHOT program is resident in your machine and just sit there
if it is, but wreck things if it is not. Just when you trust a
program enough to not use the protection, you'll get burned.
jim frost
[email protected]
=========================================================================
Date: Tue, 10 May 88 13:32:08 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject: Checkup available on VIRUS-L
The Checkup program is now available on VIRUS-L. It is a shareware
checksum program to aid in determining whether or not a file (or
files) has been altered. The filename is CHKUP14 UUE. It's a
uuencoded ARC file.
A caveat on this program, as with all the programs on VIRUS-L -
they're public domain (or shareware), and you get what you pay for.
...which isn't to say that they're without merit. I have run all
of the programs that I've posted, and I have obtained them from
reliable sources (SIMTEL20.ARPA for the most part).
Regards,
Ken
------------------------------------------------------------------------
= Kenneth R. van Wyk = _ /| =
= User Services Senior Consultant = Ack Thippfft! \'o.O` =
= Lehigh University Computing Center = =(___)= =
= Internet: <[email protected]> = U =
= BITNET: <LUKEN@LEHIIBM1> = Bill 'n Opus in '88! =
------------------------------------------------------------------------
=========================================================================
Date: Wed, 11 May 88 09:48:55 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject: christmas exec details
Here are some details about the IBM "Christmas Exec" virus that was
floating around the network world right around Christmas 1987.
These were forwarded to me by a reader:
Date: 10 May 1988, 13:09:54 +0200 (MESZ)
From: Otto Stolz +49 7531 88 2645 RZOTTO at DKNKURZ1
Subject: DIRTY DOZEN (Issue #8: February 21, 1988)
> ????????.??? ?????? V There is a virus that was circulating
> around Bitnet in December that advertises
I can give you some details on this network-virus:
It's name was CHRISTMA EXEC . I forgot its file size, and have kept no
log of it.
It consisted of a single program in the REXX language, which has been
available in the VM/SP operating system (for IBM mainframes) since
Release 3. (The REXX language is also available under MS-DOS for
IBM-PC, -XT, and -AT, and it is announced for the mainframe operating
system MVS/TSO-E; but for reasons given below, I reckon the virus could
reproduce itself only under VM/SP.)
The source of CHRISTMA EXEC (with REXX, there isn't anything as an object
code file) started with a lore of say-instructions, that apparently would
display a sketch of a Christmas-tree together with some good wishes on
the screen. This bunch of (in fact rather boring) statements filled one
and a half screens; it was followed by a half-screen-sized comment,
stating roughly "Reading source-code like this is boring, rather RECEIVE
this program, and just enter CHRISTMA" (the latter CMS command would
have started the program).
When you actually started the thing (I didn't do it, but people told me),
the program indeed displayed a Christmas-Tree and best wishes for the
year to come. Then it read two files, CMS (part of VM/SP) maintains on
behalf of every user.
The first one is called <userid> NETLOG, and contains a log of network
traffic the user has been involved in. Here is a sample entry of my
personal RZOTTO NETLOG file ("disc" meaning "discarded", and "from"
pointing to the sender's address):
File CHRISTMA EXEC A1 disc from RZBERAT1 at DKNKURZ1 on 12/16/87 14:34:44
sent as CHRISTMA EXEC A1
The NETLOG file contains similar entries for notes and files having been
sent by the respective user (me, in the example).
The second one is called <userid> NAMES and contains sort of private
directory of people you are in correspondence with. Here are four
sample entries of my private RZOTTO NAMES file:
:nick.VIRUS-L :userid.VIRUS-L :node.LEHIIBM1 :notebook.VIRUS-L
:name.Virus Discussion List
:nick.VIRUS :name. Owners of VIRUS-L :notebook. VIRUS-L
:list. KenVWyk Eshleman
:nick.KenVWyk :userid.LUKEN :node.LEHIIBM1 :name.Ken Van Wyk
:nick.Eshleman :userid.LUJCE :node.LEHIIBM1 :name.Jim Eshleman
CHRISMA EXEC extracted all network addresses from these two files, and
sent a copy of itself to every of these addresses except the address,
from where it came to the current user (thus avoiding the ping-pong
effect). The poor victim's very next experience: he received replies
from thousands of BITNET nodes, telling him where the hundreds of
CHRISTMA copies went.
At last, CHRISTMA EXEC destroyed its own source on the user's disk.
As CHRISTMA EXEC relied on one of the two special CMS files, it probably
could reproduce itself only in VM/SP systems (I don't know, how net-
working is implemented under TSO or under MS-DOS). Furthermore, it
depended on active help of the user being "infected" to reproduce itself:
he had to enter two commands, RECEIVE and CHRISTMA. This active help was
provoked by an appeal on peoples curiousity and playfulness.
In spite of these two handicaps, CHRISTMA EXEC spread within two days,
worldwide. The effect was enhanced, as some copies went to BITNET
discussion lists, where they automatically were duplicated and distribu-
ted as any sensible contribution will be. If I remember correctly (and
if I can trust rumours), it originated (as a student's joke) somewhere in
Germany, went through USA, and came back to our blessed country from the
far east. It's severest effect was obstructing the whole network with
thousands of copies of itself.
The cure was very simple: every node had to run a quickly developped
program that purged every file of name CHRISTMA EXEC from the node's
spooling area, the only difficulty being the distribution of this
"macrophage" program through the helplessly overloaded network. Even
without this cure, CHRISTMA would probably be extinct by now, as any user
seeing it for the second time would have discarded the file, remembering
the traumatic experience of the first time, when he started that thing.
Thus by now, BITNET is probably "immune" to this virus.
The moral of the story:
1. read and understand programs you receive without having asked for,
before you run them.
2. Think about the possible results before starting a practical joke.
Best regards
Otto.
------------------------------------------------------------------------
= Kenneth R. van Wyk = =
= User Services Senior Consultant = Badgers! We don't need =
= Lehigh University Computing Center = no stinkin badgers! =
= Internet: <[email protected]> = =
= BITNET: <LUKEN@LEHIIBM1> = =
------------------------------------------------------------------------
=========================================================================
Date: Wed, 11 May 88 10:25:27 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "David A. Bader" <DAB3@LEHIGH>
I have a question dealing with PKX35A35 and a virus/trojan associated
with it.
In the issue #8A of the Dirty Dozen by Eric Newhouse (available from
this list) dated 2-21-88, Eric writes "As of this writing, Phil Katz
(author of PKXARC) has verified that version 35A35 is the latest
version of his ARChive extractor. This phony PKXARC scrambles FAT
tables." (Refering to a suspected Trojan Horse: PKX35B35.EXE)
Anyway, through local BBS's, I attained a BugFix archive called PK35BUG,
complete with documentation supposedly written by Phil Katz,
that supposedly fixes a bug in PKX35A35.EXE for "large binary files."
The files in this archive are dated 9-22-87 through 9-27-87.
I have heard through the grapevine that this BugFix will spread a
virus, through archives, and also that it is legitimate, but still, no
one has given me a consistent answer. I tried to contact Phil Katz
through US Mail, Bitnet, and BBS's, but never got a response. Is this
BugFix his, or not? (I have a copy of it, if anyone wishes to see it.
The fix is about 3K.)
Also, why would Phil Katz tell Eric Newhouse that 35A35 is the latest
version, if he had released a BugFix, and why would Phil Katz release a
BugFix, instead of releasing a whole new version to alleviate these
problems?
Any comments are welcome!
-David Bader
=========================================================================
Date: Wed, 11 May 88 09:20:00 CST
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: LOWEY@SASK
Subject: PKARC bug, it is a valid patch
> I have a question dealing with PKX35A35 and a virus/trojan associated
> with it.
> Anyway, through local BBS's, I attained a BugFix archive called PK35BUG,
> complete with documentation supposedly written by Phil Katz,
> that supposedly fixes a bug in PKX35A35.EXE for "large binary files."
> The files in this archive are dated 9-22-87 through 9-27-87.
There was an official bug fix for PKARC. The problem was that when
files were SQUASHED, and started with a certain character (CHR(0) I
think) then it would not be unarchived. I tested this and the bug
existed. I applied the patch I got from uucp, and the bug
disappeared. I have had no problems with trojan horses arising from
it.
However, this official bug had nothing to do with "large binary
files". It is possible someone else has released a different "bug
fix" which is in fact a trojan horse.
> Also, why would Phil Katz tell Eric Newhouse that 35A35 is the latest
> version, if he had released a BugFix, and why would Phil Katz release a
> BugFix, instead of releasing a whole new version to alleviate these
> problems?
The bug it was fixing was very very minor. Perhaps one in 1000
archives would have the problem. I agree that he should have changed
the version number, but he didn't.
Kevin Lowey -- University of Saskatchewan Computing Services
=========================================================================
Date: Wed, 11 May 88 17:39:00 LCL
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Michael Wagner +49 228 8199645 <WAGNER@DBNGMD21>
Subject: Re: software self-checks
> |however, such checks would be very useful in slowing the spread of a virus.
>
> A couple of comments to this. Yes, it'd slow the spread of
> viruses, but it would also make you less paranoid about them (and
> thus less likely to catch them),
----
I assume this should have been MORE likely to catch them?
> make viruses more likely to be obnoxious
Some people advocate make-shift virus protection, i.e. protection
that is only one step ahead of the virus itself, and works by
exploiting very particular properties of the virus. When virus
protection only stops up one hole of many, it usually serves to
produce a virus strain that circumvents the one plugged-up hole.
This is what happened when people tried to patch MVT to make it
'more secure'. It was like the little dutch boy putting his
finger in one hole in a sponge. The water just went around his
'secure hole'.
Not all virus protection need be so make-shift.
MVS was built with security as a basic design criteria, and the
sponge is considerably less porous. Our experience at the
University of Toronto (where I used to work) was that most
infiltrations were done as a pasttime, to show that it could be
done, and to show off to friends. If you make this too much
work, you cut 99% or more of the perpetrators dead in their
tracks.
This is not to say that MVS is totally secure. Similarly, my
house isn't entirely burglarproof. But you do have to have a
strong motivation to work hard enough to break in. I don't store
enough (in either place) to justify anyone working that hard to
break in (and I don't put on airs like I do, either). Otherwise,
I would worry.
> (what kind of person would spend the time to work around the
> protections?),
Rather like the gun control arguments, the real criminals will
always have guns, whether you attempt to control them or not.
However, 99% of the viruses currently circulating are created by
idle minds, and not by real criminals.
> and slow the system down as well.
This is a relatively weak argument. It runs faster with security
controls enabled than it does when it isn't running at all.
Besides, security that is 'architected in' rather than strapped on
later shouldn't cost very much in computing resources.
I like human analogies. If you have to unlock the front door to
your house before you walk in, it slows you down. Have you tried
to optimize your 'house access time' by leaving it unlocked?
> This is a classic argument about security. The advent of a
> "secure" system will make users forget about security.
There is no such thing as a 'secure' system. There are only more
and less secure systems. Therefore, a 'more secure' system
includes facilities to enable the 'security officer' to check if
security has been breached (for most PCs, the owner is also system
manager, purchasing agent and security officer. Thats what he
bought in to. If he didn't want all that responsibility, he
should have bought time on a mainframe where someone else does
that work (and it costs more as a result)).
> When security is breached, the breach may never be found because
> no one is looking for it.
If no one was looking, it was a not-at-all secure system. The
greatest security system in the world is useless if no one is
watching it.
> jim frost [email protected]
Michael Wagner
=========================================================================
Date: Wed, 11 May 88 12:51:41 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Adam Lewis <ALEWIS@UTCVM>
Subject: Re: software self-checks
In-Reply-To: Message of Wed, 11 May 88 17:39:00 LCL from <WAGNER@DBNGMD21>
There is a very good point here about making security such that
it takes some effort on the part of the author of the virus to break it.
This gets rid of the people who do this to "impress" their friends and
neighbors. The problem is that the people who do in fact spend the time
it takes to break security are going to do it in a fashion that is much
more difficult to figure out and are going to be a lot more
sophisticated (i.e. no FORMAT C: in your PC's AUTOEXEC.BAT). It strikes
me as another application of Murphy's 90-10 law.
------------------------------------------------------------------------
Adam Lewis :It could be worse, it
Center of Excellence for Computer Applications: could be Monday.
Univ. of TN, Chattanooga :
------------------------------------------------------------------------
=========================================================================
Date: Thu, 12 May 88 09:15:22 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject: checksum signatures
In looking at the documentation for the Checkup program, I see that
they're using a form of a checksum to validate whether or not a file
has been altered. Now, a smart virus author can easily circumvent
a checksum algorithm by adding dummy characters to the file so that
the checksum comes out to the same value. The Checkup program, however,
maintains that its scheme is impossible to get around by using padding
characters since it calculates the checksum of the entire file as well
as that of randomly sized blocks within the file. It then stores this
data in (I assume) an encrypted format.
This raises an interesting question - is it truly possible to write
a checksum/crc/whatever algorithm that will be able to figure out
whether or not a file has been changed 100% of the time? Let's assume
that the signature data has *not* been tampered with in any way. It
is no secret that both checksums and crcs can be circumvented rather
easily. But, an algorithm which could validate a file with 100%
effectiveness could be very worthwhile looking into. Once again, the
validity of the signature data itself would have to be insured via
encryption and/or read-only isolation.
Comments? Can anyone prove or disprove the claims that the author of
Checkup makes?
Ken
------------------------------------------------------------------------
= Kenneth R. van Wyk = =
= User Services Senior Consultant = Badgers! We don't need =
= Lehigh University Computing Center = no stinkin badgers! =
= Internet: <[email protected]> = =
= BITNET: <LUKEN@LEHIIBM1> = =
------------------------------------------------------------------------
=========================================================================
Date: Thu, 12 May 88 09:36:19 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "David M. Chess" <CHESS@YKTVMV>
Subject: checksum signatures
Well, there's a very simple argument that suggests that no short
(or even medium-sized) checksum or other signature can be 100%
effective in detecting changes to files.
Consider: files are large objects, thousands of bytes long.
Signatures are smaller than that; at most hundreds of bytes
long. When you map a large set into a smaller set, there
must be cases in which two or more things in the larger set
are mapped onto the same thing in the smaller set (that is,
the mapping must be many-to-one); this is just the PigeonHole
principle.
For instance, if you're assigning all files 10,000 bytes or less
a 4-byte checksum, there are 256-to-the-9,996 as many different
files as there are different checksums. So the "average"
checksum will correspond to a very large number of different
files.
Whenever two different files have the same signature, that
signature will not be 100% effective in detecting changes
(since it won't detect one of those two files changing into
the other). But we've just seen that whenever the signature
is smaller than the maximum filesize, at least two different
files will have the same signature.
So (assuming this rather rough argument holds!) no small
signature can be 100% effective. Fortunately, signatures
don't *have* to be 100% effective to be helpful against
viruses. Viruses operate under certain constraints, and
as long as we can make it sufficiently *hard* to "spoof" the
signature, in a sufficiently large number of cases, a
signature-based scheme will detect a useful fraction of
nerfarious file-changes.
Something like that.
DC
Watson Research Center
* Disclaimer: I gave up the idea of majoring in Math sometime
* around Complex Analysis. None of the above is an
* Official Statement of anybody around here.
=========================================================================
Date: Wed, 11 May 88 12:30:00 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Joseph M. Beckman" <[email protected]>
Subject: Sueing
Cliff Stoll has suggested that people sue perpetrators who hack into
machines. He believes that even if these people cannot be prosecuted
sucessfully (under criminal law, for whatever reason(s)), it is still a
good idea to sue for damages (in civil court). He believes that this
would (at a minimum) show people that organizations are serious in going
after these people. Anyone care to sue the Pakistani who loosed the
"Brain" virus?
Joseph
=========================================================================
Date: Thu, 12 May 88 09:18:00 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
Comments: Resent-From: "Joseph M. Beckman" <[email protected]>
Comments: Originally-From: "Joseph M. Beckman" <[email protected]>
From: "Joseph M. Beckman" <[email protected]>
Subject: Re: hunting up infected files
In-Reply-To: Message of 9 May 1988 11:05 edt from Karl-L. Noell
As an employee of the National Computer Security Center, I must point
out that we do *NOT* attempt to track perpetrators for prosecution or
for *ANY* other reason!
We are not a law enforcement Agency, and are prohibited by law to take
any such action.
We are interested in tracking the viruses (or ordinary Trojan Horses) as
they infect different sites.
As a matter of professional interest, I would be curious as to the
motivations of perpetrators of malicious code, or whether they are
members of "Hacker Clubs;" but that is information that may be conveyed
without identifying the people/organizations involved.
Joseph
=========================================================================
Date: Thu, 12 May 88 12:02:24 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "David M. Chess" <CHESS@YKTVMV>
I was shooting off my mouth back in January on an internal conference,
about how it should be relatively easy to write a program that
would detect most simple viruses, and someone said "OK, let's
see it". Being lazy, I responded with pseudo-code. I attach
(a slightly updated version of) that pseudo-code for the benefit
of the community, for comments, etc. The idea is that the system
keeps a big "database" file containing various facts about
executable objects (their time/date/length, and any other
signature-like things one wants to code), and periodically
checks the executables against the database, to see what's
changed. Of course a change doesn't mean an infection (could
be a patch, an update, etc), but it can be a Clue...
The following assumes a PC-DOS base, but could be trivially
changed for CMS, etc.
Build a list of files to be checked (all EXE files, COM files,
BAT files, SYS files, or whatever, on whatever disks).
Attempt to open "old database" file
If open succeeds, read the records describing the files
found last time into the OldRecords structure, and
mark each item in that structure as "Not Seen Yet".
If open fails, alert user that there is no old database, and
ask for permission to continue. Continue only if permission
is given. Set NoOldDatabase to True.
Attempt to open "list of current files to be checked" file
If open succeeds, continue.
If open fails, abort with error message.
For each file listed in "list of current files to be checked" file
(begin
Ask DOS about the file (int21H, subfn 4Eh).
If the file is "special" (COMMAND.COM, IBMBIO.COM, IBMDOS.COM,
whatever else seems reasonable), compute a CRC or other
signature for the file (patient users with fast machines
can treat every file as special, of course).
Look the file up in OldRecords.
If the file was not listed there, add it, marked as "Seen". Tell
the user that it is a new file (unless NoOldDatabase is true).
if the file -was- listed there, and the information is not the
same as the information we just got from DOS, or if the file
is special and the CRC or signature has changed, tell the user
that the file has changed (and how), mark the item as "Seen",
update the item to reflect the current information (from DOS and
the new CRC calculation) and continue.
If the file was listed there, and the information there -is- the
same as the information we just got, simply mark that item
as "Seen", and continue to the next file.
end)
For each item in the OldRecords structure
If the item is marked "Seen", write it out to the "new database" file.
If the item is marked "Not Seen Yet", tell the user it is Gone,
and do not write it to the "new database" file.
So at the end the user has a report of new files, old files that have
vanished, and files that the program could tell had been changed.
If there are unexpected new files, or unexpected changed files,
the user can try to figure out why, which may lead to discovering
a virus.
This is designed with a hard-disk system in mind (for floppies, you'd
have to store something like the diskette label as well, and prompt
the user to swap diskettes alot), and could obviously be improved
in various ways. It can also be used in various ways; if you're
very worried, you can always boot the system from a write-protected
"trusted" disk before using it, and keep the checking program and
the "datbase" on a diskette that resides in a locked file cabinet
except when checking is going on. There is also lots of room for
invention in the "CRC or signature" part of the description. The
development of hard-to-spoof signatures is an active research area.
Now of course (more of courses) there are many possible viruses that
this sort of scheme won't catch. But it will catch (in the sense
that you'll be told about file modifications that you probably didn't
expect) the spread of all the executable-file-based PC-DOS viruses
that I know of.
DC
Watson Research Center
=========================================================================
Date: Thu, 12 May 88 09:47:07 PDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: [email protected]
Subject: Signatures and Checksums
Yes it is true that you can not find a checksum that is 100% unique
as long as the size of the checksum is smaller than the executable. It
is a many-to-one mapping. The trick is to find one that has a small
possibility that two different executables will generate the same
checksum. How "small" depends on you, your system, your needs, etc.
The idea of signing executables for protection from modification is not
a new one. Most recently, I invite you to read "An Approach to
Containing Computer Viruses" published in a 1987 volume of the IFIPs
Computers and Security Journal.
-Maria
=========================================================================
Date: Thu, 12 May 88 11:49:25 CDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Jeff Balvanz <GR.JLB@ISUMVS>
Subject: Is there something funny in the posted CHECKUP?
Just got the CHKUP14 UUE from the VIRUS-L LISTSERV, but I have a
question: when I run the program with
CHECKUP CHECKUP.EXE
Flushot+ comes back with the message "Write access being attempted
on C:\VACCINES\CHECKUP.EXE." Is CHECKUP supposed to try to write on
the executable file that you're reading checksums on? Doesn't make
sense to me. . .but I'm not a good programmer. Is there something
legitimate or illegitimate in CHECKUP, or has my computer been
sitting out in a cold draft too long (i.e., has caught something)?
=========================================================================
Date: Thu, 12 May 88 13:48:02 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject: Re: Is there something funny in the posted CHECKUP?
In-Reply-To: Message of Thu, 12 May 88 11:49:25 CDT from <GR.JLB@ISUMVS>
>Just got the CHKUP14 UUE from the VIRUS-L LISTSERV, but I have a
>question:
>Flushot+ comes back with the message "Write access being attempted
>on C:\VACCINES\CHECKUP.EXE." Is CHECKUP supposed to try to write on
>the executable file that you're reading checksums on?
When I try the same thing here, I don't get anything. I also tried it
on a write-protected floppy and couldn't duplicate it. It appeared to
work fine for me - anyone else have any problems with it? If so, I'll
remove it from the archives until I can get a copy directly from the
author.
Ken
------------------------------------------------------------------------
= Kenneth R. van Wyk = =
= User Services Senior Consultant = Badgers! We don't need =
= Lehigh University Computing Center = no stinkin badgers! =
= Internet: <[email protected]> = =
= BITNET: <LUKEN@LEHIIBM1> = =
------------------------------------------------------------------------
=========================================================================
Date: Thu, 12 May 88 14:12:00 CDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: GREENY <MISS026@ECNCDC>
Subject: re: the "database" scheme....
this idea is good, providing of course that a virus writer doesn't find out
about your database and infect it as well....
I still believe that the best way to validate the length of the files as
being unaltered is to have a good hard copy on a piece of paper locked in a
safe that only you have the combination to.....(probably in a secret room
in your basement...:-) ), then once a month (or however long it takes you
to feel paranoid....) you can check the current length against the lengths
on the hardcopy. This may or may not be feasible on systems with a huge
amount of files (simtel20....), but it would seem to be such for a small-time
user....
bye for now but not for long...
Greeny
Bitnet: MISS026@ECNCDC
Internet: MISS026%[email protected]
=========================================================================
Date: Thu, 12 May 88 14:20:00 CDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: GREENY <MISS026@ECNCDC>
Subject: re:re: is there something funny in ....
> ...did anyone else have any problems with it? If so, I'll get a copy of
> it directly from the author...
Seeing as how we have been discussing for some weeks now the topic of viruses
and how easy it is to infect programs (especially those that cross thru
net-land...) I would think that *NO* programs designed to detect viruses
and/or eradicate them should be allowed into the Virus-l archives unless they
/it have been obtained from the author of such a program directly...
Even if it is a "trusted" friend that you are getting the program from, do
you trust his/her/it's friends as well? Remember that trust is transitive and
that if you trust me, you inherently have to trust everyone that I trust.
Therefore, getting it directly from the author seems to be the best possible
route of action. That way, if the program does go haywire, you know exactly
who to blame...
bye for now but not for long...
Greeny
Bitnet: MISS026@ECNCDC
Internet: MISS026%[email protected]
Disclaimer: I'm just visiting this planet, and everything I do on my planet
is absolutely legal, so it must be so here!
=========================================================================
Date: Thu, 12 May 88 15:25:18 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "David M. Chess 862-2245" <CHESS@YKTVMV>
Subject: The "database" scheme
There are lots more "provided"s than that! This is intended just
to catch viruses of the kind that I know are actually out there.
There are probably dozens of ways around it (some involving
altering the database and some not), and it doesn't even try to
catch boot-record-altering viruses like the "Brain" (although
that would be a small mod...). I just thought it might give
some budding anti-virus-programmers a concrete jumping off point.
Maria commented that it wasn't a new idea: that's very true,
and I don't claim to have invented anything new in the least.
This kind of modification-detection scheme seems to be the
first thing that good programmers think of when they first
hear about viruses. More references to previous work along
these lines (or any other lines!) would probably be valuable
additions to this list.
DC
=========================================================================
Date: Fri, 13 May 88 01:55:53 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Joseph Sieczkowski <[email protected].lehigh.edu>
Subject: The neverending chain....
Ok guys...let's face some facts:
NO software implemented virus protection scheme can ever be 100%
effective against stopping viruses because there always can be a
counter virus that attackes the protection program. (ie. Virus "A"
attacks system, Vaccine "A" protects system, Virus "B" could attack
Vaccine "A", etc...)
It is also very important to consider the system on which we're
implementing a protection package. A PC by definition is unsecure...
Why? (1) You can address real memory, and (2) you can access the I/O
ports directly. This compounds the problem.
This is not to say we should not write protection programs to try and
protect ourselves. There is probably much merit in the idea that if a
protection scheme is "hard" to break, people might not bother trying.
(Let's face it, the "fun" does wear off after days of trying to break
protection schemes.) However, we must realize that no scheme is
perfectly safe. What we are creating is a "fishnet" to catch most of
the viruses around. And, of course, we always have the option of
making the net a little finer.
Presently, it is of key importance to be aware of these little
beasties. (As all of you are as evidenced by being on this list.) In
the future, "hardware" protection is probably going to be a
neccessity. Hopefully, it won't inhibit system "friendliness" and
utility too much. (Remember, the most secure and protected system to
date is one which is totally isolated and restricted...and who wants
one of those? Yeeek)
Joes
=========================================================================
Date: Thu, 12 May 88 09:50:00 CST
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: LOWEY@SASK
Subject: RE: checksum signatures
> This raises an interesting question - is it truly possible to write
> a checksum/crc/whatever algorithm that will be able to figure out
> whether or not a file has been changed 100% of the time?
Of course, one thing you can do is keep copies of sensitive files on
other disks, like a floppy disk. You can then use the MS-DOS "comp"
or "fc" command (or the unix DIFF or whatever) to see if the files are
identical or not. As long as the copy of the file is in a
"sterile" environment, where the virus can't get it, this approach
should work better than any CRC checks.
This doesn't help in my original problem of getting a program to check
its self for an infection.
Kevin Lowey -- University of Saskatchewan Computing Services
=========================================================================
Date: Thu, 12 May 88 09:44:00 CST
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: LOWEY@SASK
Subject: RE: checksum signatures
> Consider: files are large objects, thousands of bytes long.
> Signatures are smaller than that; at most hundreds of bytes
> long. When you map a large set into a smaller set, there
> must be cases in which two or more things in the larger set
> are mapped onto the same thing in the smaller set (that is,
> the mapping must be many-to-one); this is just the PigeonHole
> principle.
Your argument is valid if you just want to corrupt the file.
However, as you pointed out, a virus has to work under certain
constraints. A virus has to modify a program so it does some damage
AND perpetuates its self. Usually the program has to operate
correctly for a while to give it time to infect other programs.
If we have a CRC checker that not only calculates a CRC, but also
saves the original file size, date, and time, then the virus maker
would have a tough time.
The virus would have to put the damaging code in a specific place in
the file (like into the DIR command in COMMAND.COM), with the
instructions in a specific order.
The virus would have to add code to save the date and time on the
file, then reset it back after infecting the file.
The virus would have to add more code to make the CRC pass, after
determining what CRC was used.
Some viruses would need code to see if it is on a hard disk or a
floppy disk.
A count of how many "infections" would have to be kept to delay the
action of the virus.
The program would still have to operate "correctly" so the user
doesn't know he is infected.
All this would have to be done without changing the size or date of
the file.
So with an appropriate virus checker, it isn't as simple as changing
a few bytes to make the CRC work out, assuming you know which CRC was
used in the first place.
Kevin Lowey -- University of Saskatchewan Computing Services
=========================================================================
Date: Fri, 13 May 88 02:36:00 CST
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
Comments: Warning -- RSCS tag indicates an origin of SMTPUSER@SASK
From: Derek Andrew <ANDREW@SASK>
Subject: RE: checksum signatures
It is true that simple checksums are easy to defeat. I suggest considering
using the DES algorithm in the following manner. First, consider the file as a
sequence of 8 byte blocks (64 bits). Encrypt each block using a public and
known password, and add the result to a running total, 64 bits wide. At the
end, you have a 64 bit checksum. I doubt anyone reading this is cabable
of modifying the original file so as to calculate this checksum.
I missed the original posting. I am assuming that the checksum does not
reside with the file, but is kept in a seperate location where the virus
could not get to it.
derek andrew, u of saskatchewan, [email protected]
=========================================================================
Date: Fri, 13 May 88 10:00:53 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Atul Butte <ST602397@BROWNVM>
Subject: Preventing Public Domain Software contamination
With all the problems with virus infected public domain and shareware
software, I propose the following solution (for the Macintosh):
There exists a shareware program called StuffIt 1.4 which was designed
to group multiple files into one file which can then be uploaded.
StuffIt 1.4 is for the Macintosh, and is turning into a sort of standard
for packing. StuffIt 1.4, in addition to grouping files can compress
them and can encrypt them.
The proposal:
How about adding a new feature to StuffIt that encrypts files, but in
such a way that they can only be decrypted and not encrypted again? This
can be done with the following method. StuffIt could prompt the
uploading user to enter an encrypting code which is used to encrypt the
files. Along with the files, another code is included. This code is the
decrypting code, which downloading users can use to decrypt the file.
The decrypting code could be hashed by some secret function into the
original encrypting code. This method is similar to the "trapdoor"
functions used for Public-Key Cryptosystems with one-way functions.
The advantage of this is that the original author of a program can
encrypt his or her software and place it in the public domain without
the fear of others downloading the file, contaminating it with a virus,
and then uploading the file as the original.
Atul Butte /----------\ /----------\
Brown University ! OK ! ! CANCEL !
[email protected] \----------/ \----------/
=========================================================================
Date: Fri, 13 May 88 10:51:35 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject: Re: Preventing Public Domain Software contamination
In-Reply-To: Message of Fri, 13 May 88 10:00:53 EDT from <ST602397@BROWNVM>
>How about adding a new feature to StuffIt that encrypts files, but in
>such a way that they can only be decrypted and not encrypted again? This
>can be done with the following method. StuffIt could prompt the
>uploading user to enter an encrypting code which is used to encrypt the
>files. Along with the files, another code is included. This code is the
>decrypting code, which downloading users can use to decrypt the file.
>The decrypting code could be hashed by some secret function into the
>original encrypting code. This method is similar to the "trapdoor"
>functions used for Public-Key Cryptosystems with one-way functions.
Sounds like a fair idea, but what's to prevent a person from
un-stuffing all the files, and then re-stuffing them into a brand
new stuff file with his/her own encryption code? Sure, only
the author could verify the authenticity of the encryption pw,
but in the meantime, this new version could be floating all
around on different bbs's.
Ken
------------------------------------------------------------------------
= Kenneth R. van Wyk = =
= User Services Senior Consultant = Badgers! We don't need =
= Lehigh University Computing Center = no stinkin badgers! =
= Internet: <[email protected]> = =
= BITNET: <LUKEN@LEHIIBM1> = =
------------------------------------------------------------------------
=========================================================================
Date: Fri, 13 May 88 11:39:00 EST
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: GILL@QUCDNAST
Subject: Something funny about CheckUp ?
I had the same problem with CheckUp occurring that was mentioned
earlier. However, I have had a lot of little bugs, system crashes, etc
occurring in the last two weeks. My machine is getting a full physical
next week, but I think the problem is software oriented. My impression
is that FLUSHOT+ is actually buggy. I know for a fact that FLUSHOT+
will crash PCWRITE 2.71 (one can't run PR.EXE from within ED.EXE), and
I've had other similar difficulties. I guess that comes from
intercepting so many different DOS interupts. Right now, I'm in the
middle of a total system backup and reorganization, without FLUSHOT+ to
protect/mess me. (However, I may be wrong :-) )
Anyone else had similar, unexplained difficulties?
Arnold Gill
Queen's University at Kingston
gill @ qucdnast.bitnet
=========================================================================
Date: Fri, 13 May 88 12:00:04 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "David A. Bader" <DAB3@LEHIGH>
Subject: Flushot+'s bugs
I, too, had a problem with Flushot+ in that it changed the CMOS memory
containing my AT clone's setup information (such as floppy and hard
drives connected, time and date, video configuration, system memory,
etc.)
Also, I recently read that someone had a problem with PCWrite 2.71. To
interject a paragraph from Eric Newhouse's Dirty Dozen List Issue #8,
revision "A" dated February 21, 1988:
PCW271xx.ARC (Suspected Trojan)
A modified version of the popular PC-WRITE word processor (v. 2.71) has
now scrambled at least 10 FAT tables that I know of. If you want to
download version 2.71 of PC-WRITE be very careful! The bogus version
can be identified by its size; it uses 98,274 bytes wheras [sic] the
good version uses 98,644. For reference, version 2.7 of PC-WRITE
occupies 98,242 bytes.
David A. Bader
Lehigh University
=========================================================================
Date: Fri, 13 May 88 08:36:00 LCL
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Communication is the root of insecurity
<herbison%[email protected]>
Subject: RE: DES checksum signatures
>It is true that simple checksums are easy to defeat. I suggest considering
>using the DES algorithm in the following manner. First, consider the file as a
>sequence of 8 byte blocks (64 bits). Encrypt each block using a public and
>known password, and add the result to a running total, 64 bits wide. At the
>end, you have a 64 bit checksum. I doubt anyone reading this is cabable
>of modifying the original file so as to calculate this checksum.
Cryptography (and especially cryptographic checksums) is a
complicated field, and is it difficult for a novice to determine
how difficult a scheme is to defeat. The checksum you mentioned
is trivial to defeat.
Here is the method to defeat that checksum: Since the key is
known, the intruder trying to modify the file can calculate the
original checksum. The intruder modifies the file, but saves
one 8-byte block that is never referenced and can have an
arbitrary value. The checksum for the modified file is
calculated (ignoring the spare block), and the difference
between the original checksum and the new checksum is determined
by subtraction. This difference is decrypted with the known key
and placed in the spare 8-byte block in the file. This modified
file now has the same checksum as the original file.
Even if the key is not known, there is an additional attack
against this checksum: individual 8-byte blocks of the file can
be transposed and the checksum remains the same. This is not
likely to be useful to someone who wants to create a virus, but
is a concern if general file integrity is important.
DES has a defined chaining mode (CBC--Cipher block chaining)
where a series of blocks is encrypted with the result from each
encryption step feeding into the next step. CBC mode has nice
properties for encryption, but, again, an integrity check using
CBC mode with a known key can easily be circumvented. [However,
changing the order of blocks can be detected if the key is not
publicly known.]
A simple way to use DES and a known key to build a good
(cryptographically secure) checksum scheme would be very useful,
but I don't know of any that have been demonstrated to be
secure.
[One step further: It would be nice if the developer of the
software could generate the cryptographic checksum and
distribute it with the software. This results in another
problem to solve: How the correct checksum can be securely
distributed.]
B.J.
=========================================================================
Date: Fri, 13 May 88 12:50:00 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Dr. Woody" <WWEAVER@DREW>
Subject: verification of authorship of computer programs
One problem we have been dealing with is verification of authorship of
computer works, whether executables or source code. (People feel better if
they have the source - but I don't know about you guys, but if I'm presented
with a 100K source file, I might not be able to detect a trojan...) This is
a standard problem in cryptography.
Probably the simplest solution applicable to the BBS system is to do the
following: the author should choose his favorite two very very large primes,
and publish and use their product in all his works. He can then encrypt his
executable (or source code) so that a public key system can decrypt it.
The author should, of course, put the public key with the cleartext
documentation. The advantage is simply that a responsible BBS owner need only
verify the existence of the author once, and can do it in a relatively compact
fashion: he doesn't have to do a diff on files recieved, but only on the key.
Moreover, the trojans we see today are typically revisions of already existing
files (like the archive 1A => archive 1B) and so the BBS owner would know if a
malicious user contaminated the file and resubmitted it: the key would change
from the original author to one devised by the malicious user.
One disadvantage of course is that decoding the file is made more computer
resource intensive. What price security? I would not mind running an extra
layer to verify that the author is who he says it is. A submission of a program
not by the author would decrypt to gibberish. (With some authors, even the
real program decrypts to gibberish... ;-) )
Of course, what will probably happen is that unsophisticated users will
distribute already decrypted images. However, at least the BBS owners have the
ability to store only author-encrypted files and preserve the BBS's integrity
for trojan-free files.
woody weaver
wweaver@drew
=========================================================================
Date: Fri, 13 May 88 12:49:00 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Dr. Woody" <WWEAVER@DREW>
Subject: detecting data alterations via CRC
One of the thoughts for detecting differences in files has been to write
down a checksum signature with the file. The problem, of course, is that if
the virus author realizes that his creation is subject to, say, CRC detection,
then he will have the virus upon infection compute the CRC of the file, and
then alter sufficient bytes to preserve the CRC.
It has been pointed out that typical programs are measured in the kilo-
byte, while signatures are measured in bytes; since the map is from a
larger set to a smaller set, the map can not be 1-1. One solution to this
was, as someone observed, is that there is more than one cyclic polynomial
that can be used: after all, fields have lots of primitive elements. If the
CRC polynomial can be chosen from one of m (where m is in the thousands),
and there is only a probability of 1 in 2^n of the virus accidentally
preserving the CRC checksum then the probability of correctly preserving
all of the CRC polynomials is 1 in 2^mn. Of course, that means that the
checking program would have to compute all m CRC polynomials. More likely,
the program would sample 2 or 3 CRC values; most people can live with a
likelyhood of 1 in 2^3n of the virus accidentally preserving the checksum.
One problem is that the virus need not accidentally preserve checksums. The
virus could concievably satisfy *ALL* of the CRC polynomials, provided it
knew how large the signature n was. (This assumes that the input set is larger
than 2^mn.) The chief advantage is that in order to be able to have self
replicating code with an infection scheme this complex, the virus would have
to be large and the infection process would be slow, consuming a (hopefully)
visible fraction of computing resources. Fat and slow viruses can be detected,
and after detection hopefully cured.
An alternative, for the people who are especially concerned about security
and are willing to devote a larger fraction of their resources can use a
CRC scheme with site dependent signature size. In this fashion, the virus
can not know in advance the detection scheme the site will use, and so the
infection passing the signature-preservation test will be back to random, and
a probability most people can live with.
woody weaver
wweaver@drew
=========================================================================
Date: Fri, 13 May 88 08:28:10 CDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Craig Pepmiller <CCCRAIG@UMCVMB>
Subject: Signature lengths
It is not strictly true that a signature must be as large as the file checked
to avoid many-to-one mapping. An easy way to prove this is data compression.
It is easy to construct a file that uniquely identifies a larger file if the
source has repeating patterns or other features that are compressible.
Another thought for budding compu-epidemiologists; There is a set of unique
machine instructions that a virus must use to work. If you compress all the
bytes that are not part of that set then you can have a signature that is
much much smaller than the original and still identify the vital parts of the
file. This would not work on programs that are meant to unpack and execute
other files (ie BASICA) or where a change in an argument can bring in
unchecked code. Maybe you would have to check disks in their entirety.
Any comments? What set of instructions would need to be part of the set?
Should this be a thesis project for somebody (maybe me)?
Think about it,
Craig Pepmiller
Comp. Prog./Anal. II
University of MO-Columbia
Bitnet: CCCRAIG@UMCVMB
=========================================================================
Date: Fri, 13 May 88 13:59:24 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject: Checkup
I just downloaded Checkup 1.4 from the author's own bbs (215-969-8379).
Rich Levin, the author, tells me that version 1.5 should be out within
a week or so. I'll post it as soon as it's available.
I was unable to find any differences between the file that I downloaded
and the one which I had previously posted. I think that Flu_Shot+
was displaying incorrect error messages - but I could be wrong...
I did have some other problems with Flu_Shot+ interfering with a couple
other programs, for what that's worth. Anyway, you can all rest assured
that the Checkup file on VIRUS-L is as the author intended for it to be.
The filename is still CHKUP14 UUE on this LISTSERV.
Ken
------------------------------------------------------------------------
= Kenneth R. van Wyk = =
= User Services Senior Consultant = Badgers! We don't need =
= Lehigh University Computing Center = no stinkin badgers! =
= Internet: <[email protected]> = =
= BITNET: <LUKEN@LEHIIBM1> = =
------------------------------------------------------------------------
=========================================================================
Date: Fri, 13 May 88 14:45:08 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "David M. Chess" <CHESS@YKTVMV>
Subject: Signature lengths
> From: Craig Pepmiller <CCCRAIG@UMCVMB>
> It is not strictly true that a signature must be as large as the file checked
> to avoid many-to-one mapping. An easy way to prove this is data compression.
That's a point; the true statement is more like that the signature of
a *random* file must be, on average, as large as the file to be checked
(if you run a data-compression program on a file of truly random
bits, the file usually gets larger...). If I had any faith in my
understanding of the concept of information, I'd say that a one-to-one
mapping is only possible if the elements of both sets contain the
same amount of information...
> Another thought for budding compu-epidemiologists; There is a set of unique
> machine instructions that a virus must use to work.
Could you elaborate on that? The instructions that a virus needs to work
are generally the same instructions that any other program needs to do
anything else (adds, moves, operating-system calls). You could probably
identify a set of bytes and say "any virus must contain at least one
of these", but it's not clear to me how that would aid in compression
and signature-making. Sounds interesting, though; could you give more
details? (Unless you think I'm the only one who doesn't understand,
in which case write me a note and scold me!)
DC
=========================================================================
Date: Fri, 13 May 88 20:35:22 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
Comments: In-Reply-To: 13 May 88 08:28:10 CDT from Craig Pepmiller
From: Otto Stolz +49 7531 88 2645 <RZOTTO@DKNKURZ1>
Subject: Signature lengths
> There is a set of unique machine instructions that a virus must use to
> work.
True.
> If you compress all the bytes that are not part of that set then you
> can ... still identify the vital parts of the file.
False!! Using specific instructions doesn't imply having these very
instructions in the executable program file.
The virus could well compose those vital (and revealing) instructions on
the fly from totally unsuspicious material. E.g. it could subtract some
register's contents from itself to fabricate zero, increment and shift it
several times to produce an arbitrary OP-code, store it to memory and
eventually jump to this very memory location.
Hence, all OP-codes belong somehow to the vital set.
Think about it.
Best regards
Otto
=========================================================================
Date: Fri, 13 May 88 12:26:00 EST
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: GILL@QUCDNAST
Subject: More FLUSHOT+ bugs
Now that someone mentioned it, I had the CMOS problem as well, but
on an IBM-PC clone (no XT or AT!) - my machine is a Zenith 151. From
the FLUSHOT+ documentation, I didn't even realize that my CMOS could
even be changed - it implies this is a purely AT possibility.
Arnold Gill
Queen's University at Kingston
gill @ qucdnast.bitnet
=========================================================================
Date: Fri, 13 May 88 17:01:23 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Russell Nelson <[email protected]>
Subject: All Things Considered
There will be a report on the Israel University virus tonight on NPR. Catch
it on your local public radio station. This report might be repeated on
next morning's Morning Edition.
-russ
=========================================================================
Date: Fri, 13 May 88 12:20:00 EST
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: GILL@QUCDNAST
Subject: Question about CRC protection
As I understand CRCs, the CRC is a particular polynomial function
of the bytes within a file. If that is the case, would it not be
possible to devise two (or three) orthonormal CRC polynomials, such that
any illegal change in the programs constant would necessitate a change
in one or more of the CRCs? A virus could make one of the CRCs come
out all right, but several orthonormal ones?
If such an idea is possible, then virus protection becomes simply a
matter of saving and safely protecting ones CRC list.
Of course, I may be wrong. Being in physics means I'm not overly
concerned with uniqueness proofs. :-)
Arnold Gill
Queen's University at Kingston
gill @ qucdnast.bitnet
=========================================================================
Date: Fri, 13 May 88 12:33:29 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Neil Duffee <NJD2F@UOTTAWA>
Subject: XMAS EXEC add'l comments
some additional comments on the CHRISTMA EXEC:
The above virus (which arrived here with the name XMAS EXEC) more likely
relied on our trust because it was, after all, sent to us from a friend at
another node, was it not? Since we trust our friends, why not just run it?
(besides, at that time, virii were limited to micros and not mainframes)
Locally, the operators (and prob. the system manager) did a periodic check
of the spool files and purged about 200+ files manually. (we are a rather
peripheral node)
Neil Duffee
Computer Operator
University of Ottawa
Ottawa, Ontario, Canada
[email protected] (soon to become [email protected])
=========================================================================
Date: Sun, 15 May 88 19:11:29 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Jim Frost <[email protected]>
Subject: Re: software self-checks
|> |however, such checks would be very useful in slowing the spread of a virus.
|>
|> A couple of comments to this. Yes, it'd slow the spread of
|> viruses, but it would also make you less paranoid about them (and
|> thus less likely to catch them),
| ----
| I assume this should have been MORE likely to catch them?
No, I meant less. If a virus was built that circumvented the checks,
you'd probably never find it because you're not looking for it under
the assumption that if it were there, you'd be told.
jim frost
[email protected]
=========================================================================
Date: Mon, 16 May 88 04:42:20 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Amanda B Rosen <[email protected]>
Subject: Various protection schemes against executable-infecting viruses
Hi... first posting for me...
About the one-to-one mapping, I believe that it has already been mentioned
that data compressors generate unique "signatures". In fact, for any desired
amount of certainty, there will be a spectrum of algorithms you can use,
ranging from storage-intensive, computationally undemanding ones to ones
which make great demands on the CPU but generate much smaller signatures.
For example, given a desire for 100% certainty, you could copy the file (for
a disk-intensive scheme) or Huffman-encode it (CPU-bound). Likewise, for
less certainty you could keep a large checksum or a small CRC.
Without giving the matter much thought (yet), I wonder if Huffman encoding
might not be a useful tool in the Virus wars. Of course, it makes large
demands on the processor, but you don't need to huf the whole file. I am
guessing now, but I bet that a 'database' type analysis which huf'ed a
file and kept just the table could defeat every file-modifying virus out
there today. Unfortunately this takes a lot of time. The $64K question is,
are there any Huffman-type schemes which take less time, but have the same
basic character?
The reason I am intruiged by Huffman is that it analyzes the character of
the data in the file. An example of another, very simple analysis scheme is
one that counts the number of occurences of each byte value in the file. This
would be difficult to defeat, because the virus would probably have to alter
such a large part of the infected program to conform to the validation check
that the program wouldn't be able to execute at all.
Why does everyone assume that a 'database' validation scheme must use only one
type of check? Having a variety of simple checks available and randomly
choosing two for each file to be validated (you store the types of the checks
along with their results) should be enough to stop any virus.
So... am I missing something?
/a
=========================================================================
Date: Mon, 16 May 88 14:03:00 LCL
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Michael Wagner new! +49 228 8199645 <WAGNER@DBNGMD21>
Subject: Re: software self-checks
> From jim frost <[email protected]>
> |> A couple of comments to this. Yes, it'd slow the spread of
> |> viruses, but it would also make you less paranoid about them (and
> |> thus less likely to catch them),
> | ----
> | I assume this should have been MORE likely to catch them?
>
> No, I meant less. If a virus was built that circumvented the checks,
> you'd probably never find it because you're not looking for it under
> the assumption that if it were there, you'd be told.
When I catch a virus, that is to me like catching a cold, i.e.
contracting, getting sick, etc. That is how I read your comment.
I think you meant catching as in detecting, trapping, immobilizing,
etc.
It seems I understood the opposite meaning from what you intended.
Ah, the dangers of mixing vocabularies willy nilly from different
fields.
Michael
=========================================================================
Date: Mon, 16 May 88 12:18:00 PDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: WETTERN@OREGON
Subject: RE: XMAS EXEC add'l comments
I just wanted to let you know that there are at least two legitimate programs
called XMAS EXEC out there. One of them, for example, is a cute little
animated thing coming from Japan.
So, when next xmas comes around and somebody sends you a XMAS EXEC, check it
out before you run or discard it. It might be a virus or something legitimate.
=========================================================================
Date: Mon, 16 May 88 14:07:00 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Woody <WWEAVER@DREW>
Subject: detecting damaged data
I think we've become a bit distracted on the problem of virus detection.
There seem to be two essential problems: first, making sure that the program
you recieve is free of viruses (and destructive code -- i.e. the authorship
problem) and ensuring that your data does not become contaminated over time.
The current discussion seems to be revolving about the latter half of the
problem: we would like to ensure that the executable image we are about to
launch (or data base we are about to access) has not been altered by a
malefic agent. Someone (sorry, threw away that message) proposed storing
a CRC signature for each file. Jerry Leichter (LEICHTER@YALEVMS) responded
>Unfortunately, it is very easy to modify a file so that any given CRC remains
>unaltered. The protection you get by using a CRC is thus quite limited - it
>stops those virus-writers who aren't clever enough to work around it.
This is an inherent problem: if we use a simple protection scheme, then the
virus can include code to defeat it. Varying what is meant as "simple",
while looking at the code to CHECKUP, Kenneth R. van Wyk (LUKEN@LEHIIBM1)
remarked
>This raises an interesting question - is it truly possible to write
>a checksum/crc/whatever algorithm that will be able to figure out
>whether or not a file has been changed 100% of the time? Let's assume
>that the signature data has *not* been tampered with in any way. It
>is no secret that both checksums and crcs can be circumvented rather
>easily. But, an algorithm which could validate a file with 100%
>effectiveness could be very worthwhile looking into. Once again, the
>validity of the signature data itself would have to be insured via
>encryption and/or read-only isolation.
David M. Chess (CHESS@YKTVMV) gave an argument to answer van Wyk's question
in the negative: essentially, it is that the number of possible messages
is larger than the number of possible (small) signatures. No one - to - one
function maps a larger set into a smaller set. However, Leichter's
original post goes on to point out the following:
>I would suggest a compromise: A mechanism that, while not completely secure,
>makes things very hard on a virus-maker while not requiring huge amounts of
>computation. When a program is published, a large number of random polynomials
>(say, 100 or 1000) are chosen, using the techniques of Rabin's paper. The CRC
>of the program with ALL the polynomials is published. To check a program, you
>chose any two of the polynomials - also published - compute the CRC's, and
>compare. (You must, of course, chose those two at random.) The virus maker
>must make his program have the same CRC with respect to ALL the 100 or 1000
>polynomials - which is possible, but requires (I believe, this would need to be
>studied) a LOT of computation. (The length should probably be checked - it's
>going to be a lot easier on the virus maker if he can add extra stuff to the
>end of the program to make the CRC's come out right.)
Professor Leichter is trying to simultaneously solve the authorship problem and
the preservation of data problem by publishing this list with the program.
One of the problems with this is that we still have to find some way to
publicly distribute this list, and then have to store this list (no small
overhead!). However, if we just consider trying to stabilize the data, this is
quite a useful system. When the file is recieved (or legally modified) a
collection of 100 or 1000 (or 10, site dependent CRC polynomial signatures) are
chosen and stored separate from the file.
Now, at appropriate intervals, one or two of the CRC polynomials from the
stored list are selected, are computed for the file, and compared against the
stored signatures. If a difference is detected, we know the file is
contaminated and appropriate measures can be taken.
In some sense, this is appealing to Arnold Gill's intuitive feel for the
effect of CRC error detection:
> As I understand CRCs, the CRC is a particular polynomial function
>of the bytes within a file. If that is the case, would it not be
>possible to devise two (or three) orthonormal CRC polynomials, such that
>any illegal change in the programs constant would necessitate a change
>in one or more of the CRCs? A virus could make one of the CRCs come
>out all right, but several orthonormal ones?
If the virus knows which (small number of) CRC's are going to be checked, it
(theoretically) can alter the data to preserve all signatures. If it doesn't
know which CRC's are going to be checked, it can only preserve them randomly.
If we can treat the virus as a random rather than intelligent agent, then
we achieve detection approaching that of noisy telephone lines, for which
CRC's are excellent.
The chief advantage of this scheme is that we are drawing upon the essence of
zero knowledge proof to verify the identity of the data. While a virus
could contaminate a specific site (because for a specific site the inquiry is
predetermined: the virus need only defeat a small number of detection
functions) general transmission of the virus is not possible; once such a
virus is detected at one site, avenues of communication (such as this list)
will alert other sites where it may have escaped detection and it can be
killed net-wide.
An important feature of this scheme is that it requires a small amount of
overhead (only a few signatures stored at any one site, instead of all of the
signatures stored at every site) and can be done quickly (little more than
reading the entire file). It seems clear to me at least that detection
schemes that require extensive storage or processing will not be enacted --
I mean, given sufficient storage, one would simply keep a spare copy of the
data on a WORM -- so this at least has a possibility of being followed in
the interests of good computer hygiene.
=========================================================================
Date: Mon, 16 May 88 14:37:41 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: [email protected]
Subject: Re: Signature lengths
>> It is not strictly true that a signature must be as large as the file checked
>> to avoid many-to-one mapping. An easy way to prove this is data compression.
>
>That's a point; the true statement is more like that the signature of
>a *random* file must be, on average, as large as the file to be checked ...
No, that's not quite right. All the "counterexample" shows is that there
may be a bijective mapping from the set of all signatures of n bits to some
*subset* (of size 2^n) of the set of all files of m bits, m > n. As I
mentioned in my previous message to VIRUS-L(1), it is the *number of distinct
values the program file can take on* that determines the size of the signature
required, not the number of bits in the program file per se. If you
allow the n-bit signature to include a program with more than n bits, there
will be a program of less than or equal to n bits for which there is no
n-bit signature.
A compression algorithm just tries to take the most "frequently occurring"
values of an m-bit file and give them representations in n bits. Consider
that it is not possible to compress all files, as Mr. Chess points out;
that is because in n bits you can't represent all m bit files, just as
you can't represent all m bit files in an n-bit signature.
In other words, compression would be analogous to finding a function that
assigns a unique n-bit number to each *existing* program you have (where there
are less than 2^n programs in existence). This may well be possible
(although in the worst case the function might have to have a copy of each
program to compare with the one being tested). Really, though, the function
would have to do slightly more than that; it would also have to return
some special value for all programs that didn't match, so you can tell
when you have a modified one.
>> Another thought for budding compu-epidemiologists; There is a set of unique
>> machine instructions that a virus must use to work.
>
>Could you elaborate on that? The instructions that a virus needs to work
>are generally the same instructions that any other program needs to do
>anything else (adds, moves, operating-system calls).
That's true. It's not really the set of unique machine instructions,
but rather the instruction *sequences*. Correctly-working programs use
these same instructions (maybe through a mediator, the operating system),
they just don't use them to infect other programs.
However, machines that provide "hardware protection" features do use
exactly the principle stated in the part with the ">>" above; these are
the "privileged instructions" (which may take the form of privileged
system calls). If you restrict this set of instructions to be used only
by code which is proven to protect against virus-operation (this
includes protecting the protection code itself, and other things generally
associated with a secure system), then you have a system which is
"secure," which is the source of much work these days.
But, notice that it gets increasingly hard to fully protect a system
in this way; for example, you would have to have the restriction that
only compilers can modify object files, for instance; i.e., the system
would have to distinguish writes to a user's file that result from the
user recompiling the program, from writes to the same file that occur
due to some other program trying to modify it to insert a virus.
Now that I think about it, that is not as hard as it first seems, it's
just not something that is usually provided nowadays. It would require
one to be very rigorous in the design, but it does seem as though
it could be done...
------
(1) I haven't seen my previous message appear on the list, though, so it
may have been lost on the way to LEHIIBM1.
Eric Roskos, IDA ([email protected] or [email protected])
=========================================================================
Date: Mon, 16 May 88 15:01:23 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: [email protected]
Subject: need RISKS LOG
Is there anyone out there who would be willing to send me the RISKS LOG
on a floppy disk? I will send you the postage required. I am preparing
a report on viruses and need the log fairly soon (at least by the first
of next week). I have been trying for several weeks to get a copy via
GET RISKS LOG but, although I get the report back from the list server
saying the job has run, the log never arrives. Apparently someone's mailer
is discarding it along the way.
If you are willing to do this, email me about it so we can work out how
to send it. Thanks... -- Eric Roskos
=========================================================================
Date: Mon, 16 May 88 14:47:08 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: [email protected]
Subject: Re: The neverending chain....
In the future, "hardware" protection is probably going to be a
neccessity. Hopefully, it won't inhibit system "friendliness" and
utility too much. (Remember, the most secure and protected system to
date is one which is totally isolated and restricted...and who wants
one of those? Yeeek)
Actually, the goal of a secure system should be to prevent "illegal" accesses
while providing a minimum of interference to "legal" accesses. This is what
makes it more challenging. Note, though, that *some* overhead is necessary,
simply because it requires more work to check that an access is "legal" than
just to allow all accesses. But it doesn't follow that the overhead has
to be intolerably high...
=========================================================================
Date: Tue, 17 May 88 04:19:54 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Amanda B Rosen <[email protected]>
Subject: Detecting damaged data
Shortly after I posted some thoughts concerning the usefulness of keeping
several (random) signatures for every file, Woody(WWEAVER%DREW.BITNET) posted
a long, well-written article declaring that this is exactly the right thing
to do. He still mentions only CRC's, though. Why are they considered the best
signatures? Is there a particularly easy way to defeat byte-counters (or
nibble counters, if you can't store a 256 word signature)?
It seems to me that in order to check files sufficiently often, the CPU
overhead must be *very* light. Disk storage, however, is at much less of a
premium. Even a 256 word signature would be a tiny percent of the actual
file's size, and the byte-counting algorithm is very cheap.
/a
=========================================================================
Date: Tue, 17 May 88 12:52:00 CET
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Karl-L. Noell" <NOELL@DWIFH1>
Subject: CRC Signatures not reliable at all ?
Several discussion remarks have objected, that CRC signatures wouldn't
be able to protect against intentional file tamperings.
This holds true only under the following assumptions:
1. A CRC based protection scheme is utilized.
2. The certain G(x)=... is the current (and public known)
denominator polynomial to calculate the signature, and
3. the original (untampered) file yields to the very remainder
R(x)=... considered as the signature of the clean file.
To succeed in his impious attempts, an evil-doer must exactly know
really *everything* stated above (1.,2.,3.). Then it's indeed possible
to 'adjust' the CRC signature to get the expected value even after
files have been altered. For this reason, CRC signatures can't provide
sufficient security if one intends to protect the public *distribution*
of files showing, that they are coming from trustworthy sources.
Nevertheless CRC signatures can be fairly reliable to protect files
from getting tampered *subsequently* during running for applications.
If you chose an arbitrary G(x) and *not* the polynomials standardized
by CCITT, and if you alter *your* G(x) from time to time, how should
another person be able to know about this scheme ? Keeping and com-
paring weekly logs reporting file sizes, time date stamps *and* CRCs
(computed with home made and sometimes changed polynomials) will give
a fair chance to detect suspicious events. I believe such imperfect
methode is still better than taking no care at all whilst waiting
for the 'great and entirely secure' solution.
Karl Noell
=========================================================================
Date: Tue, 17 May 88 07:22:00 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Woody <WWEAVER@DREW>
Subject: re: Detecting damaged data
Amanda B Rosen <[email protected]> asks
>Why are they [CRC checks] considered the best
>signatures? Is there a particularly easy way to defeat byte-counters (or
>nibble counters, if you can't store a 256 word signature)?
Actually, I don't think there is a "best" scheme. To defeat a particular CRC
check, you have to make sure that your virus maps the binary polynomial of the
corrupted file (mod the CRC polynomial) to the binary polynomial representing
the true file (mod the CRC polynomial). To defeat a byte counter, you have to
make sure the corrupted file has the same bytes as the true file (though
presumably in a new order). The thing is, though, if you devote that 256
word signature to a CRC check, we have 2^256*(wordsize) different possible
states that can arise as residues. Moreover, there are good mathematical
reasons to believe that these different states occur with equal frequency. If
you devote that 256 word signature to a byte counter then not all
2^256*(wordsize) bit patterns arise: moreover, I would suspect that the counts
for most executable files have about the same percentages of each operation.
The lack of randomness makes the test less effective. However, most people
want to check the size of the file as part of the corruption check -- the idea
of a byte counter is simply a generalizaton of that examination.
She continues
>It seems to me that in order to check files sufficiently often, the CPU
>overhead must be *very* light. Disk storage, however, is at much less of a
>premium. Even a 256 word signature would be a tiny percent of the actual
>file's size, and the byte-counting algorithm is very cheap.
Absolutely. If we want to add this check to a segment loader as part of the
operating system, it needs be fast indeed. As I recall, the CRC check is done
by fairly simple shifting and mod 2 addition: in both the byte counting
algorithm and the CRC check algorithm, the actual check is a small fraction of
the time required to retrieve the file from storage.
Is a CRC check before launch being done anywhere? Even a simple parity check
(i.e. CRC with polynomial x + 1)? Why not?
=========================================================================
Date: Tue, 17 May 88 08:37:26 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Otto Stolz +49 7531 88 2645 <RZOTTO@DKNKURZ1>
Subject: Special Warning on 3 infected MacIntosh programs
Hello,
A couple of minutes ago, I run into a letter dated 21th March 1988, that
was circulated by a Software Distributing House in southern Germany to
their customers. I will not post their name or address to this list; if
somebody really needs it, please drop my a note, privately.
As I don't have access to a MacIntosh, I can't assess the importance the
message might bear to MacIntosh users; so I deemed it best posting it in
this list for anybody who might be concerned. As none of the programs
below is mentioned in the DIRTY DOZEN, somebody (Ken Van Wyk?) should
forward this note to Eric Newhouse whose BITNET address is unknown to me.
Following is the main part of this letter (translated into English):
> Subject: MacIntosh Virus!!!
>
> Regrettably, also MacIntosh has been befallen by some virus, meanwhile.
> Please do *not* use any of the following programs:
> Pre-Release PageMaker 3.0
> Pre-Release HyperCard German
> Pre-Release Multifinder German
>
> *Beware:* Virus spreads through networks (e.g. AppleTalk)!!!
>
> Symptoms: Difficulties when using the Hard Disk, even to the amount
> of completely loosing the Hard Disk.
Best regards
Otto Stolz
=========================================================================
Date: Tue, 17 May 88 10:08:20 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
Comments: Resent-Date: 17 May 1988, 15:49:32 +0200 (MESZ)
Comments: Resent-From: Otto Stolz +49 7531 88 2645 RZOTTO at
DKNKURZ1
From: Otto Stolz +49 7531 88 2645 <RZOTTO@DKNKURZ1>
Subject: Special Warning on 3 infected MacIntosh programs
The following contribution came back to me from somewhere down the line
for a reason I couldn't figure out from the accompanying message.
As I'm not sure wether it has already reached the relvant LISTSERV,
I'm going to post it again.
Hello,
A couple of minutes ago, I run into a letter dated 21th March 1988, that
was circulated by a Software Distributing House in southern Germany to
their customers. I will not post their name or address to this list; if
somebody really needs it, please drop my a note, privately.
As I don't have access to a MacIntosh, I can't assess the importance the
message might bear to MacIntosh users; so I deemed it best posting it in
this list for anybody who might be concerned. As none of the programs
below is mentioned in the DIRTY DOZEN, somebody (Ken Van Wyk?) should
forward this note to Eric Newhouse whose BITNET address is unknown to me.
Following is the main part of this letter (translated into English):
> Subject: MacIntosh Virus!!!
>
> Regrettably, also MacIntosh has been befallen by some virus, meanwhile.
> Please do *not* use any of the following programs:
> Pre-Release PageMaker 3.0
> Pre-Release HyperCard German
> Pre-Release Multifinder German
>
> *Beware:* Virus spreads through networks (e.g. AppleTalk)!!!
>
> Symptoms: Difficulties when using the Hard Disk, even to the amount
> of completely loosing the Hard Disk.
Best regards
Otto Stolz
=========================================================================
Date: Tue, 17 May 88 08:40:00 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Joseph M. Beckman" <[email protected]>
Subject: Re: checksum signatures
In-Reply-To: Message of 12 May 88 09:15 EDT from "Kenneth R. van Wyk"
1. It is patently false that a checksum algorithm can (with an accuracy
of 100%) detect changes to a file. I am assuming that "checksum" here
means some "encoding" of the file that *is less lengthy* of the file
itself. Consider this: let's let xx represent files, y represent the
checksum. If we only use digits for this example, there are 100
different files that can exist, 10 different checksums. Clearly, one
checksum "covers" 10 files.
Although you can do certain other things (in addition to "pure"
checksums), you would (?) have to *be able to recreate the original
file* from the "checksum" (and whatever else you looked at) in order to
claim 100% detection. Anything less says that there is a possibility of
"collision."
If you make a backup of a file & then do a compare, that would give you
100% (with certain assumptions); or even if you could compress the file
& back that up. It may be that you can achieve 100% detection with less
if you make certain assumptions about what the file will or will not
contain; but if you are talking about arbitrary strings, such an
assumption is not valid.
Joseph
=========================================================================
Date: Tue, 17 May 88 17:18:00 LCL
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Michael Wagner new! +49 228 8199645 <WAGNER@DBNGMD21>
Subject: Re: Detecting damaged data
> From: Woody <WWEAVER@DREW>
>
> Is a CRC check before launch being done anywhere? Even a simple
> parity check (i.e. CRC with polynomial x + 1)? Why not?
I believe OS-9 has always done this. Even on slow 1MHz 6809s, the
delay was never objectionable. The point was not to detect
viruses, but rather to provide some minimal protection against
calling programs that had suffered damage on disk and had passed
the rather simplistic old disk data validation checks. This was
especially important on a cpu that had no memory protect and no
supervisory/user mode capabilities. I don't recall the details of
the algorithm any more, but I can find out if anyone is interested
(private mail, please - don't tell the whole list).
It was so simple at thing to do, and offered considerable
protection. I never understood why no other micro-os manufacturer
did it.
Michael
=========================================================================
Date: Tue, 17 May 88 12:59:00 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Woody <WWEAVER@DREW>
Subject: re: CRC signatures not reliable at all ?
Karl Noell <NOELL@DWIFH1> (Germany! Isn't BITNET a great communication
network?) writes
>Several discussion remarks have objected, that CRC signatures wouldn't
>be able to protect against intentional file tamperings.
>This holds true only under the following assumptions:
> 1. A CRC based protection scheme is utilized.
> 2. The certain G(x)=... is the current (and public known)
> denominator polynomial to calculate the signature, and
> 3. the original (untampered) file yields to the very remainder
> R(x)=... considered as the signature of the clean file.
>To succeed in his impious attempts, an evil-doer must exactly know
>really *everything* stated above (1.,2.,3.). Then it's indeed possible
>to 'adjust' the CRC signature to get the expected value even after
>files have been altered. [...]
I'd like to point out he needn't really *know* all that.
Let us suppose that the virus writer knows that 1 is true. Also, suppose
that the virus writer does not *know* the G(x) of 2, but suspects it is
one of g1(x), g2(x), ... gk(x). Write G(x) = g1(x) * g2(x) * ... * gk(x),
and set ti(x) = G(x) / gi(x) (for i = 1 .. k ). For a fixed remainder gi(x)
he precomputes mi(x) so that
mi(x) * ti(x) = 1 mod gi(x).
(Such exist from the chinese remainder theorem, because the CRC polynomials
are relatively prime.) Set p(x) to be the clean file, interpreted
as a binary polynomial. Compute r1(x), r2(x), ... , rk(x) the remainders
mod g1(x), g2(x), ... , gk(x) respectively. Form
r(x) = sum { ri(x) * mi(x) * ti(x) } mod G(x).
The virus need only do the following: (1) analyze the executable image, and
find a routine that is rarely executed. Carefully jump
around that routine, and use the space for his viral code. Alter p to form
an infected, virally communicating file p'(x). Save a bit more space that we
will use as free variables. (2) Alter p'(x) to p*(x) by manipulating that free
space so that p*(x) = r(x) mod G(x).
Now, no matter which CRC check g1(x) to gk(x) is run, p*(x) has the same
residue as the 'clean' file p(x).
There is no way to defend against that, provided the invading virus does
know that you are using a CRC check and has a (short) list of CRC polynomials
to protect itself against. There is considerable hope, however. The
computation involved in obtaining r(x) is nontrivial. Moreover, the 'save
a bit more space' may also be nontrivial: to match the residue mod G(x)
it could be necessary to use up to degree(G(x)) bits and this is the degree
of the CRC check times the number of potential checking polynomials: with
a sufficiently large CRC check signature and sufficiently many candidates
for check polynomials, our virus writer can't write an undetectible virus.
Anyway, Karl Noell goes on to observe
>If you chose an arbitrary G(x) and *not* the polynomials standardized
>by CCITT, and if you alter *your* G(x) from time to time, how should
>another person be able to know about this scheme ? Keeping and com-
>paring weekly logs reporting file sizes, time date stamps *and* CRCs
>(computed with home made and sometimes changed polynomials) will give
>a fair chance to detect suspicious events. I believe such imperfect
>methode is still better than taking no care at all whilst waiting
>for the 'great and entirely secure' solution.
A person could know your CRC check polynomial because you aren't clever enough
in concealing it. Suppose you have a file called MY_CRC_CHECK_POLYNOMIAL.DAT...
I could have my virus look for such a file and use it. But seriously, this
is the whole point. If we are able to assume that the virus does not know
which of the CRC polynomials you are using (nor its size) then he can not
protect completely against it. As long as we are dilligent and random, this
is not an "imperfect methode" but safe protection against a random virus.
A more serious problem however would be a program designed to specifically
live inside a specific site or system. For a specific site, the randomness
of the CRC is no protection. But then, this is virus-L, not ICE-L...
woody
=========================================================================
Date: Tue, 17 May 88 08:42:00 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
Comments: Resent-From: "Joseph M. Beckman" <[email protected]>
Comments: Originally-From: "Joseph M. Beckman" <[email protected]>
From: "Joseph M. Beckman" <[email protected]>
Subject: Re: hunting up infected files
In-Reply-To: Message of 9 May 1988 11:05 edt from Karl-L. Noell
As an employee of the National Computer Security Center, I must point
out that we do *NOT* attempt to track perpetrators for prosecution or
for *ANY* other reason!
We are not a law enforcement Agency, and are prohibited by law to take
any such action.
We are interested in tracking the viruses (or ordinary Trojan Horses) as
they infect different sites.
As a matter of professional interest, I would be curious as to the
motivations of perpetrators of malicious code, or whether they are
members of "Hacker Clubs;" but that is information that may be conveyed
without identifying the people/organizations involved.
Joseph
=========================================================================
Date: Wed, 18 May 88 08:35:47 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject: Beware the turkey! :-)
Here's a forwarded message that I got. The program described here looks
almost like a new CHRISTMA EXEC - if anyone has any more information on
this, please send it to the list.
To: [email protected]
Subject: Warning!
Date: Thu, 12 May 88 13:07:21 -0700
From: Tim Morgan <[email protected]>
Everyone should be aware of the program described in the following
message. We don't want to have to restore any files for anyone...
Date: Tue, 10 May 88 12:48:16 PDT
From: Doug Fouts <fouts%[email protected]>
To: [email protected]
Subject: EMAIL WARNING
I have just been informed by a friend of mine here at U.C.S.B.
that there is a program being passed around via ARPAnet (and
also some other computer networks) that is called "turkey". The
instructions that are sent with the program say that when
compiled and run the program will draw a nice picture of a
turkey. I have been informed that the program is a (not very
funny) joke. It does not draw a turkey, but it does erase all
of the unprotected files in your directory. You might want to
pass this information along to people you know who use the
network, as I am doing.
Doug Fouts
------------------------------------------------------------------------
= Kenneth R. van Wyk = =
= User Services Senior Consultant = Badgers! We don't need =
= Lehigh University Computing Center = no stinkin badgers! =
= Internet: <[email protected]> = =
= BITNET: <LUKEN@LEHIIBM1> = =
------------------------------------------------------------------------
=========================================================================
Date: Wed, 18 May 88 14:49:00 LCL
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Michael Wagner +49 228 8199645 <WAGNER@DBNGMD21>
Subject: Re: CRC signatures not reliable at all ?
> From: Woody <WWEAVER@DREW>
>
> There is considerable hope, however. The computation involved in
> obtaining r(x) is nontrivial. ...with a sufficiently large CRC
> check signature and sufficiently many candidates for check
> polynomials, our virus writer can't write an undetectible virus.
There is a very important point here, which I think needs to be
stressed more than Woody is stressing it. A virus sophisticated
enough to defeat the nontrivial schemes being proposed should be
detectable either by the space it consumes or the time it takes
up. This really the best we can hope for in these CRC schemes; to
force such a virus into the domain of the visible. But we still
have to have the tools to 'see' with. Therefore, computer users
need to have precise tools to account for:
1. All consumed and free disk space
2. All consumed and free main storage in the running system
3. All consumed cpu time over some period of time.
These tools are anyways useful to micro owners who want to better
understand the workings of their micros, but they become absolutely
necessary to manage the problems that occur when virii start
sprouting up. If a certain, theoretically-unchanged operation
starts taking significantly longer, it may have been subverted.
To an extent, provision for these tools needs to be built in. For
example, there should be no unaccounted-for storage on disk; the
map should show it all, including boot blocks, fats, (skinnies,)
whatever.
Michael
=========================================================================
Date: Wed, 18 May 88 08:56:04 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject: Re: CRC signatures not reliable at all ?
In-Reply-To: Message of Wed, 18 May 88 14:49:00 LCL from <WAGNER@DBNGMD21>
> This really the best we can hope for in these CRC schemes; to
> force such a virus into the domain of the visible.
> ...
> If a certain, theoretically-unchanged operation
> starts taking significantly longer, it may have been subverted.
There certainly is a lot of truth in that; a virus that is sufficiently
smart enough to get around the defense mechanisms proposed here would
probably use enough CPU time such as to become noticable. Even the
simple viruses seen so far can be noticed by someone who is truly used
to the speed that his/her micro operates. However, you run into problems
with this "method" of virus detection when (if?) you start to use multi-tasking
operating systems like OS/2 and/or Un*x. Since several programs could be
running at the same time in such a system, any one program could take a
different amount of time to execute every time you run it.
Ken
P.S. I'm *not* trying to start a conversation on the merits of OS/2 vs.
MS-DOS! Really, I'm not!
------------------------------------------------------------------------
= Kenneth R. van Wyk = =
= User Services Senior Consultant = Badgers! We don't need =
= Lehigh University Computing Center = no stinkin badgers! =
= Internet: <[email protected]> = =
= BITNET: <LUKEN@LEHIIBM1> = =
------------------------------------------------------------------------
=========================================================================
Date: Wed, 18 May 88 15:52:00 LCL
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Michael Wagner new! +49 228 8199645 <WAGNER@DBNGMD21>
Subject: Re: CRC signatures not reliable at all ?
> Even the simple viruses seen so far can be noticed by someone who
> is truly used to the speed that his/her micro operates. However,
> you run into problems with this "method" of virus detection when
> (if?) you start to use multi-tasking operating systems like OS/2
> and/or Un*x. Since several programs could be running at the same
> time in such a system, any one program could take a different
> amount of time to execute every time you run it.
This was exactly my point (I guess I didn't express it very well).
On simple systems, real time is (perhaps) an adequate measure. On
multi-tasking machines (for me it's not when or if, it's how long
ago. OS/9 and AmigaDOS were my last two micro operating systems;
between them it's been five years since I used anything simpler),
you MUST have ways to measure CPU consumed BY TASK/PROCESS. This
implies that OS designers must build dispatchers that attribute
all CPU consumption to the various consuming tasks.
> Ken
Michael
=========================================================================
Date: Wed, 18 May 88 14:53:44 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject: forwarded submission
Here's a forwarded message from J.D. Abolins:
Re: Eric Rostov's request for copy of risks log on diskette...
Eric or anyone else seeking for this and other files on diskette
(5.25" >Diskette, msdos format), can snd me a stanped, self-
addressed mailer to me at
j. d. abolins
301 N. Harrison Street #197
princeton, NJ 08540usa
(this is a mailing address only.)
Daytime phone: (609) 292-7023
Besides the risks log, I have a number of other text files and
articles concering the viruses. Photocopies of print articles
can be made by arrangement.
Re: the request to pass a message on virus-l to Eric Newhouse...
I am going to send him a print copy of the message. Eric
Newhouse, the developer of the dirty dozen listing, is not on
bitnet. He is the sysop of the crest rbbs in california.
the bbs number is (213) 471-2518. His mailing address is
Eric Newhouse
1834 Old Orchard Road
Los Angeles, CA 90049 usa
Soon, I hope to send up the most recent version of the dirty dozen
listing.
j.d.abolins
[Thanks for the generous offer J.D.!. -Ken]
------------------------------------------------------------------------
= Kenneth R. van Wyk = =
= User Services Senior Consultant = Shocked! Shocked I am at =
= Lehigh University Computing Center = this despicable act! =
= Internet: <[email protected]> = =
= BITNET: <LUKEN@LEHIIBM1> = =
------------------------------------------------------------------------
=========================================================================
Date: Fri, 20 May 88 08:12:00 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Joseph M. Beckman" <[email protected]>
Subject: Re: Signature lengths
In-Reply-To: Message of 16 May 88 14:37 EDT from
"riacs!ames!hc!csed-1!csed-47!roskos%rutgers.edu at
CUNYVM.CUNY.EDU"
The capability to limit what programs can write to executables, etc., is
a capability we are building into the LOCK (LOgical Coprocessing
Kernel).
This is done by assigning a "domain" to every subject (program) and a
"type" to every "object" (file). There is an access matrix to determine
which domains have (a particular) access to types. So if you have a
type called "executable", only a subject in domain "trusted compiler"
would have write access to it.
This is a very powerful integrity tool, which will allow us to make some
very strong assertions about how (if any) viruses could exist in such a
"LOCKed" system.
Joseph
=========================================================================
Date: Fri, 20 May 88 08:46:35 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject: Re: Signature lengths
In-Reply-To: Message of Fri,
20 May 88 08:12:00 EDT from <[email protected]>
>a capability we are building into the LOCK (LOgical Coprocessing
>Kernel).
Any chance of giving us VIRUS-L readers some more information on
LOCK? I'm sure we'd all appreciate it.
Ken
------------------------------------------------------------------------
= Kenneth R. van Wyk = =
= User Services Senior Consultant = Shocked! Shocked I am at =
= Lehigh University Computing Center = this despicable act! =
= Internet: <[email protected]> = =
= BITNET: <LUKEN@LEHIIBM1> = =
------------------------------------------------------------------------
=========================================================================
Date: Fri, 20 May 88 09:07:02 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject: forwarded submission
Here's a forwarded submission from J.D. Abolins:
Ooops, my apologies. I had gotten the name wrong for the fellow
who is looking for the copy of the RISKS LOG. I still don't have
a copy of the original message from here at this site, but I
think the name is more like Eric Roskos. But in any case, you
know who you are and the offer for the doskette applies to anyone
on the VIRUS-L list. (I prefer a stamped self-addressed disk mailer
with a diskette or money to cover the disk and mailing.)
Also I have sent up the DIRTY DOZEN listing, version 8 b. This
came out in April 1988.
J.D. Abolins
------------------------------------------------------------------------
= Kenneth R. van Wyk = =
= User Services Senior Consultant = Shocked! Shocked I am at =
= Lehigh University Computing Center = this despicable act! =
= Internet: <[email protected]> = =
= BITNET: <LUKEN@LEHIIBM1> = =
------------------------------------------------------------------------
=========================================================================
Date: Sat, 21 May 88 23:21:00 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Joseph M. Beckman" <[email protected]>
Subject: Additional LOCK Info
In-Reply-To: Message of 20 May 88 08:46 EDT from "Kenneth R. van Wyk"
Re: LOCK
One of the problems with building security into Operating Systems, has
been the serial nature of a computer. When the user's program is
operating, the security software is not. The user is then only
constrained by what the TCB (trusted computing base) has done *before*.
If there is a failure, and the user is jumped into mastermode, he can do
whatever he wants. There is also an obvious performance penalty; the
more security processing is necessary, the less time there is for user
programs.
LOCK is (essentially) adding a separate computer onto the computer to be
secured (called the Host). This allows us to monitor without the
performance penalty. It also allows us to keep the tcb code physically
separate from user applications -- there is *no way* for the user to
generate an address that reaches into the tcb code -- it is on a
separate machine (albeit attached to the Host's bus).
Most "secure" systems being built are designed to stop the compromise of
information, pretty useless against an integrity attack (such as a
virus). That's one of the reasons we are building the Type Enforcement
mechanism; to stop viruses and ordinary Trojan Horses.
Although this mechanism cannot "detect" or "screen" viruses, it can at
least reduce them to ordinary Trojan Horse status (disallowing them
anyway of propagating). Of course, if you audit, you should be able to
pick up a virus attempting to propagate (due to rejected actions).
Joseph
=========================================================================
Date: Mon, 23 May 88 09:35:48 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject: implementing protection mechanisms
I'd be interested in seeing some discussion about what virus protection
mechanisms other people have actually implemented, particularly in
microcomputer labs at universities. I don't just mean commercially
available products; rather, any steps that are currently being taken
at your site to try to prevent viruses from spreading there. Are you
just using write protect tabs, etc., or are you also using some program(s)
to try to detect them?
Here at Lehigh University, we're currently implementing more and more
Novell Local Area Networks - the network file server providing read-only
access to all executable files on the LAN. We're also using notchless
boot floppy disks for the workstations. Granted, there are ways of
getting around the notchless floppies (via modifying hardware...), but
they seem to be doing a pretty reasonable job (knock on wood :-).
We're also currently evaluating a number of commercial products.
So, what's everyone else doing? Opinions?
Ken
------------------------------------------------------------------------
= Kenneth R. van Wyk = =
= User Services Senior Consultant = Shocked! Shocked I am at =
= Lehigh University Computing Center = this despicable act! =
= Internet: <[email protected]> = =
= BITNET: <LUKEN@LEHIIBM1> = =
------------------------------------------------------------------------
=========================================================================
Date: Tue, 24 May 88 13:13:00 PDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: DBUERGER@SCU
Subject: Comments on FLUSHOT PLUS
I am forwarding these notes on FLUSHOT PLUS from
Usenet.comp.sys.ibm.pc.general. I forgot to include
the headers, but authors' net addresses are included.
-------------------------------------
I was testing FLUSHOT Plus to see if it was worth the
$10.00 fee the Author, Ross Greenberg is charging.
I knew that a large number of hours had been put into the program.
The documentation made it lk prettgood, even though it was a bit
rambly.
I created a FLUSHOT.DAT file, and put in 37 lines
of the form
C=filename
When I loaded Flushot, I got a message saying that
there was no room for a table, and the machine hung.
I had not read the documentation closely enough. It turns
out that you have to put a 'dummy' checksum in each line
like this:
C=filename[12345]
Where 12345 is the dummy number. When flushot is started,
it checksums the file, and reports the new number, which
you have to write down and type in FOR EACH FILE!
I then rewrote the FLUSHOT.DAT file with only two programs,
command.com and a.bat checksummed. Flushot checked them on
startup, but did not perform as advertised when I ran A.BAT,
changed it, and ran it again.
Flushot claims that it checksums files whenever they are
loaded by MSDOS. I guess this does not apply to BATCH files.
I was going to test checksumming of .EXE files, but FLUSHOT
trashed my CMOS ram.
FLUSHOT PROTECTS CMOS RAM ?
Finally, I added two more lines to FLUSHOT.DAT with dummy
checksums. I restarted FLUSHOT and got the following
message:
CMOS RAM HAS BEEN CHANGED. Y TO CONTINUE, ANY OTHER
KEY TO PROCEED
Followed by a long garbled bunch of characters!.
Naturally, when I rebooted I could not boot from the
Hard Disk, until I restored the setup information.
My CMOS ram was trashed by FLUSHOT! I hoped that no damage
had been performed to my FAT!.
I then restored my ram with a CMOS-SAV progam which I wrote
for such a purpose, and reloaded flushot.
I then ran a program which zeroed out my CMOS ram using
MS C outp() function, without a whimper from FLUSHOT.
Note that I had no TSR'S present when this happened. I
have a Leading Edge AT clone (Made by Mitsubishi, same
as SPERRY IT). I am running DOS 3.1.
I considered the possibility of Ross Greenberg enforcing
his $10.00 fee by putting counters into flushot (since I
had to restart it each time I changed anything in the
FLUSHOT.DAT file and did this a number of times)
and put the idea aside. (That was a pretty virulent dissertation
in the manual about *worms*, maybe he thinks that people
who don't buy his software are *worms*?!? :-)
What I think Ross will accomplish by these threats, rewards,
challenges is ENCOURAGE scores of copycats to write viruses
to beat flushot (which is buggy).
My conclusion is that FLUSHOT Plus does not perform as
advertised (in my case, anyway) and I would not use it
or even trust it with my data.
The checksum protection is quite limited in number of
files, and the
method of entering the checksum is quite painful.
The bugs in the program might be excusable if
the program was public domain or shareware in the
sense that you pay for it only if you think it is
valuable (not if you use it, since technically, I
owe Ross Greenberg $10 since I used it) .
I think that it tries to do too much, and ends up doing
too little, even the wrong thing altogether. This shows
poor design and testing practice.
When I support a shareware program, I am not paying the
author for his time, I am paying for a finished product.
And a finished product, FLUSHOT PLUS is not !
The above is my opinion, and no-one is liable for it but
myself. I reserve the right to deny everything.
Matt Cohen (matt@psuhcx)
-------------------------------------------------
As promised, I forwarded matt@psuhcx (Matt Cohen)'s letter to Ross.
Here's his reply:
"Well, Matt, I'm sorry that you found the program to be less than you
expected. You certainly got your money's worth, though, didn't you?
Look, the program does try to do a lot. One area I'v had consistant
trouble with has been CMOS. It'll get pulled in the next release. Not
because some people didn;t find it useful. Just because the bitching from
the people who had problems with it isn't worth the lousy $10 that the other
people pay. If you don't like it, don't use it. I'm certain that I won;t
lose any sleep over it.
You might want to consider using one of the commercial products. I
understand that at least one of them costs about $200. But, since you have
to pay them in advance, I would assume that you'd not even consider such a
thing. I ask people to contact me if they have a problem. I guess that
part of the manual (the one with my phone number) must have escaped your
astute observations as well as the "How to Use Flu_Shot" section must have.
I know!! Your printer was out of paper! Well, just for you Matt, I'll print
out a copy here and send it to you --- if you pay the postage.
But, I guess with people like you around, I should just stop enhancing
FLU_SHOT, or trying to protect *you* from the bad guys. Hell, I can't even
protect you from yourself.
Have a nice day, Matt."
Erik Bailey | CompuServe | 7 Oak Knoll | (ARPA/USENET courtesy of
ihnp4!think!ejb | PCMagNet | Arlington, MA 02174 | Thinking Machines Corp.,
[email protected] | 72261,3275 | (617) 643-0732 | First St, Cambridge, MA)
do headache -> take 1 aspirin od "This terminates one way or another" -Dijkstra
%%% End of forwarded messages
David Buerger
[email protected]
=========================================================================
Date: Tue, 24 May 88 16:55:36 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject: More Flu_Shot woes
I just saw another interesting Flu_Shot related bug report on the
Usenet and I thought that I'd forward it here. The report goes into
quite some detail as to specific bugs in various versions of Flu_Shot,
including Flu_Shot+ 1.2. I hope that these bugs get fixed in a future
release!
Here's the forwarded message:
>From: Glenn Larsen <glarsen@note.nsf.gov>
>I had only one problem with Flu Shot 3 which was downloaded from SIMTEL
>in Nevada. The problem was when using the option to protect the CMOS were
>configuration information is stored with battery backup.
Here in Albuquerque a local BBS SYSOP complained that FLUSHOT3 was actually
a Trojan Horse program itself and was responsible for trashing his hard disk.
Since it seemed like a legit program to me, based on the well documented
sources of the program uploaded to SIMTEL20, I decided to take a little time
and dis-assemble FLUSHOT3 and see if I could see any trouble. What I found
was a program that, in my opinion, was loaded with bugs. One of the bugs I
found was in the CMOS restore section: FLUSHOT3 screws up and replaces the ES
register with the DS value when it returns from this routine.
Summary of BUGS and/or omissions in FLUSHOT3 detected as of May 1, 1988:
Bugs which can cause significant damage:
1. Stack corrupted in Int 26h handler: should return via RETF,
which should leave flags on stack, but instead returns via
RETF 2, thereby discarding flags.
2. Restoring CMOS memory after checking improperly restores
the es segment register : es is replaced by ds
3. Program assumes direction flag is cleared (forward).
Less damaging bugs:
4. Incorrect memory size (2 times amount req'd) in install
5. Interrupts are enabled for no reason in FCB test
Condom holes: Bugs or ommissions that make program ineffective
6. Incorrect jmp instruction disables ASCIIZ rename checking
7. No check of AT bios int 13h "Write long" call (0bh)
No checks for XT int 13h format calls 6 and 7
8. No accommodation for extended FCB format
9. No checks for direct IO via IOCTL call 44h
10. Program fails to detect FCB file delete and renaming
functions that can affect critical files if wild
cards are used.
Loose ends:
11. Invalid error codes returned by int13h and int26h
12. Error code returned by failed FCB calls is unknown
13. Failures are not handled consistently - FCB calls return
to program while others force a program terminate.
14. No checks for existence of CMOS RAM before reading and/or
attempting to restore it. What happens on non AT's? [Since
the user has to specifically request this check, one could
argue it would be his/her own fault to invoke it on a machine
that doesn't have the CMOS memory.]
FluShot Plus, version 1.2 is significantly better, but it still has
some problems: What I've found as of May 14, 1988:
Bugs which can cause significant damage:
1. Stack corrupted in Int 26h handler (fails to leave old
flags on stack as it should)
Condom holes: Bugs or omissions that make program ineffective
2. No check of XT bios int 13h format functions 6 and 7
3. No accommodation for extended FCB format
4. No checks for direct IO via IOCTL call 44h
Loose ends:
5. Invalid error codes returned by int 13h and int 26h failures
6. No checks for existence of CMOS RAM before reading and/or
attempting to restore it. What happens on non AT's? [Since
the user has to specifically request this check, one could
argue it would be his/her own fault to invoke it on a machine
that doesn't have the CMOS memory.]
7. Overall the program coding is bit sloppy. Since it doesn't make
any attempt to optimize usage of the segment registers, it is a bit
longer and slower than it needs to be.
Final comments:
What else can I say? I'm not going to claim to be the world's finest
programmer and that I could do a better job. I may well be dead wrong
in identifying some of the code as bugs. However I would suggest that
if you are planning on using FLUSHOT xxxx, back up your hard disk first.
PS:
I downloaded the latest FSP_12.ARC from SIMTEL20 tonight to make sure
that it was the same as what we had gotten off local boards here in
Albuquerque. Unfortunately, the FSP.COM file was different! A quick
check, however, reveals that the only difference was the addition of a
CMP AL,"?" and JE xyz pair of instructions in the filename compare
subroutine. The Int 26h stack bug was still there.
Albq. version of FSP.COM: 10309 bytes CRC = BDCE 27 April 88
SIMTEL20 version : 10313 bytes CRC = 9723 27 April 88
Peter Esherick
Sandia National Labs, Albuquerque
<[email protected]>
------------------------------------------------------------------------
= Kenneth R. van Wyk = =
= User Services Senior Consultant = Shocked! Shocked I am at =
= Lehigh University Computing Center = this despicable act! =
= Internet: <[email protected]> = =
= BITNET: <LUKEN@LEHIIBM1> = =
------------------------------------------------------------------------
=========================================================================
Date: Wed, 25 May 88 08:37:49 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject: well...
Well, this isn't a virus per se, but I thought I'd mention it here because
it spread over so much of the Usenet that it's become a major annoyance...
Yesterday, a student on the Usenet sent out a request for money to further
his education. He's requesting that each person reading his message sends
him $1.00 - kind of like a chain letter... He sent this out to *MANY*
major Usenet discussion lists. While reading Usenet news this morning,
I probably saw his posting on about 20 different news groups.
Granted, this poor starving student probably (!) deserves money to
continue to go to college. But, I'd hate to see this sort of thing set
a precedent on e-mail forums such as VIRUS-L and those on the Usenet.
It'd become as bad as the CHRISTMA EXEC - everyone would be sending out
this sort of junk mail over the networks which would undoubtedly cause
lots of congestion, to say the least. Sort of a human nature virus...?
Ken
P.S. For obvious reasons, I didn't want to re-post the student's message
here.
------------------------------------------------------------------------
= Kenneth R. van Wyk = =
= User Services Senior Consultant = Shocked! Shocked I am at =
= Lehigh University Computing Center = this despicable act! =
= Internet: <[email protected]> = =
= BITNET: <LUKEN@LEHIIBM1> = =
------------------------------------------------------------------------
=========================================================================
Date: Wed, 25 May 88 19:34:52 GMT
Reply-To: Malcolm Ray <[email protected]>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
Comments: Warning -- original Sender: tag was [email protected]
From: [email protected]
Subject: Slight irreverence
It certainly seems that viruses have taken a strong hold in the States.
As yet the UK has got off *relatively* lightly (howls of rage expected
from unfortunate UK victims :-). We'd like to warn our students and staff
of the dangers, and teach them some basic hygiene, but it's difficult to
do so without contributing to the panic and hype. Gentle reader, how does
one pitch the documentation?
Speaking of hype, I think the best parody of an OTT virus story came from
a friend of mine (who shall for the moment remain nameless, since I don't
have his permission for reposting). Please don't think I'm taking the subject
lightly; just staying sane:
> I actually had to replace the transformer in the power supply of
> my PC after a really nasty virus had hacked its way onto it. My
> supplier said I would have to replace major sections of the
> plastic moulding around the monitor, but it looks like I got away
> with it. I'm pretty alert when it comes to viruses: I actually
> nearly caught the blighter before it got to the transformer, but
> the bloody thing slipped up the secondary winding before I could
> zap it.
Think of that next time you hear of some punter having to replace ROMs because
some nasty program had run riot!
------------------------------------------------------------------------
Malcolm Ray JANET: [email protected]
Senior Systems Officer BitNet: [email protected]
City of London Polytechnic No other routes please!
Isn't it strange how few UK correspondents bother with disclaimers?
=========================================================================
Date: Wed, 25 May 88 20:24:52 CST
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: James Ford <JFORD1@UA1VM>
Subject: Re: Question about CRC protection
In-Reply-To: Message of Fri, 13 May 88 12:20:00 EST from <GILL@QUCDNAST>
=========================================================================
Date: Thu, 26 May 88 08:03:16 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Joe McMahon <XRJDM@SCFVM>
Subject: Mac Virus Clearinghouse
Hello all.
We've set up a sort of clearinghouse for Macintosh anti-viral software on
our LISTSERV. The files we are collecting are essentially descriptions of
known viruses, detection programs, eradication programs, and prevention
programs.
To access this, TELL LISTSERV AT SCFVM INDEX PUBLIC. That will give you
a list of the files available. We intend to stay on top of this -- we're
being cautious, but not panicing. We have only have 4 systems out of (my
guess) a couple hundred invaded, but it always pays to have the software
available.
--- Joe M.
=========================================================================
Date: Fri, 27 May 88 15:35:25 GMT
Reply-To: Malcolm Ray <[email protected]>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
Comments: Warning -- original Sender: tag was [email protected]
From: [email protected]
Subject: RE: Slight irreverence
A slip of the fingers caused Ken to send the following to me personally
instead of to the list. At his request I'm forwarding it.
==== Bite here ====
From: "Kenneth R. van Wyk" <[email protected]> 27-MAY-1988 14:24
To: MALCOLM
Subj: Re: Slight irreverence
Received:
from UKACRL by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 3655; Fri, 27
May 88 14:25:01 BS
Received: from LEHIIBM1.BITNET by UKACRL.BITNET (Mailer X1.25) with BSMTP id
3654; Fri, 27 May 88 14:25:00 B
Received: by LEHIIBM1 (Mailer X1.24) id 0769; Fri, 27 May 88 09:11:39 EDT
Date: Fri, 27 May 88 09:01:31 EDT
From: "Kenneth R. van Wyk" <[email protected]>
Subject: Re: Slight irreverence
To: Malcolm Ray <[email protected]>
In-Reply-To: Message of Wed, 25 May 88 19:34:52 GMT from <[email protected]
>We'd like to warn our students and staff
>of the dangers, and teach them some basic hygiene, but it's difficult to
>do so without contributing to the panic and hype. Gentle reader, how does
>one pitch the documentation?
I think that your example of hype (the reported virus "frying" the
transformer and all...) is about the best example of how *NOT* to
educate your students and staff about viruses! Perhaps truth would be
a much better approach; present the facts, along with common sense
precautions that people can take to reduce their risk of being stung
by a virus. Give them examples of what existing viruses have done,
and how far they've spread (the Brain virus seems as good an example
as any), and tell them how a virus spreads (by executing an infected
program - including the operating system/boot tracks, NOT by things
such as two disks coming in physical contact with one another). In
short, take the myths out of viruses for your users. Explain to them
that, by sharing programs with other users (either via disk swapping or
downloading from bulletin boards, etc.), they're taking the risk that
they may execute a program which is infected.
Above all, tell them to make backups of all of their data *FREQUENTLY*,
and to keep all shrink wrap original disks in a safe place with their
write protect tabs on.
Anyone have anything to add to this?
Regards,
Ken
------------------------------------------------------------------------
= Kenneth R. van Wyk = =
= User Services Senior Consultant = This page intentionally =
= Lehigh University Computing Center = left blank. =
= Internet: <[email protected]> = =
= BITNET: <LUKEN@LEHIIBM1> = =
------------------------------------------------------------------------
=========================================================================
Date: Fri, 27 May 88 16:05:49 GMT
Reply-To: Malcolm Ray <[email protected]>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
Comments: Warning -- original Sender: tag was [email protected]
From: [email protected]
Subject: RE: Slight irreverence
Ken, I had no intention of letting that spoof anywhere near our users! It
was intended for the sophisticates who can spot hype when they see it. My
point was exactly what you said: naive users (I don't use the term pejoratively)
are *not* getting the truth, because some people who should know better
(mostly in the computer press) are hyping it up. I had an example of this
today: a friend who's involved in a research project about distributed
operating systems tells me that his team leader is giving a talk on his work.
The other contributor is a computer journalist noted for his virus stories,
and... well, on second thoughts, I don't want to be libellous. The point is
that people *like* virus stories - they're becoming part of modern folklore
(albeit with a slightly limited audience), like alligators in the sewers and
[fill in your favourite tall story here]. Hands up who's read "Shockwave Rider"
by John Brunner. Enjoyable book, right? Think about why. Let's face it,
although I'm sure we're all agreed that virus-writing is very irresponsible
and should be countered, we all enjoy a good story about the chaos caused
(as long as it's someone else's chaos, or we've put it behind us). But their
are people who *believe* there are alligators down there...
Again, this is not to diminish anyone's problems. If your site has been
brought to its knees, commiserations :-(. I just don't want to see the
proliferation of what a colleague called "the virus scare virus". Let's
keep this list part of the cure, not part of the disease.
------------------------------------------------------------------------
Malcolm Ray JANET: [email protected]
Senior Systems Officer BitNet: [email protected]
City of London Polytechnic No other routes please!
All seems infected that the infected spy,
As all looks yellow to the jaundiced eye -- Alexander Pope
=========================================================================
Date: Fri, 27 May 88 12:17:39 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Alan J Rosenthal <[email protected]>
Subject: write-protect tabs
Recently, Kenneth R. van Wyk advised VIRUS-L readers to advise users,
among other things,
> to keep all shrink wrap original disks in a safe place with their
> write protect tabs on.
I would like to point out that many computer users are not aware that
write protection for floppy disks is often implemented in software and
therefore can be ignored by a malicious program. Any discussion of
write-protecting disks should mention this. [The program also has to
re-implement the disk io libraries, so this does greatly increase its
complexity, but many virus programs are quite sophisticated!]
In particular, the write protection on Macintosh computers is
definitely implemented in software, and I seem to vaguely remember that
it is on the IBM-PC as well. So there is hardware to read whether the
disk is write-protected or not, and a responsible program checks this
before writing.
Needless to say, I think this is a big mistake and can't see why
someone would build a disk drive like that.
Alan J Rosenthal, flaps at utorgpu
=========================================================================
Date: Tue, 24 May 88 11:09:00 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
Comments: Resent-From: "Joseph M. Beckman" <[email protected]>
Comments: Originally-From: "Joseph M. Beckman" <[email protected]>
From: "Joseph M. Beckman" <[email protected]>
Subject: Re: hunting up infected files
In-Reply-To: Message of 9 May 1988 11:05 edt from Karl-L. Noell
As an employee of the National Computer Security Center, I must point
out that we do *NOT* attempt to track perpetrators for prosecution or
for *ANY* other reason!
We are not a law enforcement Agency, and are prohibited by law to take
any such action.
We are interested in tracking the viruses (or ordinary Trojan Horses) as
they infect different sites.
As a matter of professional interest, I would be curious as to the
motivations of perpetrators of malicious code, or whether they are
members of "Hacker Clubs;" but that is information that may be conveyed
without identifying the people/organizations involved.
Joseph
=========================================================================
Date: Fri, 27 May 88 17:50:47 GMT
Reply-To: Malcolm Ray <[email protected]>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
Comments: Warning -- original Sender: tag was [email protected]
From: [email protected]
Subject: RE: write-protect tabs
IBM-PC floppy write-protect logic is hardware. If a disk is write-protected,
it's *safe*.
------------------------------------------------------------------------
Malcolm Ray JANET: [email protected]
Senior Systems Officer BitNet: [email protected]
City of London Polytechnic No other routes please!
Most people won't realise that writing is a craft. You have to take your
apprenticeship in it like anything else. -- Katherine Anne Porter
=========================================================================
Date: Fri, 27 May 88 13:23:07 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject: Monthly (starting now) greeting.
[ Last (and first) modified 27-May-88 - Ken van Wyk ]
Welcome! This is the monthly introduction posting for VIRUS-L,
primarily for the benefit of any newcomers. Apologies to all
subscribers who've already read this in the past (you'll only have to
see it once a month, and you can, if you're quick, press the purge
key...:-).
What is VIRUS-L?
It is an electronic mail discussion forum for sharing information
about computer viruses. Discussions should include (but not
necessarily be limited to): current events (virus sightings), virus
prevention (practical and theoretical), and virus questions/answers.
What isn't VIRUS-L?
A place to spread hype about computer viruses; we already have the
Press for that. :-) A place to sell things, to panhandle, or to
flame other subscribers. If anyone *REALLY* feels the need to flame
someone else for something that they may have said, then the flame
should be sent directly to that person and/or to the list moderator
(that'd be me, <[email protected]>).
How do I get on the mailing list?
Well, if you're reading this, chances are *real good* that you're
already on the list. However, perhaps this document was given to you
by a friend or colleague... So, to get onto the VIRUS-L mailing list,
send a mail message to <[email protected]>. In the body of the
message, say nothing more than SUB VIRUS-L your name. LISTSERV is a
program which automates mailing lists such as VIRUS-L. As long as
you're either on BITNET, or any network accessible to BITNET via
gateway, this should work. Within a short time, you will be placed on
the mailing list, and you will get confirmation via e-mail.
How do I get OFF of the list?
If, in the unlikely event, you should happen to want to be removed from
the VIRUS-L discussion list, just send mail to
<[email protected]> saying SIGNOFF VIRUS-L. People, such as
students, whose accounts are going to be close (like over the
summer...) - PLEASE signoff of the list before you leave. Also, be
sure to send your signoff request to the LISTSERV and not to the list
itself.
How do I send a message to the list?
Just send electronic mail to <[email protected]> and it will
automatically be redistributed to everyone on the mailing list. By
default, you will not receive a copy of your own letters. If you wish
to do so, send mail to <[email protected]> saying SET VIRUS-L
REPRO.
What does VIRUS-L have to offer?
All submissions to VIRUS-L are stored in monthly log files which can be
downloaded by any user on (or off) the mailing list. There is also a
small archive of some of the public anti-virus programs which are
currently available. This archive, too, can be accessed by any user.
All of this is handled automatically by the LISTSERV here at Lehigh
University (<[email protected]>).
How do I get files from the LISTSERV?
Well, you'll first want to know what files are available on the
LISTSERV. To do this, send mail to <[email protected]> saying
INDEX VIRUS-L. Note that filenames/extensions are separated by a
space, and not by a period. Once you've decided which file(s) you
want, send mail to <[email protected]> saying GET filename
filetype. For example, GET VIRUS-L LOG8804 would get the file called
VIRUS-L LOG8804 (which happens to be the monthly log of all messages
sent to VIRUS-L during April, 1988).
What is uuencode/uudecode, and why do I need them?
Uuencode and uudecode are two programs which convert binary files into
text (ASCII) files and back again. This is so binary files can be
easily transferred via electronic mail. Many of the files on this
LISTSERV are binary files which are stored in uuencoded format (the
file types will be UUE). Both uuencode and uudecode are available from
the LISTSERV. Uudecode is available in BASIC and in Turbo Pascal here.
Uuencode is available in Turbo Pascal. Also, there is a very good
binary-only uuencode/uudecode package on the LISTSERV which is stored
in uuencoded format.
Why have posting guidelines?
To keep the discussions on-track with what the list is intended to be;
a vehicle for virus discussions. This will keep the network traffic
to a minimum and, hopefully, the quality of the content of the mail to
a maximum. No one wants to read personal flames ad nausium, or
discussions about the pros and cons of digest-format mailing lists,
etc.
What are the guidelines?
As already stated, there will be no flames on the list. Anyone
sending flames to the entire list must do so knowing that he/she
will be removed from the list immediately.
Same goes for any commercial plugs or panhandling.
Submissions should be directly or indirectly related to the
subject of computer viruses.
Thank-you for your time and for your adherance to these guidelines.
Comments and suggestions, as alway, are invited. Please address them
to me, <[email protected]> or <[email protected]>.
Ken van Wyk
------------------------------------------------------------------------
= Kenneth R. van Wyk = =
= User Services Senior Consultant = This page intentionally =
= Lehigh University Computing Center = left blank. =
= Internet: <[email protected]> = =
= BITNET: <LUKEN@LEHIIBM1> = =
------------------------------------------------------------------------
=========================================================================
Date: Fri, 27 May 88 19:31:00 LCL
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Michael Wagner +49 228 8199645 <WAGNER@DBNGMD21>
Subject: Re: write-protect tabs
> IBM-PC floppy write-protect logic is hardware. If a disk is
> write-protected, it's *safe*.
I believe the above statement to be correct; however, many people
would disagree. I have been told that the confusion comes from
the fact that there are two levels of protection on some floppy
schemes. The write protect line is sensed and available for the
software, so the software can produce a nice message. The line is
also used, inside the drive itself, to shut down the write-current
supply, so that, even if the controller *thinks* it is writing, it
isn't. I believe this is the scheme used on the PC.
Disclaimer: I don't have a PC, nor access to the documents to
prove or disprove this 'fact'.
Michael
=========================================================================
Date: Fri, 27 May 88 13:15:51 CDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: CB Lih <CL06076@UAFSYSB>
Subject: Write protect
So what's the deal? Can software override the Mac protect tab? Are y'all
sure about IBM? What about other computers?
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Sincerly, and I mean that,
=---> CB Lih <---=
User Services -> Computing Services -> University of Arkansas -> Fayetteville
CL06076@UAFSYSB Disclaimer: There's a hole in my ozone layer.
=========================================================================
Date: Fri, 27 May 88 15:57:38 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Terry Sanderson <SANDERS@UTORONTO>
Subject: Re: write-protect tabs
In-Reply-To: Message of Fri, 27 May 88 19:31:00 LCL from <WAGNER@DBNGMD21>
Having stated this on the list once before, the topic has again arisen.
IBM PC Floppy disks CANNOT be written to when there is a WRITE-PROTECT
tab on the disk.
I DO have access to technical docs, schematics, etc., and there is NO WAY
the software can change this fact. The hardware provides a signal to the
operating system that there is in fact a write-protect tab on the disk,
but it cannot chance or override the protection.
I hope this clears up any questions.
Terry P. Sanderson P.Eng.
[email protected]
[email protected]
=========================================================================
Date: Fri, 27 May 88 16:30:00 EST
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: PHREADDE <PDAVIS@BINGVAXA>
Subject: bad tabs
I disagree, on the IBM you can write on disks protected with CERTAIN write
protect tabs. A while back, certain manufacturers produced red see-thru
tabs that provided no protection. Those manufacturers have switched back
to silver-backed black tabs. I have used the old ones and definitly written
to files. This, however, should not be a problem currently. No one that
I know of produces these thin red tabs now. If you have the old ones,
discard them; they are ineffectual.
And to all readers and contributors on this list, I would like to thank
you for your work and questions. A virus did hit our school, and was
completely vanquished within a few days. The methods that we used now
help us protect our classroom software against accidental mistakes as well
as future viruses. Public software is always vunerable to tapering, but
we feel much more protected these days. Thanks again.
Phreadde Davis
State University of NY - Binghamton
=========================================================================
Date: Fri, 27 May 88 14:44:00 PDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: WATKINS@UCRVMS
Subject: Write Protect
No, as far as I know (which is reasonably far), a Macintosh cannot
override a write protect tab (or whatever the term is for 3.5" disks);
I mean, unless it's been concealed all this time it can't be done..
And a couple cents worth (I hope) of stuff on defending against
Mac viruses...maybe this was covered earlier, but remember that there are
some resources in the system file that are duplicated in rom (for instance,
chicago 12, geneva 12 (I think), some wdefs, etc. Now if I was to write
a virus, I'd think that these places would be pretty keen for hiding my
code. (hmm, maybe I should clarify a bit, what happens is the mac
first checks to see if a resource is in rom and uses it if it can, so if
you garbaged up the fonts with your virus code, nobody would notice. It's
pretty easy to bypass the rom resources though so you could load this stuff
and jump to it pretty easily...)
I hope that made some sense...
Kevin Lund [email protected]
kevin@hope.uucp
=========================================================================
Date: Tue, 24 May 88 08:01:00 MDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
Comments: Warning -- original Sender: tag was [email protected]
From: Keith Petersen <[email protected]>
Subject: FLUSHOT-Plus withdrawn from SIMTEL20 archives
I have decided to remove FluShot-Plus from our SIMTEL20 archives
because of the continuing problem of programming bugs. It is *not* a
Trojan or Virus. The author just needs to get his bugs fixed.
I recommend to all recipients of this message that they discontinue
use of *any* version of Flushot or Flushot-Plus.
--Keith Petersen
Maintainer of the MSDOS archives at SIMTEL20.ARPA
---forwarded message---
Date: Tuesday, 24 May 1988 08:20-MDT
From: <esheric at sandia-2.arpa>
Reply-To: <esheric at sandia-2.arpa>
To: w8sdz <w8sdz>
cc: esheric at sandia-2.arpa
Re: Flushot plus bugs
>From: Glenn Larsen <glarsen@note.nsf.gov>
>I had only one problem with Flu Shot 3 which was downloaded from SIMTEL
>in Nevada. The problem was when using the option to protect the CMOS were
>configuration information is stored with battery backup.
Here in Albuquerque a local BBS SYSOP complained that FLUSHOT3 was actually
a Trojan Horse program itself and was responsible for trashing his hard disk.
Since it seemed like a legit program to me, based on the well documented
sources of the program uploaded to SIMTEL20, I decided to take a little time
and dis-assemble FLUSHOT3 and see if I could see any trouble. What I found
was a program that, in my opinion, was loaded with bugs. One of the bugs I
found was in the CMOS restore section: FLUSHOT3 screws up and replaces the ES
register with the DS value when it returns from this routine.
Summary of BUGS and/or omissions in FLUSHOT3 detected as of May 1, 1988:
Bugs which can cause significant damage:
1. Stack corrupted in Int 26h handler: should return via RETF,
which should leave flags on stack, but instead returns via
RETF 2, thereby discarding flags.
2. Restoring CMOS memory after checking improperly restores
the es segment register : es is replaced by ds
3. Program assumes direction flag is cleared (forward).
Less damaging bugs:
4. Incorrect memory size (2 times amount req'd) in install
5. Interrupts are enabled for no reason in FCB test
Condom holes: Bugs or ommissions that make program ineffective
6. Incorrect jmp instruction disables ASCIIZ rename checking
7. No check of AT bios int 13h "Write long" call (0bh)
No checks for XT int 13h format calls 6 and 7
8. No accommodation for extended FCB format
9. No checks for direct IO via IOCTL call 44h
10. Program fails to detect FCB file delete and renaming
functions that can affect critical files if wild
cards are used.
Loose ends:
11. Invalid error codes returned by int13h and int26h
12. Error code returned by failed FCB calls is unknown
13. Failures are not handled consistently - FCB calls return
to program while others force a program terminate.
14. No checks for existence of CMOS RAM before reading and/or
attempting to restore it. What happens on non AT's? [Since
the user has to specifically request this check, one could
argue it would be his/her own fault to invoke it on a machine
that doesn't have the CMOS memory.]
FluShot Plus, version 1.2 is significantly better, but it still has
some problems: What I've found as of May 14, 1988:
Bugs which can cause significant damage:
1. Stack corrupted in Int 26h handler (fails to leave old
flags on stack as it should)
Condom holes: Bugs or omissions that make program ineffective
2. No check of XT bios int 13h format functions 6 and 7
3. No accommodation for extended FCB format
4. No checks for direct IO via IOCTL call 44h
Loose ends:
5. Invalid error codes returned by int 13h and int 26h failures
6. No checks for existence of CMOS RAM before reading and/or
attempting to restore it. What happens on non AT's? [Since
the user has to specifically request this check, one could
argue it would be his/her own fault to invoke it on a machine
that doesn't have the CMOS memory.]
7. Overall the program coding is bit sloppy. Since it doesn't make
any attempt to optimize usage of the segment registers, it is a bit
longer and slower than it needs to be.
Final comments:
What else can I say? I'm not going to claim to be the world's finest
programmer and that I could do a better job. I may well be dead wrong
in identifying some of the code as bugs. However I would suggest that
if you are planning on using FLUSHOT xxxx, back up your hard disk first.
PS:
I downloaded the latest FSP_12.ARC from SIMTEL20 tonight to make sure
that it was the same as what we had gotten off local boards here in
Albuquerque. Unfortunately, the FSP.COM file was different! A quick
check, however, reveals that the only difference was the addition of a
CMP AL,"?" and JE xyz pair of instructions in the filename compare
subroutine. The Int 26h stack bug was still there.
Albq. version of FSP.COM: 10309 bytes CRC = BDCE 27 April 88
SIMTEL20 version : 10313 bytes CRC = 9723 27 April 88
Peter Esherick
Sandia National Labs, Albuquerque
<[email protected]>
=========================================================================
Date: Sat, 28 May 88 13:29:00 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Stan Horwitz <V4039@TEMPLEVM>
Subject: Re: bad tabs
In-Reply-To: Message of Fri, 27 May 88 16:30:00 EST from <PDAVIS@BINGVAXA>
Write protect tabs to prevent tamporing of disks is plain silly. All
any prankster need do is to remove the write protect tab from the disk to
sabatage a disk. When done, it's a simple matter to stick a new write
protect tab back on the damage disk. A better solution is to use notchless
disks and write to them on a machine altered so it won't complain about the
disk. If memory serves, I believe I have heard that write protect tabs can
also fail when they are sqeezed or bent in a certain way due to age but I am
not sure of this.
Stan Horwitz
Mainframe Consultant
Disclaimer -- Who me? I didn't say that?
V4039%TEMPLEVM.BITNET at cunyvm.cuny.edu
Temple Univeristy
Philadelphia, Pennsylvania USA
=========================================================================
Date: Sat, 28 May 88 17:20:00 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
Comments: Resent-From: [email protected]
Comments: Originally-From: [email protected] (Bill.Stewart.<ho95c>)
From: [email protected]
Subject: Warning: Flushot4 is a virus!
A program called Flushot4 was recently seen on a BBS out west.
Ross Greenberg's Flushot versions don't go up that high, and this one
was apparently a virus advertising itself as vaccine. So if you see
it, don't use it, don't trust anything from the machine it's on,
call the operator of the machine you see it on, etc.
--
# Thanks;
# Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
# Computers - Nasty, disturbing, uncomfortable things!
# Make you late for dinner. or breakfast.
=========================================================================
Date: Sat, 28 May 88 19:06:50 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: [email protected]
Subject: Naive virus questions
1) Is it possible to demount and mount the hard disk so that you
can effectively work with the floppy drives and not have to worry
about code being transferred to the hard disk?
2) Is it possible to design a virus that screws up the ROM?
Hey, these may seem naive, but then I'm not a computer scientist
by trade.
=========================================================================
Date: Mon, 30 May 88 17:55:00 LCL
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Michael Wagner +49 228 8199645 <WAGNER@DBNGMD21>
Subject: Re: write-protect tabs
Terry Sanderson <SANDERS@UTORONTO> writes:
> IBM PC Floppy disks CANNOT be written to when there is a
> WRITE-PROTECT tab on the disk.
>
> I DO have access to technical docs, schematics, etc. The hardware
> provides a signal to the operating system that there is ... a
> write-protect tab on the disk, but it cannot ... override the
> protection.
Terry: Perhaps an overview description of the form of protection,
where it is provided (in the drive itself, or in the interface
hardware) and whether this protection can also be expected to be
in clones would help clarify the situation.
Michael
=========================================================================
Date: Mon, 30 May 88 12:01:00 EST
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: GILL@QUCDNAST
Subject: RE: Hard disk disable
David Slonosky asked about a disable for a hard disk
In answer to your submission to VIRUS-L (at least part 1), there is a
program on the MSDOS disk called BOOTF. If I understand it correctly (i.e.
read the manual), it will software disable the harddisk so that any program
running from floppies doesn't see the harddisk. This was written because some
old commercial programs used a copy-protection scheme that crashed their
program when run on a machine with a harddisk. Really dumb, eh!!
However, since this is a software disable, I suppose it can be
circumvented by a virus checking for this kind of thing. Those more
knowledgable could perhaps comment on that.
____________________________________
Arnold Gill | If you don't complain to those who |
Queen's University at Kingston | implemented the problem, you have |
gill @ qucdnast.bitnet | no right to complain at all ! |
------------------------------------
=========================================================================
Date: Tue, 31 May 88 07:39:31 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Kenneth Ng <[email protected]>
Subject: write protect tab on floppies
>From: [email protected]
>
>IBM-PC floppy write-protect logic is hardware. If a disk is write-prot
>ected
>it's *safe*.
>
Well, not always. I recall talk/flames several months back about a certain
type of floppy disk drive (which one escapes me). Evidently
the write protect hardware worked by sensing the reflection from
the write protect tab to determine that the floppy was write
protected. Evidently the designer never heard of black write
protect tabs or of floppy disks that are manufactured without
write protect slots. Remember to always check *EVERYTHING*
the manufacturer claims before you need to.
=========================================================================
Date: Tue, 31 May 88 10:52:07 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject: First of two forwarded submissions
The following is taken from a newspaper people's magazine, and
describes some effects found in viruses that are different that I
had seen up till this time.
Quoted without permission from Editor and Publisher, May 21, 1988
_Computer_Virus_Hits_First_U._S._Newspaper_
by Mark Fitzgerald
A computer virus has finally infected a newspaper computer
system. The Providence Journal-Bulletin discovered the virus
late on Friday May 13 when reporter Froma Joselow's personal
computer disc was destroyed, the newspaper's systems engineer,
Peter Scheidler, stated.
"Her file allocation table was overwritten in a rather
unusual way - it was all zeros," Scheidler said in a telephone
interview. "Then this message appeared."
The message included the name of a Lahore, Pakistan company,
"Brain Computer Services," a 1986 copyright, the name of the two
brothers who own the store - Basit and Amjad - plus the address
of the store and its telephone.
In the middle was this chilling message: "Welcome to the
Dungeon ... Beware of this VIRUS. Contact us for a vaccination."
[The article goes on to say that about 100 disks were infected,
that the virus was contained totally in the boot block and that
overwriting of the boot block cleared the disks. Other
information in the story is no news to us.
The only new thing to me is that my understanding of this
"Brain" virus is that it was harmless, apparently not so with
this implementation.
Len Levine
[email protected] ]
------------------------------------------------------------------------
= Kenneth R. van Wyk = =
= User Services Senior Consultant = This page intentionally =
= Lehigh University Computing Center = left blank. =
= Internet: <[email protected]> = =
= BITNET: <LUKEN@LEHIIBM1> = =
------------------------------------------------------------------------
=========================================================================
Date: Tue, 31 May 88 10:53:45 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject: Second forwarded submission
>IBM-PC floppy write-protect logic is hardware. If a disk is write-protected,
>it's *safe*.
Well, yes and no. If you mean that a virus cannot write to a hardware
protected diskette, you are quite right (although one should never say
never :-)). However, it should be pointed out that hardware write
protection can fail to work. Most floppy drives detect the presence
of a write-protect notch with a mechanical or optical device. These
devices are subject to failure.
As a case in point, we purchased some 5.25 inch red floppy diskettes that
did not have write-protect notches. We wanted to distribute site-licensed
software, while making sure the software was returned to use in the same
condition as when checked out. In order for us to put the site-licensed
software on the diskettes, we altered a floppy drive by temporarily removing
the mechanical switch that determined whether the floppy was write-protected.
In the process, we found that one of our *UNaltered* drives read this
write-protected diskette! It turned out that this drive used an optical
means of sensing the status of the write-protect notch, and the light
traveled through the red jacket of the floppy diskette. Although the
diskette was write-protected, the hardware failed to detect this. I
understand that some translucent write-protect tabs cause the same problem.
The point is that a write-protected diskette is not completely immune
from infection.
---------------------
John L. Cofer
[email protected]
------------------------------------------------------------------------
= Kenneth R. van Wyk = =
= User Services Senior Consultant = This page intentionally =
= Lehigh University Computing Center = left blank. =
= Internet: <[email protected]> = =
= BITNET: <LUKEN@LEHIIBM1> = =
------------------------------------------------------------------------
=========================================================================
Date: Tue, 31 May 88 10:55:14 EDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject: Did I say two? I meant three forwarded submissions... :-)
RE: FLUSHOT4 IS VIRUS.... It is not. It is a hacked version of the
program by Ross Greenberg; it is Trojan Horse since it does not
replicate itself. Some chutzpahnik took a hacked version of TXT2COM
utility for making executable text files. The hacked program does things
that the original utility does not- like wipe out all files on the
same drive from which it is run.
The hacked TXT2COM was used on the FLUSHOT docs (which are ASCII)
to make the FLUSHOT into the Trojan Horse.
RE: Nomenclature.... A reminder that in discussing malicious programs
on a serious level, it helps to keep our terms straight. Remember, the
trait that makes a program a virus is its ability to replicate its
code, usually INTO other, valid, programs. (A case of the un-common
code. %-)) There are also automated Trojan Horses, such as the trouble-
some version of CHRISMAS EXEC which are often called viruses. Some
computer scientists have taken to calling these automated Trojans
"bacteria". Also, it is good to remember that not all programs that
wreck files, etc. are Trojans or viruses. There are a lot of buggy
programs out there. For example, there is a debate about NOTROJ; some
people have gotten burned by it, others have no problems. It may be that
it was not designed to be harmful, but has bugs that make it harmful on
many systems.
RE: NAIVE QUESTIONS.... There no dumb questions that are asked (in the
right place and time). The dumb question is the one that should have
been asked but never was.
As for the question about disconnecting the hard drive nad running
floppies only is fesible and recommended for maxiumum protection while
testing new programs. It is not a method suitable for everybody (sort
of like GRAPE NUTS<Tm> cereal). But even malicious programs that can
overide software hard disk write protects can not override an open
circuit. The trouble is the setting up and the cases where the software
needs the capacity of a hard disk. My dream scenario would be cheap
disposible hard disks for testing purposes. Electronic Petri Dishes.
Thank you, J.D. Abolins
------------------------------------------------------------------------
= Kenneth R. van Wyk = =
= User Services Senior Consultant = This page intentionally =
= Lehigh University Computing Center = left blank. =
= Internet: <[email protected]> = =
= BITNET: <LUKEN@LEHIIBM1> = =
------------------------------------------------------------------------
=========================================================================
Date: Tue, 31 May 88 16:31:07 CDT
Reply-To: Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
From: Werner Uhrig <[email protected]>
Subject: Playboy virus - BEWARE! (thomas@uvabick (Thomas Fruin))
[comp.sys.mac]
From: [email protected] (Thomas Fruin)
Newsgroups: comp.sys.mac
Subject: Playboy virus - BEWARE!
Message-ID: <[email protected]>
Date: 30 May 88 23:19:47 GMT
Through a dealer I heard that a new Macintosh virus had been sighted
here in the Netherlands, in Utrecht to be precise. It was called
Playboy or something similar, and after double clicking rapidly
started showing you pictures of benevolent nude girls, while it was
malevolently busy erasing your hard disk ...
This is all I know. Just be sure to fight your desire to launch
this nasty.
-- Thomas Fruin
[email protected] University of Leiden
[email protected] University of Amsterdam
[email protected]
hol0066.AppleLink
2:512/114.FidoNet The Netherlands
|
|
|
To the best of our knowledge, the text on this page may be freely reproduced and distributed.
If you have any questions about this, please check out our Copyright Policy.
totse.com certificate signatures
|
|
|
About | Advertise | Bad Ideas | Community | Contact Us | Copyright Policy | Drugs | Ego | Erotica
FAQ | Fringe | Link to totse.com | Search | Society | Submissions | Technology
|
|
|
|
|
|
|
TSHIRT HELL T-SHIRTS
|
