sean@ms.uky.edu (Sean Casey) (01/02/89)
The IRQ virus is definitely harder to get rid of, but at least it doesn't intentionally try to damage anything. I wonder if it would have been detected so easily if it didn't put that message in the border! [an excerpt from BIX] >One more item on the IRQ virus. If it can't attack your Startup-Sequence >it will home in on C:DIR just to be sure that it gets executed. >This is a benign intruder that can mutate to something real nasty in the >hands of a sicko. We have the start of a real problem here. >Djj This is only the beginning. Look at the IBM PC viruses out there. They do everything from say "hello" to doing a low level hard disk format (bypassing the OS) after a wait period of 3 months. It's really bad. There are now tens of programs that hunt down viruses, and they are constantly out of date. Now consider the complexity and nature of MS-DOS and AmigaDOS, and it's easy to see how much more fun it would be to write viruses for the Amiga. It's going to get a whole lot worse before it gets better. The biggest light at the end of the tunnel is probably a protected mode OS with enforced privileges. Once debugged, at this would at least protect the system files from a user running a virus. STEVE I don't have your address. What I would do about the IRQ virus is patch into the AmigaDOS code that reads in disk hunks to be executed, and scan for any and all known "rider" viruses just before execution is handed off to the hunk. You should realize that sooner or later, one of the viruses is going to attempt to disable virusx! Better make plans for that possibility... Sean -- *** Sean Casey sean@ms.uky.edu, sean@ukma.bitnet *** Who sometimes never learns. {backbone site|rutgers|uunet}!ukma!sean *** U of K, Lexington Kentucky, USA ..where Christian movies are banned. *** ``My name is father. You killed my die. Prepare to Inigo Montoya.''
dbk@fbog.UUCP (Dave B. Kinzer @ Price Rd. GEG) (01/05/89)
[Do line eaters eat viruses? Line eater vanquished, Big Net Virus shows up.]
I would like to contribute some ideas on how to reduce the spread of
the new strain of virus. Not being intimate enough with the system internals
to implement all these ideas, I feel that this information in the hands
of a net.guru will perhaps result in a new weapon in the war on viruses.
First some background info.
Virus writers take advantage of anything known about a system. For
example, the first Amiga virus hid in some unused memory and was held
in a boot block of known format. The point I'm making is, the weapon
that we fashion here should not be something that a virus writer can
count on.
Viruses spread through their latency. The latency is the time between
infection and detection. Reduction of this time will reduce the spread.
The scheme I present here will not prevent a virus from attacking a
system, rather it is a way of detecting the damage done by a virus. This
will at least alert a user that something is wrong. This should slow down
the rate of spread, even if it does not stop it. Of course this could
be combined with programs that search out specific virusus for more
complete protection.
The idea is to keep more complete information around about all the
files on a disk. OK, nothing earth shattering here, but the specific
suggestions that follow will make it very hard for a virus writer to
circumvent.
1) Since we are going to keep a file on disk, the name should be user
configurable.
2) The data file should be encrypted (NES one-key preferred). It almost
goes without saying that the key should be user configurable.
3) Data should contain file length.
4) Data should keep track of the hunks, overlays or whatever in each file.
5) Data should contain two different CRC checks of the file using user
configured polynomials.
6) The virus detection program should have a user configurable name.
7) Any ports used should have a user configurable name.
8) The program distribution should be in object module format with a
mini-linker which randomizes the (hopefully small) modules making
detection of the virus detector program difficult. Random length
modules (with random or better yet duplicate fill) could be created
so the length ends up random. The linker could also prompt for
all the user configuration data.
9) Manual invocation and possibly automatic call on disk insertion.
10) Program to output (possibly to window with drag bar [random window
structure names :-)]) the New Files, Deleted Files and Changed Files.
Included in the output should be some user configured text so a
virus has a hard time faking this. Program would then calculate
new checksums for new and changed files (except checksum file ;-))
upon reciept of user OK.
Note that there is very little for a virus writer to count on in the
above. As long as the password data is kept out of his hands (might have
to be kept encrypted in a program that looks for diskchange, [and thus
is resident in memory] since the virus could get it from there [hint hint,
also flush variables]), the above procedures make a 'standard solution'
which would be hard to beat.
Running the program (via amicron or dcron) nightly on a hard disk would
reduce the virus latency to 24 hours, significantly reducing the spread.
This might be an application for a two-key encryption system so that
a password on the command line (in the cron file) would not unlock
the data file directly.
A note to anyone who might like to take it upon themself to write a
utility like this. Assume the virus writer has your commented source
code, knows how to manipulate the system hardware directly, and knows
where you have your program stored.
Known hole in above scheme: Programs that have just been written to disk
are available for attack since no CRC's have been computed for them yet.
Anyway, just some ideas that can be taken and run with. Anyone else
out there with some suggestions?
| // GOATS - Gladly Offering All Their Support Dave Kinzer (602)897-3085|
| // >> In Hell you need 4Mb to Multitask! << uunet!nud!fbog!dbk |
| \X/ #define policy_maker(name) (name->salary > 3 * dave.salary) |paolucci@snll-arpagw.UUCP (Sam Paolucci) (01/07/89)
If I understand correctly how the IRQ virus works, I just had a thought about possible future spread of such viruses which monkey around with executable files. Why not have the executable generate its own checksum when the code is generated, and have this checksum reside in the executable itself. Then when the program is started up the first thing it does is compute its checksum and it checks the result with the one stored in the code. If the two match then it runs, otherwise it doesn't and a message to that effect could be printed out. The only possible problems that I see with the above are: a) presently one would have to have the checksum routines in their executables making the codes slightly larger. I guess _main() could be modified to accomplish this. b) it would take a little longer for the program to fire up since it has to compute its checksum before it starts executing. However note that if the code is made resident than it would be possible to not recompute the sum every time the code is re-executed.-- -+= SAM =+- "the best things in life are free" ARPA: paolucci@snll-arpagw.llnl.gov
w-colinp@microsoft.UUCP (Colin Plumb) (01/08/89)
In article <27@snll-arpagw.UUCP> paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: >Why not have the executable generate >its own checksum when the code is generated, and have this checksum >reside in the executable itself. Then when the program is started up >the first thing it does is compute its checksum and it checks the >result with the one stored in the code. If the two match then it >runs, otherwise it doesn't and a message to that effect could be >printed out. The problem with this is that it makes it a lot harder for me to, say, patch the binary to get rid of a DF1: hard reference or similar thing, and most importantly, the checksum doesn't get computed until _main gets called, and the virus patches itself in before that. Thus, the virus has already done its dirty work, so the warning isn't as useful, and, if sufficiently clever, it may delete itself from the program being run so the checksum turns up negative. You want some external means of certifying a program good. This is also why the checksum program should print out the computed checksum, and not take an argument to comapre it with, even though this makes shell scripts somewhat more difficult, lest the virus find and patch it to return "good" at all times. -- -Colin (uunet!microsof!w-colinp)
peter@sugar.uu.net (Peter da Silva) (01/08/89)
In article <27@snll-arpagw.UUCP>, paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: > Then when the program is started up > the first thing it does is compute its checksum and it checks the > result with the one stored in the code. If the two match then it > runs, otherwise it doesn't and a message to that effect could be > printed out. I don't think that would even catch the IRQ virus, because it sticks all the program's code in a data hunk... which when loaded should end up with the right checksum. If it actually went to disk to re-read itself, then the virus could fake a copy of the original in RAM. -- Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. ...texbell!sugar!peter, or peter@sugar.uu.net 'U`
limonce@pilot.njin.net (Tom Limoncelli) (01/09/89)
In article <27@snll-arpagw.UUCP> paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: > If I understand correctly how the IRQ virus works, I just had a > thought about possible future spread of such viruses which monkey > around with executable files. Why not have the executable generate > its own checksum when the code is generated, and have this checksum > reside in the executable itself. Then when the program is started up > the first thing it does is compute its checksum and it checks the > result with the one stored in the code. If the two match then it > runs, otherwise it doesn't and a message to that effect could be > printed out. > ARPA: paolucci@snll-arpagw.llnl.gov Yeah! In fact, why don't we add a checksum to the boot block? :-) (Sorry, I just had to say it) -Tom -- Tom Limoncelli Drew University Madison NJ 201-408-5389 tlimonce@drunivac.Bitnet limonce@pilot.njin.net "Fences make good neighbors" -Frost "I want an MMU" -Me Standard disclaimer? No, we're still on the dpANS disclaimer.
paolucci@snll-arpagw.UUCP (Sam Paolucci) (01/09/89)
In article <3243@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: ->In article <27@snll-arpagw.UUCP>, paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: ->> Then when the program is started up ->> the first thing it does is compute its checksum and it checks the ->> result with the one stored in the code. If the two match then it ->> runs, otherwise it doesn't and a message to that effect could be ->> printed out. -> ->I don't think that would even catch the IRQ virus, because it sticks all the ->program's code in a data hunk... which when loaded should end up with the ->right checksum. If it actually went to disk to re-read itself, then the virus ->could fake a copy of the original in RAM. Ideally the checksum should be done by the startup code, and all the hunks should be included in the check. ->-- ->Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. ->...texbell!sugar!peter, or peter@sugar.uu.net 'U` -- -+= SAM =+- "the best things in life are free" ARPA: paolucci@snll-arpagw.llnl.gov
dan-hankins@cup.portal.com (Daniel B Hankins) (01/09/89)
Re self-checking programs: Not effective. The virus prepends itself to the program. After the virus executes, *then* in loads the regular program and runs it. The regular program never knows the virus was there. The checksum matches. Dan Hankins
wdao@castor.usc.edu (Walter Dao) (01/10/89)
hmmmm let me think ....
YEAAAHHH !!!
how about fighting fire with fire ?
lets write a virus counter virus ?
lets have somewhere in the program a checksum of the program calculated by I
dont know what mean and stored at a fixed offset from the start of the
executable code.
the checksum is calculated only once when the program is finished.
(like at the same time as ATOM ....) and then the chcksm is merged to the
esecutable code itself.
then have pseudo virus in the amiga ram that acts like a virus that does the
following :
1) when a prg has to be loaded ,
recalculate the whole chcksum (I am not going to go in deep but you get
the idea).
2) get the checksum we got and which is imbedded in the code.
3) compare . if same then ok , everything is fine.
othewise, the code is not the same .
what the IRQ virus could do .
- After the irq merges itself with the code, recalculate the chcksum.
(they will have to have the right formula to calculate the chcksum).
but to much of a hassle ....
well that was on top of my head ...
D . W .peter@sugar.uu.net (Peter da Silva) (01/10/89)
In article <28@snll-arpagw.UUCP>, paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: > Ideally the checksum should be done by the startup code, and all the hunks > should be included in the check. The IRQ Virus replaces the startup code. By the time the real startup code gets in charge, the virus has done its dirty-work and hidden. -- Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. ...texbell!sugar!peter, or peter@sugar.uu.net 'U`
paolucci@snll-arpagw.UUCP (Sam Paolucci) (01/10/89)
In article <13341@cup.portal.com> dan-hankins@cup.portal.com (Daniel B Hankins) writes:
->Re self-checking programs: Not effective. The virus prepends itself to
->the program. After the virus executes, *then* in loads the regular program
->and runs it. The regular program never knows the virus was there. The
->checksum matches.
Not if the checksum code is part of the startup code.
->Dan Hankins
--
-+= SAM =+-
"the best things in life are free"
ARPA: paolucci@snll-arpagw.llnl.govgay%elde.epfl.ch@cunyvm.cuny.edu (David Gay) (01/10/89)
Instead of doing a checksum, why not check the size of the executable file ? This would still allow you to "newzap" the file, but should detect any virus which prepends itself to the executable (though it could still search for a convenient block of nulls ...). David Gay GAY@ELDE.EPFL.CH$
jms@antares.UUCP (joe smith) (01/10/89)
In article <28@snll-arpagw.UUCP> paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: > Then when the program is started up > the first thing it does is compute its checksum and it checks the > result with the one stored in the code. If the two match then it > runs, otherwise it doesn't and a message to that effect could be > printed out. > >Ideally the checksum should be done by the startup code, and all the hunks >should be included in the check. > -+= SAM =+- You realize, of course, that the expected checksum has to be stored in the file. It has to be where the checksumming routine can find it, to do the compare. If the checksumming routine was a standard library routine called from _main, then it is a trivial task for a virus to start at _main, locate the checksumming routine, locate the checksum word, and modify it. Which means that your checksum protection has been rendered worthless. Or, the virus could locate the JSR that calls the checksumming routine and replace it with a NOP. Again, disabling the protection. Here's another monkey-wrench. When AmigaDOS loads the program, the various hunks get loaded into noncontiguous memory. The loader applies 16-bit and 32-bit relocation to words on the hunks that point to other hunks. This means that the in-memory copy of the program does not look like the on-disk copy. Unless you can locate all words subject to relocation, and have the checksumming routine cancel the effect of the loader's modifications, you will not be able to get a consistent checksum out of the im-memory copy. Although programs are provided with the name of the command that started them, AmigaDOS does not include the directory name. This means that you cannot reliably locate the on-disk copy of the program to check it. Even if you search through the path list, a really nasty virus can do all its dirty work and write out a good copy of the program to RAM: so that it looks like the program was invoked from an uninfected copy. The only thing I would trust along these lines would be seperate utility and checksum list stored on a write-protected disk that watches over the files I'm concerned about. One program can be trusted to check another, but you can't rely a program being able to check itself. -- +----------------------------------------------------------------------------+ | TYMNET:JMS@F29 CA:"POPJ P," UUCP:{ames|pyramid}oliveb!tymix!antares!jms | | INTERNET:(Real Soon Now) Amiga Hacker PHONE:Joe Smith @ (408)922-6220 | +----------------------------------------------------------------------------+
bjc@pollux.UUCP (Betty J. Clay) (01/11/89)
In article <330@antares.UUCP> jms@antares.UUCP (joe smith) writes: >In article <28@snll-arpagw.UUCP> paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: (most of discussion of checksumming deleted) > >The only thing I would trust along these lines would be seperate utility >and checksum list stored on a write-protected disk that watches over the >files I'm concerned about. One program can be trusted to check another, >but you can't rely a program being able to check itself. There exists already a program that will check the Workbench items that are not likely to be changed by the user - the C: commands, the libraries, the devices and handlers. Jim Butterfield, well-known for nifty utilities for Commodore computers since l978, wrote a program called SysCheck as an aid in moving things over to 1.3. He uses both the size of the program and its checksum in culling out the items on a disk that are not the release version of 1.3. It now turns out that SysCheck also makes a dandy program for checking out the workbench against the IRQ virus. SysCheck is available on CIS, AmigaTech Forum, and is on many bulletin boards as well. It is well worth the effort it takes to download. Betty
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (01/11/89)
In <29@snll-arpagw.UUCP>, paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: >In article <13341@cup.portal.com> dan-hankins@cup.portal.com (Daniel B Hankins) writes: >->Re self-checking programs: Not effective. The virus prepends itself to >->the program. After the virus executes, *then* in loads the regular program >->and runs it. The regular program never knows the virus was there. The >->checksum matches. > >Not if the checksum code is part of the startup code. > Huh? If a virus is prepended as a code section, the startup code _is_ part of the virus code. -larry -- Frisbeetarianism: The belief that when you die, your soul goes up on the roof and gets stuck. +----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca or uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------------+
bill@cbmvax.UUCP (Bill Koester CATS) (01/12/89)
In article <2301@nunki.usc.edu> wdao@castor.usc.edu (Walter Dao) writes: >hmmmm let me think .... > >YEAAAHHH !!! > >how about fighting fire with fire ? >lets write a virus counter virus ? > Not this again. Let's put out the fire with an A-Bomb!! > >then have pseudo virus in the amiga ram that acts like a virus that does the >following : >1) when a prg has to be loaded , > recalculate the whole chcksum (I am not going to go in deep but you get > the idea). >2) get the checksum we got and which is imbedded in the code. >3) compare . if same then ok , everything is fine. > othewise, the code is not the same . > >what the IRQ virus could do . >- After the irq merges itself with the code, recalculate the chcksum. > (they will have to have the right formula to calculate the chcksum). > but to much of a hassle .... > Nothing ever seems to be TOO much of a hassle for the average virus writer. All they have to do is get the right checksum routine to break this method. Just say NO to anti virus viruses! > BK -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Bill Koester (CATS) >>Commodore Amiga Technical Support<< Commodore International Ltd. UUCP {allegra|burdvax|rutgers|ihnp4}!cbmvax!bill PHONE (215) 431-9355 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= The official word, is NO. I am therefore going anyway! Kirk - Star Trek III Pleese desrigard eny spealing airors!!!!!!! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
kurt@tc.fluke.COM (Kurt Guntheroth) (01/12/89)
The major problem with anti-virus tools is that once their action is known, they can be got around. The virus either hides in a new and previously untested way, or it actively attacks the immune system (what a wonderful analogy), by killing, maiming or subverting the anti-virus program. Of all the suggestions I have heard so far, the only one that seems to me to be practical is doing a size and checksum on system programs. This is a good plan because it is difficult to defeat by virii that simply hide. If anyone does a program like this, there are some things to remember 1. For safety's sake, the checker program must not have its own name or the names of any data files it uses compiled in. That is, the names must be set when it is invoked (as in command line args or tooltypes). Otherwise, virii can identify the program by knowing its name and delete or subvert it. Same thing for the data file. 2. Ideally, even the length of the program should be variable, perhaps using an initialization program, to make identification more difficult for the virus author. 3. The inner workings of the program should not be publicized. This will give a brief respit before it is decoded by the virus authors. 4. It is important that people know and trust the disseminator of the program and the distribution system as well. What a wonderful way to insert a new virus -- by claiming it offers immunity. It will not be possible to eliminate virii from computers completely, either now or in the future. The features of an OS that make it usable also make it susceptible to attack by a malicious program. Hopefully we can make such programs more difficult, so that would-be computer vandals and crackers decide to stick to more traditional forms of vandalism, like writing "IBM Sucks Silicon" on walls of computer centers.
dan-hankins@cup.portal.com (Daniel B Hankins) (01/12/89)
In article <6434@louie.udel.EDU> gay%elde.epfl.ch@cunyvm.cuny.edu (David Gay) writes: >Instead of doing a checksum, why not check the size of the executable file >? This would still allow you to "newzap" the file, but should detect any >virus which prepends itself to the executable (though it could still >search for a convenient block of nulls ...). It's worse than that. The virus could compress the program (using something as simple as Huffman or as complex as adaptive arithmetic coding), and then prepend itself to the file. Of course it would add some noise in order to pad the file out to its original length (and possibly checksum). Then, when the virus gets control, it does its stuff then decompresses and loads the legitimate program. Dan Hankins
jms@antares.UUCP (joe smith) (01/13/89)
In article <29@snll-arpagw.UUCP> paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: >In article <13341@cup.portal.com> dan-hankins@cup.portal.com (Daniel B Hankins) writes: >->Re self-checking programs: Not effective. The virus prepends itself to >->the program. After the virus executes, *then* in loads the regular program >->and runs it. The regular program never knows the virus was there. The >->checksum matches. > >Not if the checksum code is part of the startup code. Sorry, Sam, it won't work. We are talking about two sets of startup code here. Let's say that a copy of DIR is infected. When you type "dir", AmigaDOS loads the infected program and runs the virus's startup code (the original dir hunks are stored in the virus's data hunk). After the virus has done its dirty work, it makes sure that the original dir hunks are stored in memory the same way that the AmigaDOS loader would have done with the uninfected copy of the program. The dir startup code now runs, calculates the checksum of the of the program as it exists in memory, and comes to the conclusion that everything is OK. The dir startup code cannot detect that damage has already been done. Therefore, putting the checksum code in the startup code is not the answer. Please note that I am interpreting your one line response as an indication that we are not talking about verifying checksums of programs as they reside on disk, and not talking about putting checksum algorithyms into the AmigaDOS loader. (Arguments against them have already been posted.) -- +----------------------------------------------------------------------------+ | TYMNET:JMS@F29 CA:"POPJ P," UUCP:{ames|pyramid}oliveb!tymix!antares!jms | | INTERNET:(Real Soon Now) Amiga Hacker PHONE:Joe Smith @ (408)922-6220 | +----------------------------------------------------------------------------+
ekg@warwick.UUCP (Kevan Gelling) (01/17/89)
Can the PROTECT command be used to stop the IRQ virus attaching itself
to executable commands ??
-----------+--------------------------------------+--------------------------
// | Kevan Gelling ekg@cs.warwick.ac.uk | University of Warwick
\\ // |--------------------------------------+ Coventry
\X/ | #include <witty comment.h> | England
-----------+--------------------------------------+--------------------------ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (01/20/89)
In article <917@ubu.warwick.UUCP> ekg@warwick.UUCP (Kevan Gelling) writes: >Can the PROTECT command be used to stop the IRQ virus attaching itself >to executable commands ?? > No. The IRQ virus does a SetProtection() on the file in question to make it read/writeable. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU \_ -_ Recumbent Bikes: UUCP: pacbell > !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
rwallace@vax1.tcd.ie (02/22/89)
DON'T PANIC! The dreaded IRQ virus is apparently virtually harmless. It does not survive reboot. It does not infect every program you load in. It looks at the first line in :S/STARTUP_SEQUENCE. If that's an executable program it infects it. Otherwise it infects :C/DIR. It does this every time OldOpenLibrary() is called. In effect this means that whenever you run any program the virus may look at the first item in your startup-sequence and :C/DIR on whatever disk you currently have in the drive, so it can spread very slowly from disk to disk. It does no deliberate damage. Stopping it is simple. Rename C/DIR to something else e.g. move it into a different directory, rename it to DI or delete it and use a command shell's built-in DIR command instead. And put a tab character before the program name on the first line of your startup-sequence. I can't be certain of any of this because I haven't seen the virus myself, I got this information from articles on Jumpdisk. Also somebody may mutate it into something much more virulent at a later date. But at the moment it seems we don't have to worry too much. The new version of VirusX and a program called KillVirus will also specifically detect it. "To summarize the summary of the summary: people are a problem" Russell Wallace, Trinity College, Dublin rwallace@vax1.tcd.ie