From owner-freebsd-questions Thu Jun 20 15:33:41 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA21458 for questions-outgoing; Thu, 20 Jun 1996 15:33:41 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA21445 for ; Thu, 20 Jun 1996 15:33:37 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA16488; Thu, 20 Jun 1996 15:30:20 -0700 From: Terry Lambert Message-Id: <199606202230.PAA16488@phaeton.artisoft.com> Subject: Re: Missing Memory & shrinking drives To: jimd@mcafee.com (Jim Dennis) Date: Thu, 20 Jun 1996 15:30:19 -0700 (MST) Cc: nate@sri.MT.net, randyd@nconnect.net, questions@FreeBSD.ORG In-Reply-To: <201006202023.NAA06201@mistery.mcafee.com> from "Jim Dennis" at Jun 20, 96 01:19:18 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-questions@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Some academics have written "Unix virus demonstrations" which are > often just shell scripts. These don't propagate due to the > multi-user nature of Unix. The normal, customary, practices of > Unix users makes a poor population for viral propagation -- users > normally only execute utilities that were installed by the > administrator(s) of their system, or applications and utilities that > they themselves built or installed. Relatively little software for > Unix is distributed in binary form -- and the exceptions to this are > often treated to extra scrutiny by administrators (obtaining them > only direct from know good sites, checking sums and MD5 hashes, etc). > > So, as a practical point, there are not *unix* viruses. Actually, some academics have built virus software for UNIX that glues itself onto the front of binaries and propagates from binary to binary. This type of virus depends on binaries being allowed to be larger than their header claims -- a typical result of adding support for LISP and "compiled PERL" and EMACS "dumpbin". The virus is propagated in the background and runs (and unlinks) the real binary from data from the end of its own image on startup. A UNIX virus is typically two stage based on the need to cross protection domains, and delivers multiple payloads. At least one experimental two payload virus was written to (1) put itself on as many binaries as possible while it was not on the "passwd" binary, and (2) add itself to the "passwd" binary when a binary with the virus was run as root and (3) remove itself from binaries once it was in place on the "passwd" program and (4) once in place on the "passwd" program, send a log of all new password/user pairs to a collection point. Similar payloads are possible for sendmail or inetd or other daemons that are network accessibly and run as root, and for telnetd/rlogind/ftpd/login, or other user credential authenticators. Also, it's obvious that there are group-based attacks that don't require the actual superuser to execute the binary (bin/operator/etc.). Technically, this type of attack is a virus vectored trojan insertion. It gets more complicated; you can use trojan insertion of the virus in the first place to insert your trojan into the target system. One obvious vector is key-based prebuild binary authenticators... the most prevalent of these are Netrek clients, but IRC clients, mud clients, and similar software will also work. Netscape would probably be an ideal vector, as would Doom and Quake. This is probably why Netscape discourages mirroring its distributions. An MD5 checksum of an infected program is going match the expected value on the client site. Other insertions can be made to be less obviously detectable, and work on systems which aren't EMACS/LISP/PERL compromised by taking advantage of the shared library mapping vector in the standard crt0.o to vector to PIC code added to the code segment to do the propagation/payload delivery, then act as normal startup code. These work on non self-compromised systems because they adjust the actual header information on the binary during propagation. The second type of virus is the way that the "beneficial" code compression virus operates to reduce binary size at the cost of page sharing and startup time (a well known experiment done to rationalize virus research). UNIX virii are definitely rare, but they do exist. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.