S72UZAW@TOE.TOWSON.EDU (Jan C. Zawadzki) (12/11/90)
Greetings...
For the last couple of weeks I saw a number of inquiries about UNIX
oriented anti-virus utilities. A couple of comments:
Exercise #1. (some knowledge of unix assumed) Sit down in front of a
terminal. Using man pages/manuals write a substitute login program.
Exercise #2. (as above) Write a substitute crypt() routine. Compare your
results to those of the original crypt() - they must be the same!
Exercise #3. (regardless of your knowledge of *nix) Write a program that is
capable of switching from regular to priviledged mode and back without
the knowledge of the os. (real hardware...)
If you can do number 1, you are good. Better than most. If you can
do number 2, you are excellent - work for the NSA, they'll pay you
more than you're getting now. Fortunately, to write a VIRUS that will
function in a UNIX environment, you must be able to accomplish number
3. If you can do number 3, you will not waste your time writing
viruses, you will be writing operating systems for AT&T. There are
some very basic precautions that can keep a UNIX system safe as could
be. The security is already there - only people must be trained. The
biggest security problem in UNIX is the superuser. If that account is
handled with care, rest assured - any infection can be fully
contained.
On the other hand, the world is full of sick sick people.
- ---
Jan C. Zawadzki
INet: yahn @ midget.towson.edu
BNet: s72uzaw @ towsonvx
=== *I* think... ===CHESS@YKTVMV.BITNET (David.M.Chess) (12/12/90)
Jan C. Zawadzki <S72UZAW@TOE.TOWSON.EDU> writes that a virus under
"*nix" must be "capable of switching from regular to priviledged
mode and back without the knowledge of the os.". I don't think that's
correct. All a virus has to do is:
- Get (generally from the operating system) a list of files to which it
can write; choose one or more executables from that list.
- Read each one to see whether or not it is already infected.
- If not, do appropriate reads and writes to the file to
infect it (add a copy of the virus to it, at the start of
the execution path).
None of these things requires any sort of special privilege. Of
course, such a simple "well-behaved" virus won't be able to infect any
files to which the os doesn't give it write access, but THAT'S OK!
Fred Cohen's experiments show that there's enough program-sharing and
enough writeable executables in at least some *nix environments that a
virus can spread very widely very quickly without subverting the os in
any way.
The "viruses need to write directly to the hardare" or "viruses need
to modify the operating system" or "viruses need to subvert
operating-system security" or "viruses need to have special
privileges" stories are all common, and all false*.
DC
* (with the possible exception of some operating systems in which
writing to any executable requires a special privilege; such systems
are quite rare in real life, I think.)srodawa@vela.acs.oakland.edu (Ron Srodawa) (12/13/90)
S72UZAW@TOE.TOWSON.EDU (Jan C. Zawadzki) writes: >Greetings... > For the last couple of weeks I saw a number of inquiries about UNIX >oriented anti-virus utilities. A couple of comments: I think the author misses the drift of those requests. I think they were asking for software which runs in Unix and checks MSDOS diskettes. Cross products such as these are quite common for other applications. For example, in Xenix/386 I can manipulate MSDOS diskettes..read, write, delete, format while under Xenix. I also can process arc files (and soon--zip files) while under Xenix. I can even develop MSDOS executables under Xenix. With a virtual machine like Vp/Ix I can even run MSDOS under Xenix. If virus detectors and removers for MSDOS viruses were available for Xenix, I would use them rather than native tools on MSDOS. I don't have to worry about becoming infected by accident when processing MSDOS diskettes under Xenix, even though the MSDOS diskette is infected. Xenix and other Unix systems are gaining in popularity on '386 and '486 mainframes. - -- | Ronald J. Srodawa | Internet: srodawa@unix.secs.oakland.edu | | School of Engineering and CS | UUCP: srodawa@egrunix.UUCP | | Oakland University | Voice: (313) 370-2247 | | Rochester, Michigan 48309-4401 | |
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (12/15/90)
David.M.Chess writes that a UNIX virus simply has to find executable files to write to and infect them, and does not need any special privileges. Even if there were a substantial number of such executable files, there is another consideration: There are many different types of machines running different types of UNIX. For this reason it is very unlikely that a UNIX virus could ever become as widespread as an IBM/MS-DOS virus, for example. As soon as it arrived at a machine with a different CPU (or even the same CPU with a different executable file format) its propagation at that point would be blocked. - -- Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!dhesi
VALDIS@VTVM1.CC.VT.EDU (Valdis Kletnieks) (12/19/90)
>Date: 15 Dec 90 03:27:33 +0000 >From: dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) > >There are many different types of machines running different types of >UNIX. For this reason it is very unlikely that a UNIX virus could >ever become as widespread as an IBM/MS-DOS virus, for example. As >soon as it arrived at a machine with a different CPU (or even the same >CPU with a different executable file format) its propagation at that >point would be blocked. To paraphrase this JUST a little bit.. There are many different types of machines running different types of MS-DOS. For this reason it is very unlikely that a MS-DOS virus could ever become as widespread as the Morris Worm, for example. As soon as it arrived at a machine with a different floppy controller (or even the same machine with a different version of the BIOS) its propagation at that point would be blocked. How many "malicious" viruses have we seen? And how many "innocuous" ones have there been that hurt people because they didn't know about MS-DOS 3.1, or MS-DOS 4.0, or this manufacturer's funky BIOS rom or.... But it didn't stop the virus from spreading enough to be a problem, did it? If anything, a Unix virus would be EASIER to write - because (for example) the semantics of 'seek()' or 'open()' have not been drastically changed since 1974 or so. I have currently going a project that is literally 250,000 lines of code, and is known to work on Apollo, bsd4.2, bsd4.3, bsd4.4, hpux, solbourne,sunos 3, sunos 4, sys5.2, ultrix 3.1, ultrix 4.0 (for both Vax and Mips CPUs). Now, since a virus *IS* just another program, it should be fairly simple for a competent programmer to write a measly 300 lines of code that will run on at least as many systems as the aformentioned monster.... Of course, it helps that the semantics of 'open()' have not drastically changed since 1974, as opposed to MS-DOS, that likes to keep changing the register contents of the various INT calls every release or two.... Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute
frisk@rhi.hi.is (Fridrik Skulason) (12/20/90)
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: >There are many different types of machines running different types of >UNIX. For this reason it is very unlikely that a UNIX virus could >ever become as widespread as an IBM/MS-DOS virus, for example. Ah - no problem - just make the virus contain the C source to itself, and insert it into the C programs it finds..... :-) Merry Christmas, everyone.... - -frisk - -- Fridrik Skulason University of Iceland | Technical Editor of the Virus Bulletin (UK) | Reserved for future expansion E-Mail: frisk@rhi.hi.is Fax: 354-1-28801 |
jkp@cs.HUT.FI (Jyrki Kuoppala) (12/20/90)
dhesi%cirrusl (Rahul Dhesi) writes: >Even if there were a substantial number of such executable files, there >is another consideration: > >There are many different types of machines running different types of >UNIX. For this reason it is very unlikely that a UNIX virus could >ever become as widespread as an IBM/MS-DOS virus, for example. As >soon as it arrived at a machine with a different CPU (or even the same >CPU with a different executable file format) its propagation at that >point would be blocked. This is of course not true; who said viruses have to propagate as binary files ? Shell scripts, awk scripts, elisp code etc. are easy to use. SunOS LD_LIBRARY_PATH would be a wonderful place to put some suitable code in (compiled into suitable object files from source first). Also, just leaving command files named 'ls' and the like in writable diroctories catches all those nice people with . first in their PATH (like SunOS root account last I looked). And here's a story Peter da Silva posts from time to time (I hope he doesn't mind me posting it): //Jyrki From: peter@ficc.uu.net (Peter da Silva) Newsgroups: comp.unix.wizards Subject: UNIX and viruses (Re: GNU, security, and RMS) Date: 8 Jun 89 14:08:27 GMT In article <19930@adm.BRL.MIL>, bzs@bu-cs.bu.edu (Barry Shein) writes: > Will someone explain to me exactly how usernames and passwords and > file protections (a not unknown form of security) will protect against > computer viruses?? Thirty-fifteen. I guess it's time for this again. I originally posted this before the Internet Worm Scare. The Usenet virus: a case history. A cautionary tale. The Usenet virus was detected when a user discovered that a program he had received from the net seemed to have two versions of malloc included with the source. One version of malloc might be odd, but people have never tired of reinventing the wheel. Two versions were suspicious, particularly since they lead to a name conflict when the program was linked. The first, lmalloc.c, seemed to be identical to the malloc listed in Kernighan and Ritchie. The second, bmalloc.c, was rather strange, so we concentrated our efforts on it... this time was later found to have been wasted. After a little work during spare moments over the course of a week we decided it was actually a clumsy version of the buddy system (a fast but space-inefficient method of memory allocation). It might make a good example of how not to write readable code in some textbook, but it wasn't anything to get worried about. Back to the first. It made use of a routine named speedhack() that was called before sbrk() the first time the malloc() was called. There was a file speedhack.c, but it didn't contain any code at all, just a comment saying that it would be implemented in a future version. After some further digging, speedhack was found at the end of main.c. The name was disguised by some clever #defines, so it never showed up in tags and couldn't be found just by grepping the source. This program turned out to be a slow virus. When it was run, it looked for a file 'lmalloc.c'. If it found it, or it didn't find Makefile, it returned. From then on malloc ran normally. If it didn't find it, it reconstructed it using a series of other routines with innocuous names tagged on to the end of other files. This was apparently an attempt to avoid overly increasing the size of any one of the files in the directory. Then it went into Makefile or makefile (it looked for both) and added lmalloc.o onto the end of the first list of '.o' files it found. It then reconstructed each of the extra routines, and speedhack itself, using techniques familiar to any reader of the obfuscated 'C' contest. These were tagged onto the ends of the '.c' files that corresponded to the '.o' files in this same list. The program was now primed to reconstruct the virus. On inspection, we discovered that about 40% of the sources on our system were infected by the speedhack virus, We also found it in one set of shell archives that we'd received but never unpacked or used, which we took as evidence that it had spread to a number of other systems. We have no idea how our system was infected. Given the frequency with which we make modifications and updates, it's likely that the original speedhacked code is no longer on the system. We urge you to inspect your programs for this virus in an attempt to track it to its source. It almost slipped by us... if the author had actually put a dummy speedhack in speedhack.c we would have merely taken lmalloc.o out of the Makefile and defused *this* copy of the virus without being any the wiser. There are other failings in this program that we have thought of. We have decided not to describe them to avoid giving the author of this program ideas we might regret. Some ways that programs like this can be defeated include 'crc' checks of source files and, of course, careful examination of sources received from insecure sites. ----- Now I have to make a confession. This whole document is a hoax intended to dramatize the problems involved with viruses and Usenet. I suspect that most of you were clued to this by the Keywords line. While playing with the idea and writing this article several things occurred to me: First of all, this virus is a much more complex program than any of the viruses that have been spotted on personal computers. I think it has to be, based on the design goals that a *real* UNIX virus must satisfy. It must be small, to avoid detection. It must not cause files to grow without bound. It must infect foreign files, otherwise it's not a virus... just a Trojan Horse (like the bogus ARC and FLAG programs on the PC). Trojan horses are a dime-a-dozen. It must infect source files, since this is the primary software distribution channel for UNIX. A virus stuck on one machine is a boring one. It must not break the infected program (other than what it might care to do deliberately). It must not be obvious from a simple examination of the source (like, changing main to Main and having a virus-main call Main). I believe that given these goals (which are, of course, subject to debate) a simpler program would be successful in infesting more than a small fraction of the machines that (say) comp.sources.misc reaches. There are systems immune to this particular attack, of course. Ones not running UNIX, so sbrk() doesn't work. Or ones with radically different versions of malloc(). Ones with no 'c' compiler. They are in the minority, though. On the other hand a virus of this type could infest a large proportion of the net before it was found. The virus I described does not cause any direct damage, except for using up a relatively small amount of disk space. A more vicious virus is possible. Other variations of this virus are obviously possible. For example, it could be tagged onto any standard 'C' library routine... I chose malloc merely because source was available and because it's something that people complain about, so they wouldn't be likely to find an extra copy suspicious. Another good routine would be perror(), for the same reason. This would have the additional benefit of making the spread of the infection dependent on an additional random factor, making it harder to detect the virus. Do I think something like this is likely? Well, I'm sure that eventually someone will try something like this, I suspect that their virus would get caught much sooner than in this story, because I think that more people look at the source than conventional wisdom would lead you to believe. - -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com. - -- Jyrki Kuoppala Helsinki University of Technology, Finland. Internet : jkp@cs.hut.fi [130.233.251.253] X400 : /C=fi/A=fumail/P=inet/O=hut/OU=cs/S=Kuoppala/G=Jyrki BITNET : jkp@fingate.bitnet Gravity is a myth, the Earth sucks!