esheric@SANDIA-2.ARPA (05/24/88)
>From: Glenn Larsen <glarsen@note.nsf.gov> >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 <esheric@sandia-2.arpa>