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 AA13864; Fri, 1 Jun 90 11:32:42 -0400 Received: from SEI.CMU.EDU by g.sei.cmu.edu (5.61/2.5) id AA20602; Fri, 1 Jun 90 11:32:39 -0400 Received: from nsfnet-relay.ac.uk by sei.cmu.edu (5.61/2.3) id AA01024; Fri, 1 Jun 90 11:32:13 -0400 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa23841; 1 Jun 90 16:10 BST From: Anthony Appleyard To: KRVW <@NSFnet-Relay.AC.UK:KRVW@sei.cmu.edu> Date: Fri, 01 Jun 90 16:08:44 BST Message-Id: <$TGTWCZCFFBTJ at UMPA> Subject: Virus-L vol 0 issue #0524 Virus-L Digest Tue, 24 May 88, Volume 0 : Issue #0524 Today's Topics Comments on FLUSHOT PLUS More Flu_Shot woes Re: hunting up infected files FLUSHOT-Plus withdrawn from SIMTEL20 archives ------------------------------ Date: Tue, 24 May 88 13:13:00 PDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: DBUERGER@SCU Subject: Comments on FLUSHOT PLUS I am forwarding these notes on FLUSHOT PLUS from Usenet.comp.sys.ibm.pc.general. I forgot to include the headers, but authors' net addresses are included. - ----------------------------------- I was testing FLUSHOT Plus to see if it was worth the $10.00 fee the Author, Ross Greenberg is charging. I knew that a large number of hours had been put into the program. The documentation made it lk prettgood, even though it was a bit rambly. I created a FLUSHOT.DAT file, and put in 37 lines of the form C=filename When I loaded Flushot, I got a message saying that there was no room for a table, and the machine hung. I had not read the documentation closely enough. It turns out that you have to put a 'dummy' checksum in each line like this: C=filename[12345] Where 12345 is the dummy number. When flushot is started, it checksums the file, and reports the new number, which you have to write down and type in FOR EACH FILE! I then rewrote the FLUSHOT.DAT file with only two programs, command.com and a.bat checksummed. Flushot checked them on startup, but did not perform as advertised when I ran A.BAT, changed it, and ran it again. Flushot claims that it checksums files whenever they are loaded by MSDOS. I guess this does not apply to BATCH files. I was going to test checksumming of .EXE files, but FLUSHOT trashed my CMOS ram. FLUSHOT PROTECTS CMOS RAM ? Finally, I added two more lines to FLUSHOT.DAT with dummy checksums. I restarted FLUSHOT and got the following message: CMOS RAM HAS BEEN CHANGED. Y TO CONTINUE, ANY OTHER KEY TO PROCEED Followed by a long garbled bunch of characters!. Naturally, when I rebooted I could not boot from the Hard Disk, until I restored the setup information. My CMOS ram was trashed by FLUSHOT! I hoped that no damage had been performed to my FAT!. I then restored my ram with a CMOS-SAV progam which I wrote for such a purpose, and reloaded flushot. I then ran a program which zeroed out my CMOS ram using MS C outp() function, without a whimper from FLUSHOT. Note that I had no TSR'S present when this happened. I have a Leading Edge AT clone (Made by Mitsubishi, same as SPERRY IT). I am running DOS 3.1. I considered the possibility of Ross Greenberg enforcing his $10.00 fee by putting counters into flushot (since I had to restart it each time I changed anything in the FLUSHOT.DAT file and did this a number of times) and put the idea aside. (That was a pretty virulent dissertation in the manual about *worms*, maybe he thinks that people who don't buy his software are *worms*?!? :-) What I think Ross will accomplish by these threats, rewards, challenges is ENCOURAGE scores of copycats to write viruses to beat flushot (which is buggy). My conclusion is that FLUSHOT Plus does not perform as advertised (in my case, anyway) and I would not use it or even trust it with my data. The checksum protection is quite limited in number of files, and the method of entering the checksum is quite painful. The bugs in the program might be excusable if the program was public domain or shareware in the sense that you pay for it only if you think it is valuable (not if you use it, since technically, I owe Ross Greenberg $10 since I used it) . I think that it tries to do too much, and ends up doing too little, even the wrong thing altogether. This shows poor design and testing practice. When I support a shareware program, I am not paying the author for his time, I am paying for a finished product. And a finished product, FLUSHOT PLUS is not ! The above is my opinion, and no-one is liable for it but myself. I reserve the right to deny everything. Matt Cohen (matt@psuhcx) - ----------------------------------------------- As promised, I forwarded matt@psuhcx (Matt Cohen)'s letter to Ross. Here's his reply: "Well, Matt, I'm sorry that you found the program to be less than you expected. You certainly got your money's worth, though, didn't you? Look, the program does try to do a lot. One area I'v had consistant trouble with has been CMOS. It'll get pulled in the next release. Not because some people didn;t find it useful. Just because the bitching from the people who had problems with it isn't worth the lousy $10 that the other people pay. If you don't like it, don't use it. I'm certain that I won;t lose any sleep over it. You might want to consider using one of the commercial products. I understand that at least one of them costs about $200. But, since you have to pay them in advance, I would assume that you'd not even consider such a thing. I ask people to contact me if they have a problem. I guess that part of the manual (the one with my phone number) must have escaped your astute observations as well as the "How to Use Flu_Shot" section must have. I know!! Your printer was out of paper! Well, just for you Matt, I'll print out a copy here and send it to you --- if you pay the postage. But, I guess with people like you around, I should just stop enhancing FLU_SHOT, or trying to protect *you* from the bad guys. Hell, I can't even protect you from yourself. Have a nice day, Matt." Erik Bailey | CompuServe | 7 Oak Knoll | (ARPA/USENET courtesy of ihnp4!think!ejb | PCMagNet | Arlington, MA 02174 | Thinking Machines Corp., ejb@think.com | 72261,3275 | (617) 643-0732 | First St, Cambridge, MA) do headache -> take 1 aspirin od "This terminates one way or another" -Dijkstra %%% End of forwarded messages David Buerger dbuerger@scu.bitnet -------------------- Date: Tue, 24 May 88 16:55:36 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: More Flu_Shot woes I just saw another interesting Flu_Shot related bug report on the Usenet and I thought that I'd forward it here. The report goes into quite some detail as to specific bugs in various versions of Flu_Shot, including Flu_Shot+ 1.2. I hope that these bugs get fixed in a future release! Here's the forwarded message: >From: Glenn Larsen >I had only one problem with Flu Shot 3 which was downloaded from SIMTEL >in Nevada. The problem was when using the option to protect the CMOS were >configuration information is stored with battery backup. Here in Albuquerque a local BBS SYSOP complained that FLUSHOT3 was actually a Trojan Horse program itself and was responsible for trashing his hard disk. Since it seemed like a legit program to me, based on the well documented sources of the program uploaded to SIMTEL20, I decided to take a little time and dis-assemble FLUSHOT3 and see if I could see any trouble. What I found was a program that, in my opinion, was loaded with bugs. One of the bugs I found was in the CMOS restore section: FLUSHOT3 screws up and replaces the ES register with the DS value when it returns from this routine. Summary of BUGS and/or omissions in FLUSHOT3 detected as of May 1, 1988: Bugs which can cause significant damage: 1. Stack corrupted in Int 26h handler: should return via RETF, which should leave flags on stack, but instead returns via RETF 2, thereby discarding flags. 2. Restoring CMOS memory after checking improperly restores the es segment register : es is replaced by ds 3. Program assumes direction flag is cleared (forward). Less damaging bugs: 4. Incorrect memory size (2 times amount req'd) in install 5. Interrupts are enabled for no reason in FCB test Condom holes: Bugs or ommissions that make program ineffective 6. Incorrect jmp instruction disables ASCIIZ rename checking 7. No check of AT bios int 13h "Write long" call (0bh) No checks for XT int 13h format calls 6 and 7 8. No accommodation for extended FCB format 9. No checks for direct IO via IOCTL call 44h 10. Program fails to detect FCB file delete and renaming functions that can affect critical files if wild cards are used. Loose ends: 11. Invalid error codes returned by int13h and int26h 12. Error code returned by failed FCB calls is unknown 13. Failures are not handled consistently - FCB calls return to program while others force a program terminate. 14. No checks for existence of CMOS RAM before reading and/or attempting to restore it. What happens on non AT's? [Since the user has to specifically request this check, one could argue it would be his/her own fault to invoke it on a machine that doesn't have the CMOS memory.] FluShot Plus, version 1.2 is significantly better, but it still has some problems: What I've found as of May 14, 1988: Bugs which can cause significant damage: 1. Stack corrupted in Int 26h handler (fails to leave old flags on stack as it should) Condom holes: Bugs or omissions that make program ineffective 2. No check of XT bios int 13h format functions 6 and 7 3. No accommodation for extended FCB format 4. No checks for direct IO via IOCTL call 44h Loose ends: 5. Invalid error codes returned by int 13h and int 26h failures 6. No checks for existence of CMOS RAM before reading and/or attempting to restore it. What happens on non AT's? [Since the user has to specifically request this check, one could argue it would be his/her own fault to invoke it on a machine that doesn't have the CMOS memory.] 7. Overall the program coding is bit sloppy. Since it doesn't make any attempt to optimize usage of the segment registers, it is a bit longer and slower than it needs to be. Final comments: What else can I say? I'm not going to claim to be the world's finest programmer and that I could do a better job. I may well be dead wrong in identifying some of the code as bugs. However I would suggest that if you are planning on using FLUSHOT xxxx, back up your hard disk first. PS: I downloaded the latest FSP_12.ARC from SIMTEL20 tonight to make sure that it was the same as what we had gotten off local boards here in Albuquerque. Unfortunately, the FSP.COM file was different! A quick check, however, reveals that the only difference was the addition of a CMP AL,"?" and JE xyz pair of instructions in the filename compare subroutine. The Int 26h stack bug was still there. Albq. version of FSP.COM: 10309 bytes CRC = BDCE 27 April 88 SIMTEL20 version : 10313 bytes CRC = 9723 27 April 88 Peter Esherick Sandia National Labs, Albuquerque - ---------------------------------------------------------------------- = Kenneth R. van Wyk = = = User Services Senior Consultant = Shocked! Shocked I am at = = Lehigh University Computing Center = this despicable act! = = Internet: = = = BITNET: = = - ---------------------------------------------------------------------- -------------------- Date: Tue, 24 May 88 11:09:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List Comments: Resent-From: "Joseph M. Beckman" Comments: Originally-From: "Joseph M. Beckman" From: "Joseph M. Beckman" Subject: Re: hunting up infected files In-Reply-To: Message of 9 May 1988 11:05 edt from Karl-L. Noell As an employee of the National Computer Security Center, I must point out that we do *NOT* attempt to track perpetrators for prosecution or for *ANY* other reason! We are not a law enforcement Agency, and are prohibited by law to take any such action. We are interested in tracking the viruses (or ordinary Trojan Horses) as they infect different sites. As a matter of professional interest, I would be curious as to the motivations of perpetrators of malicious code, or whether they are members of "Hacker Clubs;" but that is information that may be conveyed without identifying the people/organizations involved. Joseph -------------------- Date: Tue, 24 May 88 08:01:00 MDT Reply-To: Virus Discussion List Sender: Virus Discussion List Comments: Warning -- original Sender: tag was KPETERSEN@SIMTEL20.ARPA From: Keith Petersen Subject: FLUSHOT-Plus withdrawn from SIMTEL20 archives I have decided to remove FluShot-Plus from our SIMTEL20 archives because of the continuing problem of programming bugs. It is *not* a Trojan or Virus. The author just needs to get his bugs fixed. I recommend to all recipients of this message that they discontinue use of *any* version of Flushot or Flushot-Plus. --Keith Petersen Maintainer of the MSDOS archives at SIMTEL20.ARPA - -forwarded message--- Date: Tuesday, 24 May 1988 08:20-MDT From: Reply-To: To: w8sdz cc: esheric at sandia-2.arpa Re: Flushot plus bugs >From: Glenn Larsen >I had only one problem with Flu Shot 3 which was downloaded from SIMTEL >in Nevada. The problem was when using the option to protect the CMOS were >configuration information is stored with battery backup. Here in Albuquerque a local BBS SYSOP complained that FLUSHOT3 was actually a Trojan Horse program itself and was responsible for trashing his hard disk. Since it seemed like a legit program to me, based on the well documented sources of the program uploaded to SIMTEL20, I decided to take a little time and dis-assemble FLUSHOT3 and see if I could see any trouble. What I found was a program that, in my opinion, was loaded with bugs. One of the bugs I found was in the CMOS restore section: FLUSHOT3 screws up and replaces the ES register with the DS value when it returns from this routine. Summary of BUGS and/or omissions in FLUSHOT3 detected as of May 1, 1988: Bugs which can cause significant damage: 1. Stack corrupted in Int 26h handler: should return via RETF, which should leave flags on stack, but instead returns via RETF 2, thereby discarding flags. 2. Restoring CMOS memory after checking improperly restores the es segment register : es is replaced by ds 3. Program assumes direction flag is cleared (forward). Less damaging bugs: 4. Incorrect memory size (2 times amount req'd) in install 5. Interrupts are enabled for no reason in FCB test Condom holes: Bugs or ommissions that make program ineffective 6. Incorrect jmp instruction disables ASCIIZ rename checking 7. No check of AT bios int 13h "Write long" call (0bh) No checks for XT int 13h format calls 6 and 7 8. No accommodation for extended FCB format 9. No checks for direct IO via IOCTL call 44h 10. Program fails to detect FCB file delete and renaming functions that can affect critical files if wild cards are used. Loose ends: 11. Invalid error codes returned by int13h and int26h 12. Error code returned by failed FCB calls is unknown 13. Failures are not handled consistently - FCB calls return to program while others force a program terminate. 14. No checks for existence of CMOS RAM before reading and/or attempting to restore it. What happens on non AT's? [Since the user has to specifically request this check, one could argue it would be his/her own fault to invoke it on a machine that doesn't have the CMOS memory.] FluShot Plus, version 1.2 is significantly better, but it still has some problems: What I've found as of May 14, 1988: Bugs which can cause significant damage: 1. Stack corrupted in Int 26h handler (fails to leave old flags on stack as it should) Condom holes: Bugs or omissions that make program ineffective 2. No check of XT bios int 13h format functions 6 and 7 3. No accommodation for extended FCB format 4. No checks for direct IO via IOCTL call 44h Loose ends: 5. Invalid error codes returned by int 13h and int 26h failures 6. No checks for existence of CMOS RAM before reading and/or attempting to restore it. What happens on non AT's? [Since the user has to specifically request this check, one could argue it would be his/her own fault to invoke it on a machine that doesn't have the CMOS memory.] 7. Overall the program coding is bit sloppy. Since it doesn't make any attempt to optimize usage of the segment registers, it is a bit longer and slower than it needs to be. Final comments: What else can I say? I'm not going to claim to be the world's finest programmer and that I could do a better job. I may well be dead wrong in identifying some of the code as bugs. However I would suggest that if you are planning on using FLUSHOT xxxx, back up your hard disk first. PS: I downloaded the latest FSP_12.ARC from SIMTEL20 tonight to make sure that it was the same as what we had gotten off local boards here in Albuquerque. Unfortunately, the FSP.COM file was different! A quick check, however, reveals that the only difference was the addition of a CMP AL,"?" and JE xyz pair of instructions in the filename compare subroutine. The Int 26h stack bug was still there. Albq. version of FSP.COM: 10309 bytes CRC = BDCE 27 April 88 SIMTEL20 version : 10313 bytes CRC = 9723 27 April 88 Peter Esherick Sandia National Labs, Albuquerque