maa@nbires.nbi.com (Mark Armbrust) (03/29/89)
It's been a couple days and nobody has mentioned this here, so I thought I'd post the following from rec.ham-radio: > Article 10376 of rec.ham-radio: > Path: nbires!ncar!ames!oliveb!pyramid!prls!philabs!briar.philips.com!rfc > From: rfc@briar.philips.com (Robert Casey;6282;3.57;$0201) > Newsgroups: rec.ham-radio,rec.ham-radio.packet > Subject: virus in PKARC software > Message-ID: <47960@philabs.Philips.Com> > Date: 27 Mar 89 14:34:24 GMT > Sender: news@philabs.Philips.Com > Organization: Philips Laboratories, Briarcliff Manor, NY > Lines: 36 > Xref: nbires rec.ham-radio:10376 rec.ham-radio.packet:2042 copied from packet: Date: 25 Mar 89 03:56:53 UTC (Sat) From: wa2sqq@kd6th.nj.usa.hamradio (BOB ) WARNING ! WARNING ! WARNING ! From: WA2SQQ Bob Kozlarek Subject: Software Virus PKZIP/PKUNZIP .92 AM40/AM41 Recent developments in the software world have required the famous PKARC software to be replaced by a new version called PKZIP/PKUNZIP. While several versions have been seen, the latest appears to be version .92 . Usually listed on landline BBS's is a program which will provide a menu driven screen for PKZIP, usually listed as AM-40 or AM-41. After running these one time, the embedded virus allocated 13 meg of memory to "never never land". It appears that this "strain" looks to see how much memory is occupied on the HD and then proceeds to gobble up an equal amount of unused memory. The results are devastating if you have more than 50% of the drives capacity in use. With the assistance of Gary WA2BAU I was able to retrieve the lost memory by using CHKDSK /f. For those of you who are not familiar with this DOS command, drop me a line @KD6TH and I'll elaborate. My sincere thanks goes out to Gary WA2BAU for saving me lots of disk handling ! Please pass this on to your local BBS and be sure to include the remedy. Best 73 de WA2SQQ Bob Kozlarek @KD6TH in Wycoff, NJ
nelson@sun.soe.clarkson.edu (Russ Nelson) (03/29/89)
This is very, very unlikely to be a virus. Just another novice user... -- --russ (nelson@clutx [.bitnet | .clarkson.edu]) If you can, help others. If you can't, | Leftoid and proud of it at least don't hurt others--the Dalai Lama |
w8sdz@smoke.BRL.MIL (Keith B. Petersen ) (03/30/89)
This is the real story. PKWare is NOT involved. Arc Master has been updated to fix the bug. ARCM422.ARC will be available later today in Simtel20's pd1:<msdos.arc-lbr> directory. [From file ARCMWARN.TXT/ARCMWARN.ARC] 2/25/89 - ARCMASTER SOFTWARE DANGER ----------------------------------- The ArcMaster compression program shell/menu system has been a very popular download on our BBS. In the past week I have received numerous reports of messed up hard disks after running ArcMaster version 4.0 and 4.01. I don't know if there were bugs in those versions, or if some hacker has decided to target ArcMaster for trojans. I suggest all users of ArcMaster 4.0 and 4.01 stop using those versions and wait until you can get a clean, new version from a reliable source. My apologies to John Newlin, since he has written some great software, but the reports of trashed hard disks have been consistent enough to warrant some caution with the 4.x versions of ArcMaster. Bob Mahoney Exec-PC Multi-user BBS 414-964-5160 ---end--- -- Keith Petersen Maintainer of the CP/M & MSDOS archives at wsmr-simtel20.army.mil [26.2.0.74] Internet: w8sdz@wsmr-simtel20.army.mil Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdz
felstein@mcnc.org (Bruce M. Felstein) (03/30/89)
The supposed bugs in ARCMASTER version 4xx and higher do not exist. If people would bother to read the doc files they would have learned that the directory that you specify for it to use to unarc and arc files to MUST be a special blank directory, since it will erase the entire contents of the directory after it finishes rearchiving the file. If you didn't bother to read the docs you might specify your root directory to use for this function and after ARCMASTER was done, it would automatically erase all files in that directory. Bruce Felstein Microelectronic Center of NC N3DOD Research Triangle Park, NC felstein@mcnc.org
dhesi@bsu-cs.UUCP (Rahul Dhesi) (03/31/89)
In article <4251@alvin.mcnc.org> felstein@mcnc.org.UUCP (Bruce M. Felstein) writes: >...the directory that you specify for it to use to unarc and arc files to >MUST be a special blank directory... >If you didn't >bother to read the docs you might specify your root directory to use >for this function and after ARCMASTER was done, it would automatically >erase all files in that directory. Unfortunately, users won't always remember every fine detail in a user manual. I should know, I'm an experienced user of computers, and there are details I keep overlooking all the time. If a program does something dangerous, it should take some care. If the documentation says that the directory must be a special blank directory, then the program should make sure that is *is* a blank directory. If there are any files in that directory, the program should refuse to run, or at least confirm: "Warning: Directory is not empty, all files will be deleted, are you sure?". -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi ARPA: dhesi@bsu-cs.bsu.edu
davidsen@steinmetz.ge.com (Wm. E. Davidsen Jr) (04/01/89)
In article <4251@alvin.mcnc.org> felstein@mcnc.org.UUCP (Bruce M. Felstein) writes: | The supposed bugs in ARCMASTER version 4xx and higher do not exist. If | people would bother to read the doc files they would have learned that | the directory that you specify for it to use to unarc and arc files to | MUST be a special blank directory, since it will erase the entire contents | of the directory after it finishes rearchiving the file. If you didn't | bother to read the docs you might specify your root directory to use | for this function and after ARCMASTER was done, it would automatically | erase all files in that directory. Arther Clarke said "Any technology sufficiently advanced is indistinguisable from magic." I say "A program sufficiently destructive in default operation is indistinguishable from a trojan." BTW: a virus spreads, the default of this program is to sterilize itself and your files. Perhaps we need a new class of evil, the "kamakazi." I have removed this program from the sixhub archives. -- bill davidsen (wedu@crd.GE.COM) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
allbery@ncoast.ORG (Brandon S. Allbery) (04/07/89)
As quoted from <4251@alvin.mcnc.org> by felstein@mcnc.org (Bruce M. Felstein): +--------------- | The supposed bugs in ARCMASTER version 4xx and higher do not exist. If | people would bother to read the doc files they would have learned that | the directory that you specify for it to use to unarc and arc files to | MUST be a special blank directory, since it will erase the entire contents +--------------- Bogus design. Why doesn't it either (a) create a scratch directory for its own use or (b) make sure the directory is empty before running (that can even be done from a batch file: IF EXIST %1\*.* GOTO BADDIR)? I suggest that people who use ARCMASTER use a wrapper script which does one of the above, as a sanity check. ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser
matt@hprnd.HP.COM (Matt Wakeley) (04/10/89)
> +--------------- > | The supposed bugs in ARCMASTER version 4xx and higher do not exist. If > | people would bother to read the doc files they would have learned that > | the directory that you specify for it to use to unarc and arc files to > | MUST be a special blank directory, since it will erase the entire contents > +--------------- > > Bogus design. Why doesn't it either (a) create a scratch directory for its > own use or (b) make sure the directory is empty before running (that can > even be done from a batch file: IF EXIST %1\*.* GOTO BADDIR)? > I suggest that people who use ARCMASTER use a wrapper script which does one > of the above, as a sanity check. Why doesn't the program just remember which files it creates and then only erase those files? Sounds like a VERY bad design to me.