Return-Path: XPUM04@prime-a.central-services.umist.ac.uk Received: from G.SEI.CMU.EDU by ubu.cert.sei.cmu.edu (5.61/2.3) id AA03516; Tue, 19 Jun 90 07:20:13 -0400 Received: from SEI.CMU.EDU by g.sei.cmu.edu (5.61/2.5) id AA28595; Tue, 19 Jun 90 07:20:11 -0400 Received: from nsfnet-relay.ac.uk by sei.cmu.edu (5.61/2.3) id AA01622; Tue, 19 Jun 90 07:20:03 -0400 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa05181; 19 Jun 90 9:37 BST From: Anthony Appleyard To: DAVIDF@cs.heriot-watt.ac.uk Date: Tue, 19 Jun 90 09:42:00 BST Message-Id: <$TGWFCWKBBCVD at UMPA> Subject: Here is Virus-L vol 0 #0916 Virus-L Digest Fri, 16 Sep 88, Volume 0 : Issue #0916 Today's Topics Virus hits Japan (from RISKS forum) a hole (and cure) in GNU EMACS, from RISKS Rearranging program guts RE: Rearranging program guts ------------------------------ Date: Fri, 16 Sep 88 08:37:49 EDT From: "Kenneth R. van Wyk" Subject: Virus hits Japan (from RISKS forum) The following is a report on a so-called virus that has hit Japan. I thought that it was particularly interesting because it steals user passwords via a network. The information is somewhat sketchy, but it doesn't appear (to me) to propogate, so doesn't seem to be a virus, but a clever password snatcher, even though the article refers to it as a virus (reprinted from RISKS forum). Ken Date: Wed, 14 Sep 88 13:35:04+0900 From: Yoshio Oyanagi Subject: The First "Virus" on Japanese PC PC-VAN, the biggest Japanese personal computer network operated by NEC, was found to be contaminated by a kind of virus, several newspapers reported today (September 14). This is, as far as I know, the first virus reported on a Japanese PC. The viruses so far reported in Japan were all on American PC or WS. PC-VAN is a telephone based network between NEC PC9800 personal computers, the best sold PC (> one million) in Japan. This virus does not destroy programs or data unlike those in US, but it automatically posts the user's password on the BBS in cryptographic form. The offender will later read the BBS and obtain the password. Several members of PC-VAN claim that they are charged for the access to PC-VAN which they do not know. This virus seems not to be contagious by its own power. The PC9800's OS was contaminated when the user carelessly run a anonymously distributed program on the PC. Kenneth R. van Wyk Calvin: Ever consider the end of the User Services Senior Consultant world as we know it? Lehigh University Computing Center Hobbes: You mean nuclear war? Internet: Calvin: I think Mom was referring to if I BITNET: let the air out of the car tires again. -------------------- Date: Fri, 16 Sep 88 08:41:50 EDT From: "Kenneth R. van Wyk" Subject: a hole (and cure) in GNU EMACS, from RISKS The following (also from RISKS) is a report on a security hole in GNU EMACS, along with a cure. Does anyone know of any viruses that have used this EMACS "feature"? GNU EMACS users should (imho) read this carefully, and add the fix listed below in the .emacs file. Ken Date: Thu, 15 Sep 88 08:32:45 PDT From: the terminal of Geoff Goodfellow Subject: GNU Emacs & Security (A.Gaynor via Eliot Lear) Return-Path: Date: Wed, 14 Sep 1988 11:48:10 PDT From: Eliot Lear To: hackers_guild@ucbvax.Berkeley.EDU Usmail: 700 East El Camino Real, Mtn View, California 94040 Phone: (415) 962-7323 Subject: [gaynor@aramis.rutgers.edu (Silver) : GNU Emacs & Security ] [The following was discovered by one of the Rutgers systems programmers. It is similar to the old "vi:" bug in that visiting a file may cause execution of an arbitrary set of commands including shell escapes... I am told that this has not been brought up on hg before. -eliot] From: gaynor@aramis.rutgers.edu (Silver) Subject: GNU Emacs & Security This message is being sent to everyone in group slide. I've wandered across an application of a feature of GNU Emacs that may allow sliders to fall victim to trojan horses arbitrarily stuck in files. The feature in question is the `file variables' section of a file. Upon reading the file, portions of text may be evaluated, with perhaps profound results. For example, using this feature I was able to create a file that copied /bin/sh to my home directory, and chmod it to run setuid root. It wasn't hard at all. With a little effort, I'm sure I could have made its effects totally transparant. So, protect yourself by inserting the following at the root level of your .emacs: ;; Protect thine arse from the Trojan file-variables section. (setq inhibit-local-variables t) The pertinent portion of this variable's documentation reads, "Non-nil means query before obeying a file's local-variables list.". So, from now on, it's going to ask you if you want to process the variables if they are present. Only answer `y' if you trust this file not to put you through a blender. If you answer `n', you can always look at the variables somewhere within the last 3000 characters of the end of the file, and, if they appear reasonable, say `M-x normal-mode' to process them. Regards, [Ag] gaynor@rutgers.edu Kenneth R. van Wyk Calvin: Ever consider the end of the User Services Senior Consultant world as we know it? Lehigh University Computing Center Hobbes: You mean nuclear war? Internet: Calvin: I think Mom was referring to if I BITNET: let the air out of the car tires again. -------------------- Date: Fri, 16 Sep 88 06:27:42 PDT From: Robert Slade Subject: Rearranging program guts An object code optimizer would be a pretty sophisticated program to try and imbed into a small virus. Also, adding to one place and taking from another or rearranging the bytes in order to imbed your code would require a program with a lot of smarts regarding how often a piece of code is likely to be executed, and *still* wouldn't fox the smarter CRC programs. Still, it would be a prime use for a targetted virus, and not all checking programs are all that smart. -------------------- Date: Fri, 16 Sep 88 12:37:00 EST From: "Jerry Leichter (LEICHTER-JERRY@CS.YALE.EDU)" Subject: RE: Rearranging program guts I was NOT proposing that a virus optimize a random program it found on your disk in order to find place to insert itself. Nor was I suggesting that it search around in random programs for "safe" positions. The PROGRAMMER of the virus would find the safe position in some common file or files. Only those files would get infected. A nasty virus of this sort would operate in two stages. In stage 1, it would spread through files it knew about, but do nothing harmful: Infiltration. In stage 2, it would begin infecting other programs, which would then do damage, perhaps after a further delay: Sabotage. The stage 1 infection would be very difficult to detect - there would be no clue that anything untoward was happening at all. Only explicit tests, like checksums on files, could detect the infiltration - and it is exactly ways of bypassing those that we are discussing here. If stage 1 were to delay long enough - 6 months, a year - you would likely find that you had no uninfected backups anywhere. Since the connection between the infection of OTHER programs of stage 2 and the hidden stage 1 virus would be tenuous, even figuring out that there WAS a stage 1 virus around would take a while - and finding it might be hard. A really nasty approach would be for stage 1 to be targeted at backup programs (where it would stay latent forever) and file transfer programs (where it would eventually infect files as it transfered them). This would make it look as if the stage 2 infection came from a recent up-load. How likely are these scenarios? Who knows. The point is, if you are going to rely on a virus detection mechanism, you had better have a LOT of confidence that it is hard to defeat - or you open yourself up to big headaches later. -- Jerry -------------------- *** end of Virus-L issue ***