home *** CD-ROM | disk | FTP | other *** search
- VIRUS-L Digest Thursday, 9 Mar 1989 Volume 2 : Issue 61
-
- Today's Topics:
- Cartoons and wily hackers
- Re: Bouncing ball virus (PC)
- Warning: Urgent: A CHRISTMAS EXEC is around (IBM REXX)
- BUL EXEC - second issue (IBM REXX)
- Notarization
- re: notorizing
-
- [Ed. Please be advised that April 1 (fool's day) is rapidly
- approaching; it is not uncommon on the networks to find fake e-mail
- every year around this time. I will do my best to keep such mail from
- making it into a digest...]
-
- ---------------------------------------------------------------------------
-
- Date: Wed, 8 Mar 89 09:52:59 est
- From: ubu!luken@lehi3b15.csee.lehigh.edu
- Subject: Cartoons and wily hackers
-
- A couple of topics that have gotten a lot of attention recently on
- RISKS, among other places, are the use of cartoons to talk about
- viruses and the arrest of three West German "computer spies" (for lack
- of a better name). I thought I'd mention this here to find out what
- peoples' thoughts are on the subjects.
-
- Recent Dick Tracy (and reportedly other) comic strips have portrayed
- viruses and virus authors (the Dick Tracy strip apparently has a
- character who is using a virus for extortion). RISKS readers seem to
- think (by and large) that comic strips aren't too bad for talking
- about these things *if* they are portrayed accurately. Any thoughts?
-
- Also, those of us who've read Cliff Stoll's "Stalking the Wily
- Hacker" will be interested to hear that three people have now been
- arrested in West Germany in regards to the case described by Dr.
- Stoll. While this isn't directly virus related, it is interesting to
- note that the suspects used various computers and networks for
- espionage purposes. It will also be interesting to see the outcome of
- the case in the courts.
-
- Ken
-
- ------------------------------
-
- Date: Tue, 07 Mar 89 16:31:28 +0200
- From: Y. Radai <RADAI1@HBUNOS.BITNET>
- Subject: Re: Bouncing ball virus (PC)
-
- In #58 Rob Nauta asked about the bouncing ball virus. This was
- described in #18 (18 Jan), where I referred to it as the Ping-Pong
- virus. As I described it then,
-
- > It is a virus
- >which first appeared in Israel [in October 1988], and which got
- >its name because of a bouncing point which appears on the screen.
- >Like the Brain virus, it resides in the boot sector of disks, in bad
- >sectors, and in high RAM. ....
- > Among the points in which it differs from the Brain virus: (1) It
- >infects hard disks, not only 5 1/4-inch floppies. (2) It marks only
- >one cluster as bad. (3) It grabs only 2K of high RAM. (4) To the
- >best of my knowledge, it does not cause any damage to files or to the
- >FAT. In particular, the bad sectors seem to always be chosen from
- >unused clusters.
-
- The bouncing dot appears only under very special conditions: when
- (1) the system clock shows a multiple of 30 minutes and (2) the disk
- is being accessed. The simplest way to force the dot to appear (if
- RAM is infected) is to enter TIME 0 and then immediately type a cha-
- racter and press Enter. (Even after the dot appears, you can continue
- working. The dot will disappear only when you reboot or turn off the
- computer.)
- Other symptoms: 2K missing from RAM (or a multiple of 2K if infec-
- tion has taken place more than once); one bad cluster on disks. Both
- of these can be checked by performing CHKDSK, of course. If you see
- 1K in bad sectors on a diskette, that's a pretty sure sign of this
- virus since FORMAT marks bad sectors in blocks of 5K. (Anyone know
- why?) Note that when the virus marks the bad cluster, it does so on
- only one copy of the FAT.
- Finally, the virus causes access to diskettes to be slower because
- of the attempts to infect them.
- It seems to be more contagious than the Brain virus; presumably the
- main reason is its infection of hard disks also.
- In response to Rob's other questions, I'm fairly sure that there's
- no counter which will trigger further damage when it reaches some
- specified value, and that there's no specific "seeder" program.
- However, when Rob said that it spreads on bootable disks, he
- presumably meant *only* bootable disks, which is incorrect: like
- Brain, it also spreads on non-system diskettes. (They too have boot
- sectors.)
- At the time I posted my earlier article, I had not heard of this
- virus outside of Israel, so I assumed that it was a local product.
- Since then I've heard of it (or something very similar to it) in the
- UK (in May 88) and in Italy (and now in the Netherlands). In the UK
- it is referred to as the Italian virus since it was traced (by Dr.
- Alan Solomon) to Torino, Italy. (Some of the information given above
- was supplied by him.)
- In answer to Joseph Beckman's question, this virus is not just a
- splice of the Brain virus with ball code. On the one hand, it infects
- hard disks too; on the other hand it's considerably smaller than Brain
- and lacks some of Brain's features, such as feeding you the contents
- of the original boot sector when you try to look at the infected boot
- sector.
-
- Y. Radai
- Hebrew Univ. of Jerusalem
-
- ------------------------------
-
- Date: Wed, 8 Mar 89 16:19:26 GMT
- From: nad Turgut Kalfaoglu <TURGUT@TREARN.BITNET>
- Subject: Warning: Urgent: A CHRISTMAS EXEC is around (IBM REXX)
-
- From Linkfail list:
-
- A user here wrote a file called BUL EXEC which can distribute itself
- by using userid() NAMES.. it is almost identical to CHRISTMAS EXEC,
- but different picture.. Checks :node tag as well, and can jump from
- node to node.. The link will be down until we clean the problems
- here. -turgut
-
- ------------------------------
-
- Date: Wed, 8 Mar 89 20:40:46 GMT
- From: Turgut Kalfaoglu <TURGUT@TREARN.BITNET>
- Subject: BUL EXEC - second issue (IBM REXX)
-
- A follow up on BUL EXEC.........
-
- - ----------------------------Original message----------------------------
-
- After several hours of automatic reader scanning, there are no more
- copies of BUL EXEC on spool areas on TREARN. There are some that are
- RECEIVED to disks, but I have sent several warnings, and will be
- notifying everyone on this. I have a disconnected-running program to
- scan the RSCS queue repeatedly, and will be purging them if it comes
- accross a copy. Fortunately, we discovered the program, 10 minutes
- after it was released, by its author who warned us.
-
- I hope, and don't think that the file has jumped to the FRMOP22 line,
- but it may have jumped to the other Turkish nodes. (I have closed the
- FRMOP line for several hours due to this). Again, the filename is BUL
- EXEC, and it is a christmas exec (it sends itself to everyone on NAMES
- file) Regards, -turgut
-
- ------------------------------
-
- Date: Wed, 8 Mar 89 16:13:47 EST
- From: Jefferson Ogata (me!) <OGATA@UMDD.BITNET>
- Subject: Notarization
-
- >>.................... a simple virus like Brain will spread regard-
- >>less of program encryption, because it attaches to code that could be
- >>stored encrypted.
-
- I think this is a misquote. The original message said Brain will
- spread because it attaches to code that canNOT be stored encrypted.
- This was in reference to yet another suggestion that encryption (not
- cryptography in general) be used to keep executable files in a
- protected state, only to be unencrypted before execution. I'd like
- to remind readers that this scheme has important flaws: namely, the
- encryption program itself can be attacked; and the operating system
- can be attacked (by such as Brain).
-
- Regarding the idea of notarization of programs, I must assume you
- are referring to some method of distributing signatures of some
- kind, to be compared with signatures computed by the user who wants
- to know if a program is secure. It has been pointed out several
- times that if some channel exists whereby these signatures can be
- distributed without corruption, there is no reason why the programs
- themselves could not be distributed by the same channels. One must
- consider where the user needing authentication is going to acquire
- signatures: probably the same place he got the program -- a bulletin
- board. Such signatures would be just as easily corrupted as the
- programs in question.
-
- In order for a signature verification method to be viable, someone
- must come up with a method for verifying the signatures. Perhaps
- when this has been accomplished, we might discuss standards for
- signature generation. The operating system and signature-computing
- program are still healthy targets for attack.
-
- If you have some way of verifying signatures, or if you are talking
- about an entirely different mode of protection, I'd be very inter-
- ested to hear about it.
-
- - - Jeff Ogata
-
- ------------------------------
-
- Date: Thu, 9 Mar 89 00:36:53 EST
- From: Don Alvarez <boomer@space.mit.edu>
- Subject: re: notorizing
-
- Paul Lambert suggests that cryptographic notorizing is the solution to
- viruses, and then goes on to state:
-
- " To support the development of real cryptographic devices, standards
- must be available to ensure interoperability. The issues of a virus
- working their way around an implementation are not relevant to the
- development of the standards. Only the local implementation of a
- verification mechanism must be conserned with these issues."
-
- NOT TRUE!!!
- A standard is ONLY of value if you can PROVE that it can be
- implemented without theoretical weaknesses. Any cryptographic
- solution includes some black-box which does the magic to check the
- notorizing value, encrypt the password, or whatever.
-
- Unless that black-box is designed into the physical architecture of
- the computer you get NO PROTECTION from it. Why? because you can't
- trust the black-box. There is and will continue to be an enormous
- installed base of PC's, Vaxen, Suns, etc. These existing machines do
- not have any special notorizing hardware attached. That means either
- you force every IBM-PC user to install some $500 board in his machine
- that probably won't be compatible with his existing software, OR you
- modify his MS-DOS do to the cryptographic checks in software. The
- hardware solution is prohibitively expensive, and the software
- solution is worthless. The software solution is PARTICULARLY
- worthless if it's standardized (as many others have pointed out)
- because if it's standardized, then somebody has a standard they can
- set their virus to attack. DOS on your hard disk is just like any
- other file. It can be attacked and altered by viruses. It is true
- that there are excellent secure communication models for sharing data
- over an untrusted medium between mutually untrusting hosts (see
- Needham and Schroeder, for example, or any of the alphanumeric strings
- that Mr. Lambert quotes to prove this is all a solved problem) but all
- such models assume that the local magic box can be trusted. As long
- as the magic box is reprogrammable it is fundamentally untrustworthy.
-
- You can't use software to protect yourself against viruses, because
- software can be reprogrammed by the very computer you are trying to
- protect. You can't use hardware to protect existing computers against
- viruses, because it's not economically feasible. The only machines
- you can have any hope of absolutely protecting against viruses are
- next-generation machines which have watch-dog hardware built in (and
- I'm not even convinced that's possible).
-
- Standards are all well and good, but you HAVE to think about how they
- are going to be implemented, because if it can't be implemented
- securely, your standard isn't any good.
-
- I will be accused of being negative and pessimistic. That is true.
- If you are designing a security system you HAVE to assume the worst
- case, and the worst case in this case is that somebody writes a virus
- to attack the cryptographic software which your machine depends on.
-
- - Don
-
- + ----------------------------------------------------------- +
- | Don Alvarez MIT Center For Space Research |
- | boomer@SPACE.MIT.EDU 77 Massachusetts Ave 37-618 |
- | (617) 253-7457 Cambridge, MA 02139 |
- + ----------------------------------------------------------- +
-
- ------------------------------
-
- End of VIRUS-L Digest
- *********************
-
- Downloaded From P-80 International Information Systems 304-744-2253
-