VIRUS-L Digest Monday, 13 Mar 1989 Volume 2 : Issue 63 Today's Topics: Computer Security Conference in NJ Espionage Notarization Use of Digital Signatures Use of Digital Signatures Re: Macs with wills of their own Merry Christmas... I think :-( --------------------------------------------------------------------------- Date: Fri, 10 Mar 89 09:10:26 EST From: joes@dorothy.csee.lehigh.edu (Joe Sieczkowski) Subject: Computer Security Conference in NJ Apparently someone's holding a computer security conference soon. [Taken from IEEE Newsletter, March 1989, Vol. 35, Number 9] [Reprinted without Permission] On March 23, 1989 the North Jersey Joint Computers and Communications Society will meet to hear a talk on "Computer Security." The speaker will be Dr. Roy S. Freedman of the Polytechnic University. This meeting replaces the one planned on March 22nd entitled "Cryptography" and will broaden the subject to include the whole field of computer security. ...[Cut Paragraph]... ...He [Dr. Freedman] will also discuss how some recent work in cryptographis systems may thwart computer virus attacks, and how computer surveillance should be used to assess the "health" of an installation. ...[Cut Paragraph]... Time: 8:00 PM, Thursday, March 23, 1989. Place: ITT Club House, 417 River Road, Nutley, NJ Further Info: Elliot L. Gruenberg (201)662-0751 [End of article] Has anyone heard anything about this conference? Perhaps its worth attending... Joe ------------------------------ Date: Fri, 10 Mar 89 12:49:01 EST From: joes@dorothy.csee.lehigh.edu (Joe Sieczkowski) Subject: Espionage All (or almost all) of the viruses/worms/trojans we have seen on the list have been found because of one of the following: (1) An error [Lehigh virus, Internet worm] (2) It advertised itself [ping-pong, scores] (3) It blatently destroyed something [...(I'm sure you can think of some)..] Most of which were propably developed and released immediately; ie V1.0 (I guess most of you had experience with V1.0 software packages :-) Picture a group of programmers from firm "A" who wish to see their competetor's (firm "B") data. Firm A designs a virus that will place a very special back-door in a computer system. After the virus successfully installs the back-door, it removes itself from the system leaving no trace. However, Firm A doesn't release it right away. They put this very "controlled" virus on their own computer system for testing. They watch for symptoms, accumulate statistics, and wait for their users to have trouble with normal operations. After six months or so, when the have all the bugs worked out Firm A manages to have Firm B's computer infected. In a certain amount of time (whatever Firm A's statistics say), Firm A is pretty sure Firm B's computer has the back door installed. Firm A then proceeds to steal Firm B's data through the back-door. You have to start to wonder, if a single person can quickly hack out a decent virus, what can a company do if they dedicate a team of system programers to the project. Joe ------------------------------ Date: Fri, 10 Mar 89 21:38 EST From: Lambert@DOCKMASTER.ARPA Subject: Notarization I would like to reiterate that - cryptographic notarization can be a strong tool for protecting computer systems from virus attacks. It is not the only mechanism required for complete protection. Other components of a complete system might include strong memory management, a "trusted" software base, and security policies and procedures. The policies and procedures are actually the most important in that they are what most of us now rely on. Since the only feedback on my proposal so far has been negative, I would like to respond to Jeff Ogata's criticism: >.... 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). Wrong. Many mechanisms can be used to protect the software that might check a "cryptographically sealed" program. The simplest is to restart a computer with the verification software on a disk with the write protect tab set. Other schemes are possible and are independent of the cryptography and data formats. > ... 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. I am proposing a hierarchical notarization system. Only one piece of information and the verification software, or hardware, must be delivered to all users. All further notarization signatures are delivered with the "sealed" information. This means that "untrusted" means can be used for the distribution of the software and the softwares signature. If you are interested please read ISO 9594-8 (aka CCITT X.509). > ... Such signatures would be just as easily corrupted as the >programs in question. Wrong. Read any recent article on public key cryptography. In response to Don Alvarez's comments that: >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. It is interesting to note that public key algorithms are based on NP-complete algorithms (eg RSA). In this branch of mathematics, know as complexity theory, it possible to prove that the problem in the class NP-complete, but not if a particular problem might be "solved". In particular, the RSA scheme would be weakened if a major breakthrough was made in the factoring of numbers. This is very unlikely, but not provable. The RSA algorithm, even with this slight uncertainty, is considered to be "good". This is an interesting topic, but I believe that Don was referring to issues relating to proving implementations correct. He is correct that this is desirable for a specific implementation. I still maintain that the development of a software notarization standard is independent of these considerations. >Unless that black-box is designed into the physical architecture of >the computer you get NO PROTECTION from it. Yes, but the "black-box" could be software. The minimum required of the physical architecture is a reset switch and a disk write protect mechanism. I would propose that given a single "trusted" verification program, a system could be "bootstrapped" so that all installed software was verified. It is possible that a "sealed" program might contain a virus. This virus would be detectable if it altered any other "sealed" information. The source of the virus would then be directly traceable to the notarization authority, in this case the issuing software house. Once again, the software notarization does not solve all computer security problems. Policies and procedures are still required to ensure the correct usage of this tool in existing systems. Future computing systems could provide more assurances and the verification "black-box" in hardware. Paul A. Lambert Motorola GEG, Secure Network Section Lambert -at docmaster.arpa 8201 E. McDowell (602) 441-3646 Scottsdale, Az. 85252 ------------------------------ Date: Sat, 11 Mar 89 10:48 EST From: WHMurray@DOCKMASTER.ARPA Subject: Use of Digital Signatures Even in the face of digital signatures >The operating system and signature-computing program are still >healthy targets for attack. True. Digital signatures are not mechanisms for preventing attack. Rather, they are mechanisms for preserving trust, fixing accountability, and relieving the innocent. If you corrupt my signature verification mechanism, I can no longer rely upon it. However, in the presence and use of such a mechanism, I had to trust you before you could do that. If I trust you, you can always damage me, ONCE. That does not diminish the value of knowing that it is truly you (rather than someone pretending to be you) that I can no longer trust. William Hugh Murray, Fellow, Information System Security, Ernst & Whinney 2000 National City Center Cleveland, Ohio 44114 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 ------------------------------ Date: Sat, 11 Mar 89 10:32 EST From: WHMurray@DOCKMASTER.ARPA Subject: Use of Digital Signatures >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. The signature can be distributed with the program. If you verify it, it will give you confidence that it has not been corrupted since being signed. If you trust the signer, you can trust the code. Of course, you must have a trusted copy of the public key of the signer. You may get this from any trusted source (usually signed by the private key of that source, whose public key you already have and trust.) You must also have a small trusted space in which to verify the signature and store the keys. This will usually be your PC and a diskette for that purpose. (We cannot trust the managers of shared systems for this purpose.) Note that this is not a mechanism for creating trust; it is only a mechanism for maintaining and distributing trust which already exists. This does not require any invention or even implementation; an implementation is already available and its use has been endorsed by the Internet Activities Board. William Hugh Murray, Fellow, Information System Security, Ernst & Whinney 2000 National City Center Cleveland, Ohio 44114 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 ------------------------------ Date: 9 Mar 89 9:11 +0100 From: Danny Schwendener Subject: Re: Macs with wills of their own >If, when this is happening, there is a small "hand" icon in the upper >right hand corner of the screen (in the menu bar) then it IS Timbuktu, Note that there are other "foreign screen control" programs on the marketplace. One I'm particularly aware of is MoNet, by Juri Munkki in Finland. His package does the same, but does not display a warning on the foreign Mac, like Timbuktu does with the "eye" or "hand" icons. - -- Danny Schwendener ETH Macintosh Support ------------------------------ Date: Sun, 12 Mar 1989 16:07 EST From: Grey Fox Subject: Merry Christmas... I think :-( Oooh... Nasty christmas exec programs running around... It's an easy concept to grasp once someone does it... But has anyone thought to execute the original author of the damn thing? Oh well.. Anyway... Anyone ever think that one reason hackers write viruses is to prove that it can be done? I have a program that lowercases entire IBM VM directories... Dangerous to run, but written to prove that it could be done... And it could probably be hooked to a christmas exec spreader, or some sort of virus thingy that would corrupt other Exec files in a directory or a combination of the two... It has the potential to be devastating. (Which is why I am not releasing it). -Bruce Ide ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253