peter@sugar.uu.net (Peter da Silva) (10/16/88)
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 Makefile, then a file named '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 rest of the '.c' files that corresponded to the '.o' files in this same list. The program was now primed to reconstruct the virus. On inspection, we discovered that about 40% of the sources on our system were infected by the speedhack virus, We also found it in one set of shell archives that we'd received but never unpacked or used, which we took as evidence that it had spread to a number of other systems. We have no idea how our system was infected. Given the frequency with which we make modifications and updates, it's likely that the original speedhacked code is no longer on the system. We urge you to inspect your programs for this virus in an attempt to track it to its source. It almost slipped by us... if the author had actually put a dummy speedhack in speedhack.c we would have merely taken lmalloc.o out of the Makefile and defused *this* copy of the virus without being any the wiser. There are other failings in this program that we have thought of. We have decided not to describe them to avoid giving the author of this program ideas we might regret. Some ways that programs like this can be defeated include 'crc' checks of source files and, of course, careful examination of sources received from insecure sites. ----- Now I have to make a confession. This whole document is a hoax intended to dramatize the problems involved with viruses and Usenet. I suspect that most of you were clued to this by the Keywords line. While playing with the idea and writing this article several things occurred to me: First of all, this virus is a much more complex program than any of the viruses that have been spotted on personal computers. I think it has to be, based on the design goals that a REAL UNIX virus must satisfy. I have not attempted to actually implement it because of this. It must be small, to avoid detection. It must not cause files to grow without bound. It must infect foreign files, otherwise it's not a virus... just a Trojan Horse (like the bogus ARC and FLAG programs on the PC). Trojan horses are a dime-a-dozen. It must infect source files, since this is the primary software distribution channel for UNIX. A virus stuck on one machine is a boring one. It must not break the infected program (other than what it might care to do deliberately). It must not be obvious from a simple examination of the source (like, changing main to Main and having a virus-main call Main). I believe that given these goals (which are, of course, subject to debate) a simpler program would be successful in infesting more than a small fraction of the machines that (say) comp.sources.misc reaches. There are systems immune to this particular attack, of course. Ones not running UNIX, so sbrk() doesn't work. Or ones with radically different versions of malloc(). Ones with no 'c' compiler. They are in the minority, though. On the other hand a virus of this type could infest a large proportion of the net before it was found. The virus I described does not cause any direct damage, except for using up a relatively small amount of disk space. A more vicious virus is possible. Other variations of this virus are obviously possible. For example, it could be tagged onto any standard 'C' library routine... I chose malloc merely because source was available and because it's something that people complain about, so they wouldn't be likely to find an extra copy suspicious. Another good routine would be perror(), for the same reason. This would have the additional benefit of making the spread of the infection dependent on an additional random factor, making it harder to detect the virus. Do I think something like this is likely? No. Especially not now that I've written this little piece of science fiction. I'm sure that eventually someone will try something unlike this, I suspect that their virus would get caught much sooner than 'speedhack', because I think that more people look at the source than conventional wisdom would lead you to believe. But, again, this is just my personal opinion. Debate is welcomed... that's why I did this in the first place: to inject some sense into the debate currently raging in comp.sys.amiga. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
papa@pollux.usc.edu (Marco Papa) (10/16/88)
In article <2836@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: > > The Usenet virus: a case history. > (A cautionary tale). The description fits pretty much the model of virus described in Fred Cohen's thesis (date: 1983) and in fact more than one of very similar UNIX viruses were built as part of "student projects" at USC. So it is a hardly new, and divulging such information will have absolutely no effect of whether or not such a type of virus will show up on Usenet or on your favourite UNIX host. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
peter@sugar.uu.net (Peter da Silva) (10/16/88)
In article <12840@oberon.USC.EDU>, papa@pollux.usc.edu (Marco Papa) writes: > In article <2836@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: > > The Usenet virus: a case history. > > (A cautionary tale). > The description fits pretty much the model of virus described in Fred Cohen's > thesis (date: 1983) and in fact more than one of very similar UNIX viruses > were built as part of "student projects" at USC. Much of the best software shows up as student projects... students have a lot of time and a wonderful support structure surrounding them. I'm interested to learn that I independently derived the same sort of virus, since I've never read the paper in question nor attended any of the course you've mentioned in the past. Perhaps this is an obvious evolution... certainly every decision I made in putting the article together seemed pretty much forced by my goals. > So it is a hardly new, > and divulging such information will have absolutely no effect of whether > or not such a type of virus will show up on Usenet or on your favourite > UNIX host. I doubt if any of the student projects will show up, considering how tracable they are. Some time or another, though, someone is going to try something like this. Might I direct your attention to the discussion about UNIX security... and the metadiscussion about whether such discussion is appropriate... that is even as we speak winding down into yet another morass of useless hints. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
mjr@vax2.nlm.nih.gov.nlm.nih.gov (Marcus J. Ranum) (10/22/88)
In article <2836@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: > > The Usenet virus: a case history. > (A cautionary tale). Actually, calling them 'virus'ses is a beautiful description - and just like virusses that infect humans 90% of the defense is common sense. It's just like getting a venereal disease: if you play around with code that is not from reputable sources, or if you don't exercise caution, you may have a problem. I mean, compiling some sleazy public domain deamon as "root" and doing a "make install start" is the same level of thoughtlessness as doing intravenous drugs with someone you just met in a bar :-) -and when something goes wrong, you deserve as much pity. I use lots of the code that I see on the net. My defense seems to be pretty good, since I am so busy that I almost never even unshar a file until I have forgotten about it for at least a week. That greatly increases the chance that someone else will have already looked at it. And, of course, if it isn't source code, you bet I'm not going to run it on my machine unless it comes from a reputable source (someone I know personally who WROTE it, or a big company that has too much to lose to play games). There are also some "names" on the net you learn you can trust. Sure, someone could hack something into the diffs for "perl", but I expect that someone would notice. Of course you're NOT going to protect yourself from EVERYTHING by just showing common sense, but it really helps. I've found that thinking of virusses as "cybernetic VD" makes it pretty easy to know how to react when someone gives me a floppy disk of PD utilities, sans source. It's not a "paranoid" attitude - it's not a "don't use anything you didn't BUY" attitude, it's just that mommy always used to tell me: "Don't put that in your mouth if you don't know where it's *BEEN*". And if you don't have backups, you're so stupid you should give me a call and buy this 900Gb write only memory I'm selling. --mjr();