From: Ralph.Hyre@ius3.ius.cs.cmu.edu 6-Dec-1988 6:34:16 To: misc-security@rutgers.edu Subj: [645] [### OLD MSG ###] > Can the courts compel Bozo to divulge the key and method > of encryption of the data on the seized computer? Bozo might be better off taking the Fifth on this one. I though I heard about a case where a user WAS compelled to decrypt the data. Anyone know of any other precedents? Since the police/DA can bring almost unlimited resources to bear on the problem, it is VITAL that the encryption be secure. -- - Ralph W. Hyre, Jr. Internet: ralphw@ius3.cs.cmu.edu Phone:(412) CMU-BUGS Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA "You can do what you want with my computer, but leave me alone!8-)" From: hplabs!marki@hpiacla.hp.com (Mark Ikemoto) 6-Dec-1988 6:44:17 To: misc-security@rutgers.edu Subj: [441] looking for DES code ### OLD MSG ### This is for a co-worker: He is looking for source code of an implementation of the Data Encryption Standard (DES). He is looking to encrypt user passwords, account passwords, etc., inside of message streams that are transmitted over a LAN. For security reasons, he is encrypting this data, and has chosen the DES as the standard to use for this purpose. Anything you can provide will be helpful. I'll route any responses to him. Mark From: ames!rochester!kodak!doering@ucbvax.berkeley.edu (Paul Doering) 6-Dec-1988 6:54:17 To: security@pyrite.rutgers.edu Subj: [436] Key management There are a few alternatives in the question of key-management for encryptors on data lines. Among these are (a) management by a central authority within the user's company, (b) dispersed management by site administrators within the company's network, and (c) management by the vendor of the encrypting hardware/software package. I would appreciate opinions on the strengths and weaknesses of these alternatives in practice. Thanks. From: *Hobbit* 6-Dec-1988 7:24:17 To: security@pyrite.rutgers.edu Subj: [472] Administrivia Naturally I've started to get submissions for the list, but there are some items of interest from "long ago" [i.e. things that were still sitting around in the incoming queue since last July] that I'd like to send out also. So that the readership doesn't get confused about who's answering who, I will add the string "### OLD MSG ###" to the Subject: lines of the applicable messages. I will attempt to find ones apropos of the "current things" being discussed.. _H* From: jbrown@jato.jpl.nasa.gov (Jordan Brown) 7-Dec-1988 13:17:12 To: misc-security@ames.arc.nasa.gov Subj: [1427] physical security This seems like a good forum to chatter about one of my pet peeves... I've worked at a couple of places where they placed some value on physical security. Computer rooms were locked; desks were often locked. This was a real nuisance, and pointless as well. Most desks have locks that can be picked with a paper clip, and that's the hard way to get into them. The easy way is to loosen the screws holding the center drawer up until it drops far enough to allow the latch to release. Takes about 30 seconds; leaves no marks. Similar methods can be applied to many cabinets. Most modern office buildings have false ceilings... unless your computer room has structural walls surrounding it, just remove a ceiling tile from an unsecured room adjacent to the computer room, climb into the false ceiling, and remove a tile from the ceiling in the computer room and jump in. Takes about 5 minutes. Physical security is just great (it's usually easier to prove than computer security, for sure), but if it isn't done carefully it just wastes people's time. Worse, it can give people a *false* sense of security. Relatedly... have your vendor's field service techs signed nondisclosure agreements? Are you sure there's nothing in your computer room that you want to hide? I once had a FS rep tell me that somebody had pumped him about the contents of our computer room... luckily he was ethical and didn't leak anything. From: 7-Dec-1988 13:18:15 To: security@pyrite.rutgers.edu Subj: [1460] Securing documentation sets in a public terminal room. [### OLD MSG ###] Hi, I've recently inherited the job of finding equipment designed to secure manuals in a public terminal room. We've had problems in the past as our current equipment does not allow us to lock the manuals to anything. We'll probably be placing most of a VMS 5.0 documentation set out for the students and we don't want to replace manuals which might be lost, damaged or stolen. I would appreciate hearing from any and all people who've had to deal with something like this in the past. What products have you used and what degree of success have you had? How easy is it to access the materials? Does the equipment handle the standard 3 ring binder paper along with DEC's smaller 3 ring binder manuals? Any other problems and/or notes of interest? Also, if other sites have different methods of giving students access to the manual sets, what (if successful) methods have you used? Just because we've used one system in the past doesn't mean we can't use something else which might be better. Please send all responses to me. And thanks! Steve Coleman Computing Services University of Massachusetts at Boston Boston Ma 02125 (617) 929-7837 Bitnet: COLEMAN@UMBSKY USERSERVICES@UMBSKY From: *Hobbit* 9-Dec-1988 2:41:23 To: security@pyrite.rutgers.edu Subj: [810] Duplicates Many of you have been complaining of duplicate messages, and I know quite well that they're being sent, and there's not a whole lot I can do about it. Some of the running sendmail delivery processes got gunned down by mistake, and more recently we had some problems with other machines which caused weirdness to happen on pyrite [nfs mounts and all that]. Thus when the queue restarted it found things waiting to be delivered and had no clue that they'd already been taken care of, so out they went again. I'm trying to get things smoothed out on this end but each message has many recipients, and Sendmail apparently *isn't* checkpointing the queue like it's supposed to, so unless a given message's delivery process is allowed to run to completion, we lose. Please bear with; you all have N keys... _H* From: GREENY 9-Dec-1988 3:21:23 To: Subj: [326] Locksmith Licensing Does anyone out there know the procedure that one would have to go through to legally be considered a locksmith? Thanx in advance... Bye for now but not for long Greeny Bitnet: miss026@ecncdc Internet: miss026%ecncdc.bitnet@cunyvm.cuny.edu Disclaimer: Nope....not me...I had nothing to do with it! P.s. I'm in Illinois... From: HXWY@cornella.cit.cornell.edu 9-Dec-1988 3:31:23 To: Subj: [924] Digital Cellular privacy protection I'm glad to see the news group back, because I really could have used it this semester. I recently finished two papers, one on blue box fraud, and another on cellular telephony privacy, and would have appreciated some input from the internet communitity. How about some input as to the security of the coming digital cellular telephone? I realize this was a subject kinda beaten to death a few years ago, but developments in technology have made digital cellular a marketable reality in about 1991. How soon is this going to be implemented? Can old phones be retrofitted? How hard is it for the hobbiest to change his usage to receive this? How about criminal elements, how hard are they going to go? Are they just going to give up on listening to "the soap opera without words"? Any input onto specifics of digital cellular implementation or when this is going to happen would be of interest (at least to me) djf From: desmedt@csd4.milw.wisc.edu (Yvo Desmedt) 9-Dec-1988 3:41:23 To: misc-security@uunet.uu.net Subj: [2224] UWM working group on DATA SECURITY [### OLD MSG ###] UWM WORKING GROUP ON DATA SECURITY The UWM Working Group on Data Security will be holding bi-weekly meetings at the University of Wisconsin-Milwaukee. The format of the meetings is informal. The workshop committee members are: Professor George Davida (Chairman) Professor Yvo Desmedt Telephone: (414) 229-5192 Telephone: (414) 229-6762 Professor Rene Peralta. Telephone: (414) 229-5861 Attendees (and visitors) who wish to present papers or preliminary results can contact one of the committee members to arrange the presentation. Topics of discussion will include: Applications of Data Security Physical Security Authentication Privacy Computer Networks Protocols Computer Security Pseudorandom Sequences Cryptography Secure Transactions Database Security Signatures Key Management Symmetric and OS Security Asymmetric Ciphers Trojan Horses (e.g. Viruses) The meetings will be on Fridays at 3:30 pm. [September 16,30: October 14,28 November 11,25: December 9. There will be no meeting December 23.] All the meetings will be held in: Room EMS E129, The Engineering and Mathematical Sciences Building, 3200 N. Cramer St., Milwaukee, Wisconsin 53201. U.S.A. For further information contact one of the committee members, or send e-mail to: arpa: uwm-crypto@uwm-cs.milw.wisc.edu bitnet: uwm-crypto%uwm-cs.milw.wisc.edu@wiscvm.bitnet csnet: uwm-crypto@uwm.csnet uucp: {seismo|nike|ucbvax|harvard|rutgers!ihnp4}!uwmcsd1!uwmeecs!uwm-crypto The US-mail address of the committee members is: Dept. EE & CS College Of Engineering & Applied Science University of Wisconsin-Milwaukee P.O. Box 784 Milwaukee, Wisconsin 53201. U.S.A. Telephone: (414) 229-4677 From: Michael Kielsky 9-Dec-1988 10:51:26 To: security@ubvm Subj: [1720] Please send data... [### OLD MSG ###] I am currently in the process of developing research for a thesis. The topic of this research is "Computer Security in the Manufacturing Environment". I am seeking your assistance in obtaining information relevant to this topic, as there currently exists no published data. Specifically, I would like to reach people in industry who have involvement in Computer Integrated Manufacturing (CIM), and related fields, and would be willing to provide me some information on their experiences with computer security in that environment. Helpful information would include policies and procedures (current or past), actual experiences, etc., regarding Computer Security (in its broadest interpretation), implemented specifically in the Computer Integrated Manufacturing (CIM) and related environments. Suggestions gladly considered. The data obtained will be compiled and published in Spring 1989, as my master's thesis. I can be contacted as follows: work: home: Michael Kielsky 1902 E. St. Catherine Sr. Software Engineer Phoenix, AZ 85040 TAG Software (602) 276-4663 5420-100 W. Camelback Glendale, AZ 85301 (602) 939-3580 or 242-9401 (602) 939-9671 (Fax) or via electronic mail: BITNET address: AGMGK@ASUACVAX DECnet address: ACVAX::AGMGK If you know of anyone else who might be able to help me out, please feel free to pass along a copy of this letter. Your help will be appreciated. Michael Kielsky From: kerchen@iris.ucdavis.edu 9-Dec-1988 11:01:27 To: Subj: [1481] Virus-writing [### OLD MSG ###] Nick Papadakis writes: "The only people that have to worry about viruses are those that don't distribute source" (or something close to that). I have to strongly disagree. Although it is much easier to put a virus or trojan horse or both into executable files, one could also put one into source code. This source code could then be distributed, with people compiling the code and running it at home with the same effect as a virus in an executable. One only has to be a little more clever in hiding the virus code amongst the legitimate code. Now, one might argue that all one needs to do is look at the code, but this quickly becomes unfeasible beyond 1000 lines of code (the limit of current automated program verification techniques is about 1000 lines). If a computer can only verify 1000 lines of code, what human being is going to want to try 2000? 10000? Indeed, distributing source is not the answer. punchline: I am currently researching viruses/trojan horses/etc here at the University of California, Davis, so I would be interested in pursuing this thread of conversation further. If you've had experiences with viruses, knowledge of viruses, or anything else which I or other interested parties might find useful, please don't hesitate to e-mail them to this group or directly to either me (kerchen@iris.ucdavis.edu) or my group (virus@iris.ucdavis.edu). Any contributions would be greatly appreciated. Paul Kerchen | kerchen@iris.ucdavis.edu From: Bernie Cosell 9-Dec-1988 11:11:27 To: misc-security@uunet.uu.net Subj: [1723] Why should passwords be aged? [### OLD MSG ###] I wonder if someone would indulge me with a mini-tutorial on why password aging is a good thing. It seems to be a veritable shibboleth among many of the system administrators around here (elsewhere too, I suspect) and I find it little more than a damn nuisance that lends virutally nothing to the overall security of the systems involved. I have several assumptions here: (a) the passwords are well chosen. I have *never* heard of anyone cracking a system with well-chosen passwords. I'm sure it has happened, but virtually all of the breakins I'm aware of involved either other soft-spots in the system (e.g., the rlogin stuff) or taking advantage of poorly-chosen passwords; (b) nobody will (or, probably, can) cryptanalytically attack the raw password information. (and on this, the SAs even admit that they're not really worried about this) When I press the SAs on just why it is that they like password aging so much, I get a lot of hemming and hawing, and a lot of places where password aging might slightly limit the damage due to administrative screwups (mostly having to do with shared accounts, which are mostly bad ideas in the first place). I can understand (and even sympathize) with the position of an SA being that "it makes me feel more comfortable to know that my @ss is a bit covered in case I screw up and forget to do something". But the almost totemic way that password aging keeps coming up over and over makes me think that there must be _something_ more substantive to it. Am I missing the obvious again? tnx __ / ) Bernie Cosell /--< _ __ __ o _ BBN Sys & Tech, Cambridge, MA 02238 /___/_(<_/ (_/) )_(_(<_ cosell@bbn.com From: Ralph.Hyre@ius3.ius.cs.cmu.edu 12-Dec-1988 23:19:36 To: Chriz@cup.portal.com Subj: [5010] Re: Value-Based Auditing [### OLD MSG ###] Cc: misc-security@rutgers.edu [attributed in its entirety, because I feel misc.security is a more reasonable place than sci.crypt, since it doesn't deal with encryption. Maybe misc.spooks is a better place:-).] In article <9511@cup.portal.com> Chriz@cup.portal.com writes: |One of the problems facing a securities organization is the |methods by which one detects and investigates security breaches |are resource intensive. I have concentrated on the |resource-squandering dimension of value-based spoofs, but |there is a dimension that will save the spy agencies alot of time |and money. Call it my contribution to the war effort. It's |called a "value-audit", and instead of empirically determining |whether a suspect has any untoward connections or activities, it |determines whether a suspect is capable of being a traitor. |Here's how it works: |1. A profile of the suspect is empirically determined, by |empathizing with the suspect. The profile delineates the values |by which the suspect functions. |2. The empathetic portrait of the suspect is used to determine the |value excesses that the suspect is capable of. For instance, is |he one who aggrandizes power--would he betray his country to |aggrandize power? Is he one who values money--would he sell out |for cash? Is he one with an ax to grind? and so on. The IRS does this already to some extent, its called block analysis. They buy companies' mailing lists, assuming that the companies' list target people who might have something to hide. For example, a subscriber to 'Boating Week' might be hiding unreported 'undergound' income in the form of a yacht. They might assume that Wall Street Journal readers make more than $30K/year. (The goverment also sells lists of names they collect to mailing list companies, it would appear. I may be able to dig up an example, but I think amateur callsigns & info are made available to various ham organizations.) |3. With the value excesses determined by the empathetic portrait |of the suspect, the investigative agency assumes control of his |personal inputs and outputs. His credit card statements become |the product of a government computer, his electric and phone |bills are produced by a government computer, and certain phone |numbers, such as the phone number to the electric company are |routed to the government. This is so the entire entity of bills, |phone calls, and work habits becomes a totally observable system |which the audit trails can be carefully mapped. I'm reluctant to give the goverment the power to 'impersonate' other entities, there should be a principle of 'least interference' with everyday affairs in ANY preliminary or ongoing investigation. |4. With this in mind, a series of subtle pranks are conducted |which test a series of potential value excesses. At work, he may |find that he is the only one who knows about an error on the |books. At home, he may find his utility bill underestimated and |credits he doesn't deserve given to him. He may be introduced |through the mail to a young woman. An unidentifable piece of |hi-tech equipment may appear via at his doorstep, misaddressed |to him. I'd fix everything else, but I believe you ARE legally allowed to keep unsoliticed packages (received by U.S. Mail). So I'd keep the high-tech equipment, of course :-). |5. The point is this, a series of events spanning a period of time will |occur forcing the man to make an effort to maintain his integrity |and good name. They may also be the "tip of the iceberg" type of |events that produce more information than they impart to the man. |In that case, it will give the man a hint that he is being |investigated and his reaction may be judged. This smacks of entrapment. |6. For an innocent man, this will be an inconvenient but barely |noticed security check. For a guilty man, it will be an |unbearable series of potential disasters. At any given point, |the empathetic portrait of the man will yeild a series of |possible "innocent" responses, and at any given moment a series |of "guilty" responses. A consecutive series of guilty responses |would be the start of a normal investigation. This is the same argument given for the loosening of the exclusionary rule; I don't agree with assuming guilt over innocence. |7. This could be computerized, so that a number of people could |be efficiently tested at a given moment, and thus saving the |government alot of money. | |I did use this technique in a bank, once, and discovered a |multi-million dollar tax fraud scheme which was based on the fact |that the bankers were so busy playing internal politics, that |nobody was minding the shop. That was their value-excess. This is interesting stuff, but I'd worry about OUR government using it on its own citizens. Comments? -- - Ralph W. Hyre, Jr. Internet: ralphw@ius3.cs.cmu.edu Phone:(412) CMU-BUGS Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA "You can do what you want with my computer, but leave me alone!8-)" From: Devon Sean McCullough 12-Dec-1988 23:26:25 To: security@pyrite.rutgers.edu, risks@csl.sri.com Subj: [921] security + freedom = accountability [### OLD MSG ###] I'm not on either of these lists, but here's my plug for peace, freedom, and the ITS way. On the oldest running operating system around, no software ever presumes to prevent any human from doing anything whatsoever, for this is a matter to be settled between humans in traditional human ways. You trash my files, I break your face. There are railings to keep the rubes from hurting themselves but no locks. Security in obscurity. Daily backups and automatic logging of important doings have kept ITS running smoothly for decades in the face of hurricanes and high school crackers with diplomatic immunity. We even have a sort of neighborhood watch and apprenticeship feature, so anyone can observe and learn about the activites of anyone else. Write-once media such as laserdisks afford any system the security of full backups and tamper-proof logs without infringing on any user's freedom to do his or her work. From: mason@eddie.mit.edu (Mark Mason) 13-Dec-1988 10:20:41 To: marki@hpiacla.hp.com@hplabs.uucp, misc-security@rutgers.edu Subj: [225] Re: looking for DES code Bob Baldwin (baldwin@xx.lcs.mit.edu) wrote a des package th that is (literally) 100 times faster than the unix crypt call. It is (or at least was) available for uucp from eddie.mit.edu in /usr/spool/uucppublic or some such. From: "R. Gary Cutbill" 13-Dec-1988 10:30:41 To: security@pyrite.rutgers.edu Subj: [428] Dual key encryption systems [If he's talking about standard public-key, please reply to him, not the list. Thanx. _H*] Hi, I understand that there exists a scheme for data encryption/decryption which envolves having a public key which is the product of two "large" prime numbers. Can anybody tell me about how large is "large". Obviously this is a variable number. I'm just looking for a range of magnitude. -R. Gary Cutbill Cutbill@d.cicg.rpi.edu From: lvc@cbnews.att.com (Lawrence V. Cipriani) 13-Dec-1988 10:40:41 To: misc-security@att.att.com Subj: [632] Additional security to login [### OLD MSG ###] Some versions of the login program (eg in UTS), the user must enter two passwords. One is the users password, the second "External Security Password" (ESP) is defined by the system admin. The ESP is changed once a month on the systems here with it. Concerns about users having dumb passwords, like abc123, are thus reduced, as the ESP is usually hard, but rememberable. What do people think about this? Is it worth the trouble? If you're writing a PD login you might consider adding this feature (and make it optional). -- Larry Cipriani, AT&T Network Systems, Columbus OH, Path: att!cbnews!lvc Domain: lvc@cbnews.ATT.COM From: Joe McMahon 13-Dec-1988 22:40:47 To: security@pyrite.rutgers.edu Subj: [328] Re: Virus-writing I'm sure that many (or most) of the subscribers to this list are aware that there is a virus discussion list at the LISTSERV at LEHIIBM1 (TELL LISTSERV AT LEHIIBM1 SUB VIRUS-L your-name). There is also an Internet version of this list, but I'm not sure what the node address is, nor how to sign up on the Internat. --- Joe M. From: zemon%pernod.DEC@decwrl.dec.com (Art Zemon) 13-Dec-1988 22:50:48 To: security@pyrite.rutgers.edu Subj: [728] Re: physical security And a lack of real physical security virtually eliminates any computer (i.e., on-line) security that you may have implemented. For instance, what good are file protections if the backup tapes are physically available to anyone in the building on weekends? Unless you can guarantee physical security of the computer, its console, the backup tapes, and the disks, and probably any network connections, it is probably best to consider a computer to be almost completely unsecure. I advise people that there is only one way to keep private information on a timesharing computer: move the information to tape and lock the tape in a vault. -- Art Z. (expressing opinions, naturally, that don't represent my employer) From: the terminal of Geoff Goodfellow 13-Dec-1988 23:00:47 To: other_list@ucbvax.berkeley.edu Subj: [759] Sun has tamperproof UNIX, 4.5BSD and secure electronic mail? PC Week Connectivity, Page C/8, December 5, 88: Sun's New Unix To Be Its Most Tamperproof Yet Gearing up to meet the growing demand for securing computing envionrments, Sun Microsystems Inc. has announced SunOS Multi-Level Secure, which company officials claim is the most tamperproof version of its Unix operating system to date. ... Developed by Sun Microsystems Federal Inc., a wholly owned Sun subsidiary based in Washington, the secure system software runs on Sun's 3, 4 and high-security Tempest workstations and is based on Sun's version of Unix, which merges Berkeley 4.5 Unix with AT&T System V. ... SunOS MLS has provisions for securing electronic mail and ensuring that users have the appropriate level of classification to access data. From: Phil Springer 15-Dec-1988 8:22:26 To: security@pyrite.rutgers.edu Subj: [399] Re: Securing documentation sets in a public terminal room. My response to this is to put the manuals in the library and have them for check-out wit an ID. They would be due in 1-3 hours after they are checked out. At Arizona State, we put them behind the operators counter where they get their printouts, and ask for ID to use them. If they don't return the manuals, they are charged $50 regardless of the cost of the manual. This idea seems to work well. From: (Mike Litchfield 'Flashback') 15-Dec-1988 8:42:27 To: security@pyrite.rutgers.edu Subj: [449] Cellular phones I think that since since cellular phones are infact radios broadcasting over open airwaves and privacy laws do not apply the next big feature which will be seen on them is a scrambler. admittedly this is not going to stop a dedicated snoop but like most passive security devices it will make it a bit more difficult. -michael RML3362@tamvenus - bitnet RML3362@tamvenus.tamu.edu - internet TAMU-CSC has no idea what I think or say. nor does it care From: wstef@beta.uucp (W. Gregg Stefancik) 15-Dec-1988 9:02:27 To: security@pyrite.rutgers.edu Subj: [514] Re: Locksmith Licensing According to my sources (the locksmith trade journals) very few states have any form of licensing for locksmiths. In the cases where licensing does exist it usually has nothing to do with proving ones skills as a locksmith. For example California has a licensing requirement. To obtain this license one is required to submit their fingerprints a form to the state. From what I understand the state runs a simple background check to make sure you are not a "criminal." Gregg Stefancik Professional Locksmith From: gwyn@smoke.brl.mil (Doug Gwyn ) 15-Dec-1988 20:02:30 To: misc-security@uunet.uu.net Subj: [516] Re: Locksmith Licensing >Does anyone out there know the procedure that one would have to go through to >legally be considered a locksmith? Some locales require certification testing, others don't. Practically speaking you should be bonded before you offer professional security services, to insure your customers. Check with your local police, because in many locales "possession of burglar tools" is considered a crime. (I disagree with such laws; it is commission of burglary that should be the crime, not ownership of a flashlight.) From: PJS%naif.JPL.NASA.GOV@Hamlet.Bitnet 15-Dec-1988 20:22:30 To: security%ubvm.bitnet@Hamlet.Bitnet Subj: [634] Re: virus-writing >I have to strongly disagree. Although it is much easier to put a >virus or trojan horse or both into executable files, one could also >put one into source code. This was in fact attempted on a BBS used by one of the columnists for DEC Professional; in a recent issue he describes how he nearly released a DCL command procedure that contained an innocuous-looking command that in fact, when symbols were translated, would erase all system files (after ensuring that it had all necessary privileges, done earlier in an above-board manner). He's practising safe computing from now on. Peter Scott (pjs%grouch@jpl-mil.jpl.nasa.gov) From: DAvid James Flory 15-Dec-1988 20:42:30 To: SECURITY@pyrite.rutgers.edu Subj: [776] Digital Cellular phones Found some information on digital cellular phones. will reduce cellular calls to a hiss so no monitoring by scanners. Will not be doable until 1995. Europeans are testing it. When its implemented it will have to support two kinds of the cellular phones, both analog and digital. some channels will be digital, others analog, analog will be gradually phased out. can have up to 8 users per channel. will use either FDMA, TDMA or CDMA (what is CDMA. Code Division Multiplexing means nothing to me.) not all markets will get this in the forseeable future. (only the top 5 or so) found this in a paper by Dr. Herschel Shosteck "the long range demand for cellular telephone service" Proceedings of the National Communications Forum Volume XXXXI Book 2 pages 889-897. djf From: tedrick@ernie.berkeley.edu (Tom Tedrick) 15-Dec-1988 21:02:30 To: Chriz@cup.portal.com, Ralph.Hyre@ius3.ius.cs.cmu.edu Subj: [137] Re: Value-Based Auditing Cc: misc-security@rutgers.edu These ideas aren't new (KGB does things like that according to Suvurov, and so on). Not to say it isn't interesting. Best, -Tom From: simsong@athena.mit.edu 15-Dec-1988 21:22:31 To: mason@eddie.mit.edu Subj: [626] looking for DES code Cc: hplabs!marki@hpiacla.hp.com, misc-security@rutgers.edu Date: Tue, 6 Dec 88 15:54:02 EST From: mason@eddie.mit.edu (Mark Mason) Bob Baldwin (baldwin@xx.lcs.mit.edu) wrote a des package th that is (literally) 100 times faster than the unix crypt call. Bob Baldwin did not write a DES package, nor does the unix crypt call perform DES encryption. Unix crypt runs a modified version of DES, and it is this modification which Bob Baldwin wrote a fast package for. Bob's program does a direct translation to the Unix encrypted string, possible because the Unix call throws away so much information. It is this discarding of information that Baldwin's program exploits. From: linnig@skvax1.csc.ti.com 21-Dec-1988 9:55:34 To: security@tilde.csc.ti.com, linnig@tilde.csc.ti.com Subj: [756] re: password aging Our systems here use password aging, and it is a damn pain in the @ss. We have two levels of passwords to get through when we log in via dialin. I use two different dialin nodes, and have different passwords for each. I have four different accounts on two different machines. Password aging forces me to have different passwords for all of these (they age at different rates). This makes me write all this down somewhere. Having my passwords on paper seems a lot less secure than having one password for the machines and a different password for the dialins (I grudgingly allow the need for them to be different). I can memorize two passwords. Keeping track of six passwords that expire from time to time is a hell of a lot harder. Mike Linnig From: John Laws (on UK.MOD.RSRE) 21-Dec-1988 10:15:35 To: Bernie Cosell <@relay.mod.uk:cosell@bbn.com> Subj: [721] Re: Why should passwords be aged? Cc: misc-security <@relay.mod.uk:misc-security@uunet.uu.net> Bernie, 'Why should passwords be aged?' Because in using them they are at risk of being exposed. It matters not that you do not write them down. In typing them in your fingers movements may be observed from a distance, even the sound of your typing can be a great assistance. You may move your lips to each charater of the password. Equally your password may be observed as it passes along the wires and computer switches of your comms path. The longer and/or more frequently you use a password the greater the risk that it may be exposed. How great that risk is depends on how often you can be observed ie length of comms lines, ability to tap lines, how often others are with you when you use it,...... John Laws From: Don Chiasson 21-Dec-1988 10:35:34 To: security@pyrite.rutgers.edu Subj: [644] Safe code (old msg, was virus-writing) Cc: kerchen@iris.ucdavis.edu, G.CHIASSON@xx.drea.dnd.ca Even searching the source code isn't a guarantee: a really determined foe could modify the compiler or run time library so that a virus was automatically inserted whenever a certain program was compiled or linked with libraries. I admit this is getting a bit far out: it is the old statement that a lock will stop only people who are dumb or not really dishonest. Even though most people will not examine all the source code, the threat that they could is enough of a deterrent. It does point out, though, that anyone who is *really* concerned about security such as the military or banks must take incredible precautions. Don From: Ken Wallewein 21-Dec-1988 11:15:42 To: Subj: [543] Why should passwords be aged? > I find it little more than a damn nuisance ... I've seen/heard others make similar comments lately. It got me thinking. I think I have one good reason. Although passwords are intended to be private things, known only to those with 'need to know', they tend to get spread around due to various extenuating circumstances. The older a password is, the likelier it is that this has happened, and the more people it is likely to have been given to. Changing passwords can be thought of as refreshing their confidentiality. /kenw From: Bertil Reinhammar 21-Dec-1988 11:33:57 To: security@pyrite.rutgers.edu Subj: [929] Re: Why should passwords be aged? Aging passwords are motivated by rejecting the assumption a) by Bernie Cosell stating that passwords are well chosen. They are *often not* so. Moreover, people do sometimes lend their passwords to others. Indeed not recommendable but that's my experience. It is virtually impossible to find all these sinners. Aging password limit the damage significantly since most of these indiscretions were supposed to be short term. ( In the dreadfull case of people persisting on leakage we can only hunt and kill. ) As a comment on Cosell's assumption on well chosen passwords I would say that the *only* way to get at least reasonable passwords is to reject certain classes of them. E.g. passwords used recently, passwords being close to user name, passwords being relatives names etc. Bertil Reinhammar Dept. of Electrical Engineering ...!uunet!mcvax!enea!rainier!bertil University of Linkoping, Sweden bertil@isy.liu.se From: Michael Stack 21-Dec-1988 11:54:48 To: Security Topics Discussion List Subj: [1013] Voting by Computer On the outside chance that there may be subscribers to this list who have not yet seen it: there is a fascinating (and long) article in the Nov 7 issue of The New Yorker on the subject "Voting by Computer". If ninety-five million Americans vote on Tuesday, November 8th, the decisions expressed by about fifty-two million of them will be tabulated according to rules that programmers and operators unknown to the public have fed into computers. Would {a "logic-and-accuracy public test"} discover, for example, a "time bomb" set to start transferring a certain proportion of votes from one candidate to another at a certain time, or any other programmers' tricks? "Of course not," Naegerle said. "It's not a test of the system. It's not security!" I encourage anyone concerned with the problems of computer security to find and read this article. It's an eye-opener, even for those of us acquainted or involved with security issues. Michael Stack Northern Illinois University From: packard!shz@att.att.com (S. Zirin) 22-Dec-1988 10:26:00 To: security Subj: [1415] Re: Locksmith Licensing The California locksmith license law requires locksmiths in the state to apply for a Locksmith Contractor's license which costs several hundred dollars annually. The state contractor's laws do not require other licensed contractor's (e.g., general, electrical, etc) to use only licensed locksmiths, but do require licensed locksmiths to use only licensed electrical (etc) subcontractors. The law provides for a simple background check, some form of general contracting test that has precious little to do with locksmithing, and yet another way for the state to increase their revenue. The national locksmith's organization, Associated Locksmiths of America (ALOA), does provide a Proficiency Registration Program (PRP) for locksmiths. Three levels of proficiency are recognized: RL = Registered Locksmith CPL = Certified Professional Locksmith CML = Certified Master Locksmith A locksmith must pass 12 categories on a uniform test to earn the RL designation, an additional 12 categories to earn CPL and (currently) an additional 9 to earn CML. The tests must be taken several times to ultimately earn the CML designation since there is a limit on the number of categories tested at one time. A locksmith with one of these designations has demonstrated a measurable level of locksmithing ability and is recognized by the national locksmith organization. Seth Zirin, Registered Locksmith att!packard!shz From: Jim Shaffer 22-Dec-1988 10:46:00 To: security@pyrite.rutgers.edu Subj: [5186] very weird IBM PC virus report The following were found on the Bitnet mailing list Virus-L@LehiIBM1.Bitnet. Does anyone have any more information on this subject? VIRUS-L Digest Monday, 12 Dec 1988 Volume 1 : Issue 42 --------------------------------------------------------------------------- Date: Tue, 6 Dec 88 08:33:44 PST From: eto@elroy.jpl.nasa.go Subject: Virus Carried by >2400 baud modem carrier This memo has been distributed at JPL, but I have not run across mention of the virus anywhere else: Subject: New Virus Sender: David I NAKAMOTO / JPL/01 Contents: 2. Part 1. TO: JEMS / JPL/01 Part 2. There is a new virus out there that is carried on the subcarrier of modems running at 2400 baud or higher. This virus was discovered by someone working in a Telecommunications company in Seattle. From my information, this virus is transmitted during a binary file transfer and uses the subcarrier to change registers inside your modem to spread the virus around. That's how it replicates. The virus attaches itself to all incoming binary data and infects the host's hard disk, causing random writes to sector after sector. The only apparent cure is to cycle the power on the modem or reset the modem registers BY HAND. To prevent the spread of the virus, it is recommended that you use 300 or 1200 baud only, that you refrain from file transfers, that sysops close their file transfer areas, and make backups of your hard disk every day in case of infection. Four systems are known to be infected with this virus, none on lab that I know of. A possible hardware fix is being developed that filters the subcarrier for this virus. End of Item 2. VIRUS-L Digest Tuesday, 13 Dec 1988 Volume 1 : Issue 44 --------------------------------------------------------------------------- Date: Mon, 12 Dec 88 22:02 EST From: Subject: more on modem virus A report of the so-called modem virus was posted to a local BBS here in Bloomington, Indiana, about a month ago. I know nothing about sub-carriers on 2400 baud modems, but I found the idea of a virus inhabiting the registers of a modem to be so fantastic that I dismissed the report as nothing more than a prank. Below is a copy of the first message in the report, it was followed by a series of messages as the virus allegedly spread through Washington State. Jon LaCure Indiana University lacurej@iubacs Report: ---------------------------------------------------------------------------- The following messages were found in the SnoBbs'ers echo Message #21191 "SnoBbs'ers" Date: 06-Oct-88 00:57 From: Tom Cooper To: All Subj: Worlds worst virus I found the following message thread on a Seattle board. Looks like a really bad virus is out now. TC -------------------------------------------------------------------- #1153 OF 1165 TIME: TUE 10-04-88 03:17:41 FROM: MIKE ROCHENLE TO: ALL SUBJ: Really nasty virus AREA: GENERAL (1) I've just discovered probably the world's worst computer virus yet. I had just finished a late night session of BBS'ing and file trading when I exited Telix 3 and attempted to run pkxarc to unarc the software I had downloaded. Next thing I knew my hard disk was seeking all over and it was apparantly writing random sectors. Thank god for strong coffee and a recent backup. Everything was back to normal, so I called the BBS again and downloaded a file. When I went to use ddir to list the directory, my hard disk was getting trashed agaion. I tried Procomm Plus TD and also PC Talk 3. Same results every time. Something was up so I hooked up my test equipment and different modems (I do research and development for a local computer telecommunications company and have an in-house lab at my disposal). After another hour of corrupted hard drives I found what I think is the world's worst computer virus yet. The virus distributes itself on the modem sub-carrier present in all 2400 baud and up modems. The sub-carrier is used for ROM and register debugging purposes only, and otherwise serves no othr purpose. The virus sets a bit pattern in one of the internal modem registers, but it seemed to screw up the other registers on my USR. A modem that has been "infected" with this virus will then transmit the virus to other modems that use a subcarrier (I suppose those who use 300 and 1200 baud modems should be immune). The virus then attaches itself to all binary incoming data and infects the host computer's hard disk. The only way to get rid of the virus is to completely reset all the modem registers by hand, but I haven't found a way to vaccinate a modem against the virus, but there is the possibility of building a subcarrier filter. I am calling on a 1200 baud modem to enter this message, and have advised the sysops of the two other boards (names withheld). I don't know how this virus originated, but I'm sure it is the work of someone in the computer telecommunications field such as myself. Probably the best thing to do now is to stick to 1200 baud until we figure this thing out. Mike RoChenle From: Luke OConnor 22-Dec-1988 21:46:05 To: misc-security@watmath.waterloo.edu Subj: [254] Re: Additional security to login Seemingly the point is to increase security by extending the length of the original password. May I ask (i) how are the ESP passwords distributed? (ii) why doesn't the system admin. issue users with one password that it considers safe? Luke From: Jim Shaffer 22-Dec-1988 22:07:23 To: security@pyrite.rutgers.edu Subj: [517] Re: Virus-writing As far as I know, there is no "Internet version." Internet users may subscribe to VIRUS-L@LEHIIBM1.BITNET also. If you're on the Internet, send the SUB command as above in the body of a mail message to LISTSERV@LEHIIBM1.BITNET (or LISTSERV%LEHIIBM1.BITNET@CUNYVM.CUNY.EDU, as required by your mailer). For example: To: LISTSERV@LEHIIBM1.BITNET Subject: Enter your message. Hit control/z to end or control/c to quit: SUB VIRUS-L Joe User ^Z To submit articles to the list, mail them to VIRUS-L@LEHIIBM1.BITNET. From: wcs@skep2.ATT.COM (Bill.Stewart.[ho95c]) 22-Dec-1988 22:27:20 To: clyde!misc-security@gatech.edu Subj: [916] Re: Additional security to login ESPs are typically configurable, used on incoming modem lines but not on local network or hard-wired connections. If you have the kind of configuration where you use them, it's strongly recommended that, for lines that use them, you always prompt for login, passwd, and ESP, even if the person gets one of them wrong; otherwise a password-cracker can break things one at a time. Some additional guidelines: - make your passwd program check that the password is different from the ESP (you don't need a clear-copy ESP around to do this - just crypt with the ESP's salt) - think about whether the ESP should be the same as your LAN's dialin password, if your LAN has a modem pool that supports them. - for lines that use the ESP, drop DTR after (say) 3 bad attempts. -- # Thanks; # Bill Stewart, AT&T Bell Labs 2G218 Holmdel NJ 201-949-0705 ho95c.att.com!wcs # # News. Don't ask me about News. From: "W. K. {Bill{ Gorman" <34AEJ7D@CMUVM.BITNET> 23-Dec-1988 15:26:10 To: Art Zemon Subj: [408] Re: physical security All this assumes, of course, that the personnel concerned with any computer installation are "secure", i.e., safe from coercive incursions by potential terrorists, infiltrators or saboteurs. This must be true both on and off the job, or system penetration by a determined assailant is assured. Case in point: The various measures, of whatever effectiveness, surrounding casino employees in some locations. From: kerchen@iris.ucdavis.edu (Paul Kerchen) 23-Dec-1988 15:46:10 To: security Subj: [1504] Re: Additional security to login >... The ESP is changed once a month on the systems here >with it. Concerns about users having dumb passwords, like >abc123, are thus reduced... This system will certainly be more secure than a single password system, but only if the distribution of the ESP is secure. If the sysadmin simply mails the ESP to all the users, this doesn't lock out those users who are already accessing the facilities illegally. Of course, if the sysadmin cannot mail the new ESP, how can she/he distribute it without a major hassle? I can envision an administrative nightmare when trying to distribute the new ESP to all the users of a 100+ user system (and every month at that!). Clearly, there must be a way to securely distribute the ESP (off hand, nothing comes to mind, but there *must* be a way, right?). Another point is that some people really have poor memories. The ESP is "hard but rememberable" for some but for others it is hard and *un*rememberable. Therefore, they write it down and leave it near their terminal, workstation, etc. Of course, that is a classic password problem, but it must be considered as well. How about requiring all users to have two different passwords? Then, even if they choose 'abc123' and 'foobar', they are still more difficult to crack than either one by itself. Of course, the benefits of such a system do not come for free and they may even be outweighed by the penalties, but I'm just throwing this out for discussion. Paul Kerchen | kerchen@iris.ucdavis.edu From: dab@allspice.lcs.mit.edu 27-Dec-1988 9:46:26 To: security@pyrite.rutgers.edu Subj: [315] Cellular phones As I understand it, the driving force behind the Electronic Communications Privacy Act of 1986 was the celluar phone people trying to make it illegal to listen to cellular telephone frequencies. This isn't to say that scramblers wont become popular, but there is a privacy law that applies. David Bridgham From: "JOE ST SAUVER, (503) 686_4394 EXT 36" 27-Dec-1988 10:06:26 To: security@pyrite.rutgers.edu Subj: [404] RE: Cellular phones My understanding is that cellular phone transmissions *are* specifically covered by provisions of the Electronic Communications Privacy Act; however, numerous scanners are available which can be used out of the box to receive these frequencies, and many others that have these frequencies "deleted" are capable of being "fixed" to re-receive them with relatively trivial modifications. Joe St Sauver From: David Flory 27-Dec-1988 10:26:26 To: SECURITY@pyrite.rutgers.edu Subj: [1028] Digital Cellular Phones Unfortunately it is illegal to receive cellular telephone calls, even though they are broadcast on "public airwaves" The Electronic Communications Privacy Act of 1986 (PL99-508) makes the "intentional" (whatever that means) interception of cellular telephone calls punishable by a $500 fine and/or six months in jail. But this is hardly protection (considering how effective legislation has been with dealing with drug smuggling and the like) Digital cellular phones will take the analog voice transmission, and convert it to a digital stream that sounds much like static. Unfortunately one of my souces (Dr. Herschel Shosteck) is of the opinion that it wont be implemented until 1995 (after the Europeans get all their bugs in their digital cellular phonesout) Also, for several years the systems will support BOTH analog and digital cellular phones (some frequencies allocated for both) so some cellular calls will be monitorable for a while. Also, many markets will not switch to this technology for quite a while. djf From: "W. K. (Bill) Gorman" <34AEJ7D@CMUVM.BITNET> 27-Dec-1988 10:46:26 To: Security Digest Subj: [333] Re: very weird IBM PC virus report I will paraphrase what has been said on the SECURITY-L list: This seems to ba a rather obvious hoax, based on the theory that if one can't actually spread virii, spread rumors of virii. Take a *close* look at the signature on this report, i.e., Mike RoChenle, which comes out Micro Channel! Gimme a break! From: "Kenneth R. van Wyk" 27-Dec-1988 11:06:26 To: Security List Subj: [824] Re: very weird IBM PC virus report In a more recent VIRUS-L, I told the readers that the original message sent to some bboard by Mike RoChenle (read: Micro Channel) was undoubtedly a hoax. No one has yet come up with any information that could substantiate the original report. Please, everyone who reads this, assume that the original message was a hoax that was forwarded, in good faith, to my VIRUS-L forum. Regards, Ken van Wyk Moderator of VIRUS-L Kenneth R. van Wyk Calvin: Mom, I'm going to grow a LONG User Services Senior Consultant beard like the guys in ZZ Top! Lehigh University Computing Center Mom: That's great Calvin, do it! Internet: Calvin: Wow, I thought she'd put up more BITNET: of a fuss than that! From: Lynn R Grant 27-Dec-1988 19:46:27 To: Security@rutgers.edu Subj: [1395] Password Aging Re: Bernie Cosell's question about the usefulness of password aging: Password aging minimizes the amount of time that your password is open to attack. You may have a well-chosen password, but the longer it is used, the more likely it is that someone has looked over your shoulder and seen you enter it, or a line-tapper has read it off your communication line, or, if you are the type that writes your good password on a piece of paper, someone has discovered it. The DoD Password management guideline has another good use of this, though I have never seen it implemented the way they describe. Most systems I have seen will suspend your userid after you enter some number of incorrect passwords. You must then get a security administrator to reset it. This leaves you open to an easy denial-of-service attack. And if someone does it to all your security administrators, the whole shop is in trouble. To counter this, the DoD guideline suggests making the logon process get slower after the first few bad passwords are entered for a particular userid. That limits how many passwords can be tried in a given length of time, without leaving you open to the denial-of-service attack. If you calculate how many trys it will take on the average to guess your password, you can set up your password so it expires before then, making a brute force attack much harder. Lynn Grant From: Stan Horwitz 27-Dec-1988 20:26:27 To: Subj: [1830] Re: Virus-writing Hello. I was just at what was called an "emergency breifing" on viruses. The person who conducted the breifing is quite well known for his work in the area of viruses and computer security. His name is Dr. Fred Cohen. This was a very interesting meeting. One thing that surprised me is that public domain software is a smaller source of viruses than proprietary software which comes in those nice shrink wrapped packages. Since there is no regulartory agency whose job it is to certify software and it's potential for harboring viruses and legitimate bugs, proprietary software becomes just as easy to infect at the publishing house as any of your own disks. It also seems that few unversities or other institutions of higher education admit to viruses being a major problem. I don't know of any courses offered in the subject of computer security and virus detection. Are there any at your school? A question of relevance to this discussion is along the following lines. Is it not the ethical responsibility of our government to establish laws and guidelines which software must pass before being distributed? I know that the government has guidelines for itself about the integrity of software for it's internal systems. What about for consumers in general? We have laws regulating production of auto's and other consume products and services. The same should be true of software. There should be some sort of committee made up of individuals from government and private industry who are responsible for certifying software. For gosh sakes, even floppy disks must under some sort of certification! It's kind of silly to certify the integrety of floppy disks when we are allowed to purchase disks with software that might very well have a virus due to the lack of regulations and standards in this area. From: lypowy@cpsc.ucalgary.ca (grep) 29-Dec-1988 4:26:35 To: security@rutgers.edu Subj: [396] Re: Virus-writing Also, there is a new list called VALERT-L that is used for reports of virus infections ONLY (and immediate treatment procedures). You may subscribe to this list in the same manner used for VIRUS-L. Greg Lypowy University of Calgary Computer Science Department 2500 University Drive N.W. lypowy@cpsc.UCalgary.CA Calgary, Alberta, T2N 1N4 ...!{ubc-vision,ihnp4}!alberta!calgary!lypowy From: packard!shz@att.att.com (S. Zirin) 29-Dec-1988 4:46:36 To: security Subj: [564] Re: Locksmith Licensing >Practically speaking you should be bonded before you offer >professional security services, to insure your customers. Bonding and insurance are not the same. A bond protects your customer if you are convicted of being dishonest and does not protect against negligence. Liability insurance protects a customer against negligence. >(I disagree with such laws; it is commission of burglary >that should be the crime, not ownership of a flashlight.) You must therefore support the right of private individuals to own guns. Correct? Seth Zirin att!packard!shz From: compass!worley@ucbvax.berkeley.edu (Dale Worley) 29-Dec-1988 5:06:35 To: foo@ucbvax.berkeley.edu Subj: [2859] From risks-forum: Mitnick Date: 16 Dec 88 08:13:25 PST (Friday) From: Rodney Hoffman Subject: Armed with a keyboard and considered dangerous The 16 Dec 88 'Los Angeles Times' contains this story (excerpts only): EX-COMPUTER WHIZ KID HELD ON NEW FRAUD COUNTS By Kim Murphy Kevin Mitnick was 17 when he first cracked Pacific Bell's computer system, secretly channeling his computer through a pay phone to alter telephone bills, penetrate other computers and steal $200,000 worth of data from a San Francisco corporation. A Juvenile Court judge at the time sentenced Mitnick to six months in a youth facility.... [After his release,] his probation officer found that her phone had been disconnected and the phone company had no record of it. A judge's credit record at TRW Inc. was inexplicably altered. Police computer files on the case were accessed from outside.... Mitnick fled to Israel. Upon his return, there were new charges filed in Santa Cruz, accusing Mitnick of stealing software under development by Microport Systems, and federal prosecutors have a judgment showing Mitnick was convicted on the charge. There is, however, no record of the conviction in Sant Cruz's computer files. On Thursday, Mitnick, now 25, was charged in two new criminal complaints accusing him of causing $4 million damage to a DEC computer, stealing a highly secret computer security system and gaining access to unauthorized MCI long-distance codes through university computers in L.A. and England. U.S. Magistrate ...took the unusual step of ordering [Mitnick] held without bail, ruling that when armed with a keyboard he posed a danger to the community. "This thing is so massive, we're just running around trying to figure out what he did," said the prosecutor, an Asst. U.S. Atty. "This person, we believe, is very, very dangerous, and he needs to be detained and kept away from a computer." LA and FBI Investigators say they are only now beginning to put together a picture of Mitnick and his alleged high-tech escapades. "He's several levels above what you would characterize as a computer hacker," said Detective James K. Black, head of the LA Police Dept's computer crime unit. "He started out with a real driving curiosity for computers that went beyond personal computers.... He grew with the technology." Mitnick is to be arraigned on two counts of computer fraud. The case is believed to be the first in the nation under a federal law that makes it a crime to gain access to an interstate computer network for criminal purposes.... Federal prosecutors also obtained a court order restricting Mitnick's telephone calls from jail, fearing he might gain access to a computer over the phone lines.... From: Stan Horwitz 29-Dec-1988 15:40:42 To: Subj: [1830] Re: Virus-writing Hello. I was just at what was called an "emergency breifing" on viruses. The person who conducted the breifing is quite well known for his work in the area of viruses and computer security. His name is Dr. Fred Cohen. This was a very interesting meeting. One thing that surprised me is that public domain software is a smaller source of viruses than proprietary software which comes in those nice shrink wrapped packages. Since there is no regulartory agency whose job it is to certify software and it's potential for harboring viruses and legitimate bugs, proprietary software becomes just as easy to infect at the publishing house as any of your own disks. It also seems that few unversities or other institutions of higher education admit to viruses being a major problem. I don't know of any courses offered in the subject of computer security and virus detection. Are there any at your school? A question of relevance to this discussion is along the following lines. Is it not the ethical responsibility of our government to establish laws and guidelines which software must pass before being distributed? I know that the government has guidelines for itself about the integrity of software for it's internal systems. What about for consumers in general? We have laws regulating production of auto's and other consume products and services. The same should be true of software. There should be some sort of committee made up of individuals from government and private industry who are responsible for certifying software. For gosh sakes, even floppy disks must under some sort of certification! It's kind of silly to certify the integrety of floppy disks when we are allowed to purchase disks with software that might very well have a virus due to the lack of regulations and standards in this area. From: Phil Hochstetler 3-Jan-1989 10:29:18 To: misc-security@tektronix.tek.com Subj: [208] Re: looking for DES code Given all this mention of "fast DES code", how about someone posting how to obtain this code? Not all of us got a copy of it when it went by. -- Phil Hochstetler Sequent Computer Systems Beaverton, Oregon From: doug@lenti.uucp (Doug Davis) 3-Jan-1989 10:49:16 To: texbell!killer!misc-security@cs.utexas.edu Subj: [585] mkdir security bug ****FIX POSTED*** I just posted a fix to the recient /bin/mkdir security problem that was posted to news.admin. The fix was posted in both news.admin and comp.sources.misc. Those of you who have a setuid'ed root /bin/mkdir, or a non 4.2 BSD (or greater) system, will most likely be interested in this fix. doug davis -- Lawnet 1030 Pleasent Valley Lane. Arlington Texas 76015 817-467-3740 { sys1.tandy.com, motown!sys1, uiucuxc!sys1, killer!texbell } letni!doug "Talk about holes in UNIX, geeze thats nothing compaired with the security problems in the ship control programs of StarFleet." From: *Hobbit* 3-Jan-1989 11:09:16 To: security Subj: [541] modem worm I have trouble believing this one myself. That person that spreads such a rumor should include more in-depth technical details, like a genuine report from the Rockwell people as to whether this is possible or not. Any modem that can respond in that manner to "commands" from a *foreign* modem [not to mention being smart enough to inject code for the machine it's connected to into the bit stream?!??!] is far too smart for its own good. Someone with an in at Rockwell or whoever makes the relevant chip set give 'em a call, okay?? _H* From: "W. K. (Bill) Gorman" <34AEJ7D@CMUVM> 3-Jan-1989 11:29:16 To: PROFS Discussion List Subj: [421] mail encryption Is anyone familiar with a commercially available, two key (public key/private key) encryption/decryption system that might either run on, or be adaptable to run on, PROFS under VM/HPO and CMS? This would be primarily for internal use, as sending encrypted notes through the network in general raises other problems. Those-Who-Know-That-They-Know here are becomiong concerned about this issue. Thanks in advance. Bill. From: (Tom, Tech. Support) 3-Jan-1989 11:49:16 To: security@pyrite.rutgers.edu Subj: [1735] A response >>Check with your local police, because in many locales >>"possession of burglar tools" is considered a crime. >>(I disagree with such laws; it is commission of burglary >>that should be the crime, not ownership of a flashlight.) I presume that you are using some sarcasm here, but there are still two points I'd like to make as an ex-police officer of 9 years. 1. Commission of a burglary _IS_ a crime. In fact, it's a Felony in Pennsylvania, and it is defined as _any_ entry into a building with the intent to commit a crime. This would mean any crime, from rape to theft to criminal mischief. That's a statute with some teeth! 2. Posession of burglar tools is also a crime in this state. As with your flashlight example, there are many legitamate uses for almost anything ... even slim jims, pry bars, and dynamite have proper use. It is the circumstance surrounding the posession that makes the offense. A slim jim in the hands of someone who normally and routinely makes a living with locks does not imply an attempt to steal a car, but if he's found at 3:00AM with no owner around and a black box for hot wiring ... . BTW the same logic applies to deadly weapons. I have personnaly arrested and convicted on posession of a baseball bat, but rest assured that my defendant was not on the ball field. * HAVE A GOOD DAY * * * * Tom Mahoney * * Computer Electronics Tech. * * * * FRANKLIN & MARSHALL COLLEGE * * Computer Services * * Technical Support Center * * Lancaster, PA 17604-3003 USA * * * * Bitnet Address: TOM@FANDM * ********************************* From: CTM@cornellc.cit.cornell.edu 3-Jan-1989 12:09:16 To: "Security List." Subj: [672] Re: very weird IBM PC virus report Some of the people on the virus-l list have suggested that the modem virus is impossible and is indeed a form of virus passed around by HUMANS in the form of endless messages about the modem virus. Since the messages about the virus have hard names connected to them it would seem that this report could be checked out with thoroughness. It is a serious security risk to get people thinking there is a security risk when there isn't. While they are looking for the bug that ain't, the bug that is crawls in the back door. In my opinion this modem virus is probably real and should be looked into. I am using a 2400 baud modem to write this. From: ellis@godot.psc.edu (James Ellis) 3-Jan-1989 21:29:18 To: misc-security@uunet.uu.net Subj: [706] Re: Yet Another useful paper - really shadow password files I see many folks suggesting that password files should be regularly scanned to check for easily guessed passwords. And a number of sites have one style or another of a password cracking program for just this purpose. But is it not more appropriate for this effort to be put into the passwd(1) program itself to prevent people from using poor passwords in the first place? This certainly takes less cpu time and has the advantage of giving users immediate feedback on the quality of their passwords. BRL wrote a nice version of passwd with a number of such checks some years ago. MCNC added a history of previously used passwords and some other checks. It seems to work well with few user complaints. From: Glenn Hyatt 3-Jan-1989 21:49:18 To: G.CHIASSON@xx.drea.dnd.ca Subj: [1108] Re: Safe code (old msg, was virus-writing) Cc: security-request@pyrite.rutgers.edu >Even searching the source code isn't a guarantee: a really determined >foe could modify the compiler or run time library ... At the bank where I work we put very rigorous controls over updates to all code used "in production." When someone is given authorization to change or add code, a second person reviews the change, tests it, and moves it into production. The change actually made is then reviewed via audit trails and comparing link modules. Now, I'm a data security manager, and my boss pointed out that the integ- rity of the audit trails is a sine qua non in all of this. So I pointed out that the integrity of audit trails depends on the integrity of the code that produces the audit trail, which depends on the link modules for: the code that produces the audit trail, the compilers that compile it, the linker that links it, the address-translation mechanisms, the I/O modules involved . . . . Oh, yes, and how do we know that the piece of paper in our output bin is the one produced by our high-integrity audit trail? I'm getting out of data security. My brain hurts. - Glenn From: "Homer W. Smith" 5-Jan-1989 1:02:01 To: "Security List." Subj: [678] re: password aging Our system forces us to change the passwords every 90 days. However it does not keep track of the old passwords. Thus I comply and change the password, and then I change it right back again to the original. I know people who have used the same password for all their accounts on every computer they have ever touched for 20 years. Not bright, but I can understand the attitude. I guess people have not learned that passwords are not secure. Or that the only threat is random people who out of boredom might want to sign on. The dedicated hacker with years of programming aimed at cracking every encryption scheme in existance is beyond their ken. From: Harold Pritchett 5-Jan-1989 1:22:35 To: security@pyrite.rutgers.edu Subj: [891] re: password aging >Password aging forces me to have different passwords for all of these >(they age at different rates). Why not change all of them to the same thing when the first one expires (if what you really want is one password on all systems.) I personally like the idea of different passwords for each of my privileged accounts, and a single password for all of the non-privileged accounts. That way, if someone gets my one of my super accounts, they don't get all of them. I also have no problem with writing my passwords down and putting them in my wallet. If someone wants them bad enough to mug me for them, they can have them... It's not as if I have national security information in my accounts. Harold C Pritchett | BITNET: HAROLD@UGA BITNET TechRep | ARPA: HAROLD@UGA.UGA.EDU The University of Georgia | BELL: (404) 542-3135 Athens, GA 30602 | From: Chriz@cup.portal.com 5-Jan-1989 1:42:21 To: security-request@rutgers.edu Subj: [3080] Sparking a major investigation In a very old science magazine, there was an article about an experiment involving a camera lens and a piece of black tape. The black tape was used to cover the surface of the front of the lens. Small holes were cut in a regular pattern in the tape. The lens was then attached to a camera, and a line pattern was used as a target for the modified lens to focus on. Film recorded an image on the focal plane. The lens was able to record the line pattern clearly. The experimenter concluded that a huge telescope could be built in space by precisely aligning fragments of a "lens" in 3-d space, and recording information that passed through the precisely aligned lens fragments. Here is the point. If one views an intelligence agency as a giant lens with information only accepted at certain points (like the lens with black tape on it), and like a lens, the information is passed through and summarized on a focal plane (the top of the organization) one has the basis for playing dirty tricks on the organization. First, the organization is compartmentalized, and thus the receiving people on the surface of the lens have no idea that what they are seeing is part of a larger pattern. Thus, the receiving agents can be counted on to transmit the data received regardless of how strange an element the data forms on the focal plane. Second, if one can pinpoint the openings in the black tape, one can feed a series of simultaneous data at the face of the "lens" (like the line pattern mentioned above), and have a reasonable assurance that the pattern will be reproduced at the top of the spy organization. Here is a plan of attack based on this principle: Goal: To leave the sustained impression on those that keep an eye on things that there is a major new spy organization working on a major operation in the U.S. This will be done within the confines of the law, and without spending too much time or money doing it. A church group, charity, or other group of idealistic people could do it. Step 1: Gain attention. Note: phone books can be obtained in quantity, but virtually any other publication with low temperature data will work. a. In fifty cities, drop a small town (preferably from UTAH or Missouri) phone book in an envelope, with the address "Counterintelligence, Washington, D.C." on it. b. Send the same phone book to each embassy on embassy row in Washington D.C., and to each consulate around the country. c. Air freight copies of the same phone book to neutral central American or Latin American countries. d. Have groups who ordinarily attract the attention of the authorities place a copy of the phone book in their (sometimes broken into) offices. Step Two: At protest rallies, make sure that at least one person, and preferably twenty or thirty, carry the phone book. Step Three: Publish all protest letters, pamphlets, notices of meetings with a page from the phone book (with names and letters crossed out, or blacked out) reproduced on the back side of the publication. Step Four Suddenly cease having anything to do with the phone book. From: mhw@wittsend.lbp.harris.com (Michael H. Warfield (Mike)) 9-Jan-1989 8:27:36 To: misc-security@gatech.edu Subj: [1035] Re: Additional security to login > - make your passwd program check that the password > is different from the ESP (you don't need a > clear-copy ESP around to do this - just > crypt with the ESP's salt) Huh, not a good move. This would require that you use the same salt for every user and ES password on the system. The "crypt" based security is only marginally secure at best, to compromise the encryption algorithm by forcing the salt to a constant value is asking to get it cracked. You would be much better off crypting the ESP's in a fixed reversible maner AND protecting them through permissions (I like 400 root owner) and other obfuscations (hide it in a binary library or some other "inocuous" file). May not make it impossible to find but sure can make it tough and not compromise the user passwords in the process. --- Michael H. Warfield (The Mad Wizard) | gatech.edu!galbp!wittsend!mhw (404) 270-2123 / 270-2098 | mhw@wittsend.LBP.HARRIS.COM An optimist believes we live in the best of all possible worlds. A pessimist is sure of it! From: "Keith F. Lynch" 9-Jan-1989 8:47:36 To: Security@pyrite.rutgers.edu Subj: [1654] Another virus report Cc: KFL@ai.ai.mit.edu Forwarded from the VirusBoard BBS at (225) 617-0862 [sic] Date: 11-31-88 (24:60) Number: 32769 To: ALL Refer#: NONE From: ROBERT MORRIS III Read: (N/A) Subj: VIRUS ALERT Status: PUBLIC MESSAGE Warning: There's a new virus on the loose that's worse than anything I've seen before! It gets in through the power line, riding on the powerline 60 Hz subcarrier. It works by changing the serial port pinouts, and by reversing the direction one's disks spin. Over 300,000 systems have been hit by it here in Murphy, West Dakota alone! And that's just in the last twelve minutes. It attacks DOS, Unix, TOPS-20, Apple II, VMS, MVS, Multics, Mac, RSX-11, ITS, TRS-80, and VHS systems. To prevent the spread of this dastardly worm: 1) Don't use the powerline. 2) Don't use batteries either, since there are rumors that this virus has invaded most major battery plants and is infecting the positive poles of the batteries. (You might try hooking up just the negative pole.) 3) Don't upload or download files. 4) Don't store files on floppy disks or hard disks. 5) Don't read messages. Not even this one! 6) Don't use serial ports, modems, or phone lines. 7) Don't use keyboards, screens, or printers. 8) Don't use switches, CPUs, memories, microprocessors, or mainframes. 9) Don't use electric lights, electric or gas heat or airconditioning, running water, writing, fire, clothing, or the wheel. I'm sure if we are all careful to follow these 9 easy steps, this virus can be eradicated, and the precious electronic fluids of our computers can be kept pure. --RTM III From: J.D. Abolins 9-Jan-1989 9:02:21 To: SECURITY@pyrite.rutgers.edu Subj: [4492] personnel and security Reply to Mr. Gorman's comments about the "secureness" of the personnel True. There are factors that affect the level of the "secureness" of personnel, whether for a computer center, a casino, or whatever. Some of them are... 1. Self-motivated breaches of security: * Character of the each employee-- susceptibility to greed, to mutiny (ie.; revenge for wrongs, real or perceived), ideology, etc. * Atitudes towards reasonable security procedures. Some people tend to be lax in this area because of ignorance of the reasons for security practices, resentment of being told to follow procedures, apathy, overconfidence, power plays, laziness, foolish bravado, poor communication of the procedures by management, frustrating security procedures, encouragement by others not to use procedures, time pressures, effects of chemical dependency, depression, etc. * Ideology, which was mentioned above, does not have to be a matter of political ideology. It can encompass religious views, ethical views, and relational views. Difference in viewpoints/ideology is not neccesarily a security hazard. It becomes a security hazard when the conflict between the employee's ideology and the real or perceived ideology of the employer clash and the employee seeks to decide. The outcome of the decision is what determines if it threatens security. (Some may seek to sabotage by action or inaction; other may quit the job; still others may submerge their beliefs, leading to cognative disonance.) 2) Susceptability to influence by others: * The influence of family and friends. This can play off of the factors mentioned above. Family financial problems can make an employee more susceptible to greed. Family strife (eg.; divorce procedings, marital strife) may affect the employee's judgement, making him/her more susceptibilty to taking the anger out on the employer. Also, it is among familiy and friends where an employee might say too much about his employers security procedures. * The possibility of threats to self and/or, especially,to family opening the door to influencing an employee. This is a very tough issue. First, the impact of such threat, the perception of choosing between family and the job, etc. weigh heavily upon any normal person. Second, most people, outside of regimented situations such as the military, see that they are not paid well to risk their own lives, let alone that of their spouse or children. * The prevelence of "social engineering" by many intruders under- scores a major vulnerability. "Social engineer" is the practice of wheedling, coaxing, threatening, etc. pieces of useful info out of a company's employees. The techniques used can vary greatly. One of the main safeguards is the clear communication and practice of basic security precepts. For example, passwords are not to be divulged over a phone nor by mail to anyone, no matter who they claim to be, is a start. Some of these factors present special challenges for the civilian employer. While some companies are now taking a careful look at their employees' personal lives, looking for signs of financial or marital difficulties, chemical dependencies, etc., this comes with great risk to the civil liberties of the employees. This factor is compounded by the polycotomous view of modern man- the the man/woman in the office has no linkage to the same person at home; that problems can be left at the door of the office. Yet some companies find that by gently keeping of possible turmoil in an employee's life, giving counseling/treatment opportunities, and by reassinging the person to less critical tasks, that they can help the employee and themselves. Another challenge is giving ways for the employees to notify the employer about security threats. This is important for cases of social engineering and for case of threats against the employee and his/ her family. If they do not have a way of seeking help, they may be more likely to acquiesce to the demands. Also, in the case of "social engineering", the employee should be aware of what it is and that it is better to report such attempts to a security manager. J.D. Abolins 301 N. Harrison Str. ; 197 Princeton, NJ 08540 This is purely may off-the-cuff opinion. It does not represent the views ofthe NCC, the DEP , or anybody else. From: gloom!cory@encore.encore.com 10-Jan-1989 18:34:37 To: security@rutgers.edu Subj: [920] Zero knowledge passwords? How many of you have ever either written or run into 'login simulators'? Of those of you who haven't, how many of you could write one? (Does everyone have their hands up now?) Are there any systems out there that implement some way of verifying that the program that you (the prospective user) are talking to is really the login program? a program that SHOULD be trusted with your password? Anyone got any good ideas on how to do this? +C -- Cory ( "...Love is like Oxygen..." ) Kempf UUCP: encore.com!gloom!cory "...it's a mistake in the making." -KT [Moderator note: It's one of the first things the engineering frosh do on our vaxcluster. If the faculty involved took the time to educate these people a little better about the computer they were supposed to use, significantly fewer people would fall victim to this -- as it is, they run around so pitifully clueless, that such games usually work. _H*] From: etg!acheron!scifi!njs@uunet.uu.net (Nicholas J. Simicich) 10-Jan-1989 18:54:08 To: misc-security@uunet.uu.net Subj: [1226] EMP (Electro-Magnetic-Pulse) Luggage scanning. On the Independent Network News, the other night, there was an interesting(?) article about luggage checking. Someone proposed checking all luggage by exposing it to a powerful Electro-Magnetic pulse. The theory is that you run all luggage through a building, and inside the building, suitably shielded regarding both electrical and blast effects, you, well, apply an Electro-Magnetic pulse to the luggage that is strong enough to set off any explosive (as well as ammunition and so forth) concealed in the luggage. The implication was that the explosive didn't have to be hooked to a detonator. They had some academic type who was proposing this on, and interviewed him. No one asked the question which was obvious to me: What does this do to every piece of electronic gear which is misfortunate to be in its path? My first guess is that a pulse which is strong enough to set off explosive (there was reference to powerful Navy radar setting off shells in the TV article) will also burn out every piece of electronic gear from digital watches to calculators and, of course, our favorite computers. It would probably also erase floppy disks. -- Nick Simicich --- uunet!bywater!scifi!njs --- njs@ibm.com (Internet) From: annala@neuro.usc.edu (A J Annala) 12-Jan-1989 0:20:40 To: misc-security@ucbvax.berkeley.edu Subj: [586] Re: Locksmith Licensing >for example California has a licensing requirement. To obtain this license >one is required to submit their fingerprints a form to the state. The state >runs a simple background check to make sure you are not a "criminal." I am a little curioys about this message ... the president of the california locksmithing association told me a few months ago that locksmiths were now required by california law to hold a valid california contractor's license ... failure to obtain such a license could subject one to arrest for simple possession of locksmithing (read burglars) tools. AJ From: hsc@mtund.att.com (Harvey Cohen) 12-Jan-1989 0:36:45 To: misc-security@att.att.com Subj: [1089] Re: From risks-forum: Mitnick I don't have a copy of the original article, but I think the version posted here (misc.security) has been edited to remove all references to inside accomplices, physical break-ins, and other means by which Mitnick gained initial access to systems. The remaining text is misleading, I think, in implying that Mitnick somehow started only with public-domain information and used only skill to breach security. This is all too common in publicity about computer security breaches. The notion that sensitive computer systems are somehow accessible to any hacker by skill alone is romantic and newsworthy, so the fact that access really depended on getting phone numbers or passwords from an inside accomplice or by physical breakin is downplayed or even ignored. The techniques of Mitnick and others like him resemble in many respects the techniques of the professional magician, and the press plays along by emphasizing the "magic." -- Harvey S. Cohen, AT&T Bell Labs, Lincroft, NJ, mtund!hsc, (201)576-3302 [Moderator note: Well, *I* didn't edit it down -- it came that way.. _H*] From: ncc!myrias!dbf@pyramid.com (David Ferrier) 12-Jan-1989 1:01:58 To: mnetor!alberta!misc-security@uunet.uu.net Subj: [4479] Re: Password Aging >Password aging minimizes the amount of time that your password is open >to attack. You may have a well-chosen password, but the longer it is >used, the more likely it is that someone has [obtained it]... This sounds good, but no matter how they try to justify or explain it, password aging is one of those things that system administrators do that look really good to system administrators, auditors, and security consultants, but in practice does not give enough benefit to justify the tremendous inconvenience and loss of time caused to users and the organization. Security measures are put in place to prevent losses. If the cost over time of a security measure exceeds the probability of loss over time times the value of the assets, use of the security measure is bad management. Password aging is an example of a security measure, which, except for the CIA or other exceptional organizations, usually costs more to implement than the value of the assets protected. What does password aging buy you? -------------------------------- - it helps reduce risk by preventing access to the system and data by unauthorized users. Examination of past security incidents invariably shows that almost all damage done to systems or data was done by authorized users with passwords, not by the spooks that password aging is supposed to defend against. What are the risks of access by unauthorized users? ------------------------------------------------ - theft of machine cycles, unauthorized access to data, unauthorized modification or destruction of data. In most systems, the wastage of machine cycles by authorized users who are inexperienced or inefficient, or read dozens of USENET articles every day, far exceeds the possible cost of system use arising out of unauthorized access. As for data: signon passwords are only the first line of defense. Depending on the system, a user often has limited access to data. Unless unprotected data are not backed up, contain vital trade secrets, or there is no audit trail log generated of modifications to critical data, access by an unauthorized user is be much of a problem--not enough, anyway, to justify the cost of password aging. What is the objective improvement to security given by password aging? -------------- - who knows? How can you measure the likelyhood of a password being compromised when it is not changed regularly? A similar study might be done on people with wall safes who do not change the combination on a regular basis. What is the cost of password aging? ---------------------------------- - administrative: staffing a responsive corporate security department who can give out new passwords to users who tend to forget theirs when they have to change them regularly - user: need to build into project schedules enough slack to allow for loss of productivity due to being unable to access the system because a password has expired - organizational: replacing people who get fed up with the security run-around and leave Anything constructive to say about password aging? -------------------------------------------------- The following concepts came from working with a password aging system used by a Toronto computer utility that prevented reuse of any password for 20 cycles. Worse, it even prohibited use of near matches--"moon" and "fool" for example. Users had to keep a list of old passwords, because as a final diabolical twist, the system only gave you five tries to assign a valid new password when the old one expired, at which point use of your id was suspended. - If you must have password aging, keep it within reasonable bounds. As with any other corporate program, force the people proposing it to do a cost justification, and make a business case if they can for forcing people all over the company do regular password changes. - Make sure it is an option that you can control on an individual or departmental basis, so that only people with high risk data or extensive access rights are put to the inconvenience of changing passwords frequently, or at all. This control should extend to the number of generations of old passwords that are kept on file to ensure the new password does not replicate a previous password. -- David Ferrier Edmonton, Alberta alberta!myrias!dbf (403) 428 1616 [Moderator note: It looks like the upshot of this discussion is that aging isn't really much help... _H*] From: Michael DeCorte 14-Jan-1989 19:25:21 To: misc-security@rutgers.edu Subj: [1031] Re: Virus-writing >It also seems that few unversities or other institutions of higher education >admit to viruses being a major problem. I don't know of any courses offered >in the subject of computer security and virus detection. Are there any at >your school? No, it would be overreacting to the problem. Every student here at Clarkson get a Z-200 (AT clone). Every one gets a Unix account. Noone as reported a case of the flu among these 4-thosand AT's. Now we were lucky that we didn't get hit my the RTM worm so I suppose you could say he have been hit 1/2 a time. So what am I trying to say here? Let's just be rational about this and not over react. The panic over viruses seems very similar to the panic poisons being put into food (read: tylenol). Everyone was worried that it would distroy our entire food distribution network. When was the last time you heard anything about it? -- Michael DeCorte // (315)265-2439 // P.O. Box 652, Potsdam, NY 13676 Internet: mrd@sun.soe.clarkson.edu // Bitnet: mrd@clutx.bitnet From: ole!powell@teltone.com (Gary Powell) 14-Jan-1989 19:38:48 To: security@pyrite.rutgers.edu Subj: [940] Cellular Phones In case you think no one would go to the trouble of listening to your conversation, the local paper (Seattle Times) has run a couple of articles on the folks who listen in, and what is said. Apparently the best conversations involve couples who fight, lie etc. ("Honey, I'm going to be late from work, Oh Yeah?, Yes I'm at ______'s bar."....) I have yet to see any articles on prossecution of listeners. Will digitizing the signal allow for more traffic? I have heard that L.A. is in trouble with all the cellular phone use, and that the lines fill up. My understanding is that with a "cordless" phone no warrant is required for a "tap". Does anyone know if that applies to cellular phones? (I have seen articles where the neighbors inadvertently picked up converstations about drug deals, informed the police who then made recordings.) -- Gary Powell UUCP!uw-beaver!tikal!ole!powell Seattle Silicon Corp. (206) 828-4422 From: Don Hopkins 14-Jan-1989 20:15:17 To: V4039@TEMPLEVM.BITNET Subj: [4475] Just say no to government software certification Cc: security@pyrite.rutgers.edu A question of relevance to this discussion is along the following lines. Is it not the ethical responsibility of our government to establish laws and guidelines which software must pass before being distributed? NO WAY! I think it's a BAD idea for the government to regulate software distribution in an attempt to prevent viruses. I think the proposed prevention is worse than the cure. How can government regulation do anything to prevent computer viruses without being oppressive, costly, and ineffective? It'll always be up to programmers, users, and system administrators to take the appropriate precautions (like archiving source code, and making regular backups), to minimize the loss of time and data if and when the occasional virus happens along. How can the government make virus prevention the software distributer's responsibility, by regulating software production? There should be some sort of committee made up of individuals from government and private industry who are responsible for certifying software. For gosh sakes, even floppy disks must under some sort of certification! First off, there's no way a person or committee can certify a piece of software virus free, with 100% certainty. The function of a computer virus is totally open-ended. There are too many ways in which one could operate. Computer programs can be extremely complicated, undocumented, and obfuscated, and the environment in which they run has to be considered as well. It's extremely silly to compare floppy disk certification with software certification! Software certification is *NOT* something that can be automated, like trivially checking a floppy disk for bad sectors. How many people do you know who could have looked at the source code to the 4.3BSD finger daemon and realized that it could be used to get a shell, because it was doing a gets() into a local string variable? Would you stake your career on somebody else's program being virus-free? Besides being impossible, software certification would be unthinkably costly in terms of time and money. Even partially certain certification is a tedious, intensive process that requires a great deal of time and understanding and the attention of an experienced programmer. How much do you think you'd have to pay a committee of expert programmers to grovel over other peoples code looking for hidden traps? Don't you think people with such skills have better things to do with their valuable time? How long do you think it would take for a committee to certify one single program virus free (even just partially certain)? Does it have to be well documented? Or even bug free (ha ha!)? Can a program be too big to certify? How many programs would need to be certified each year? How long would the waiting list be? How would the list be prioritized? Think of all the nasty legal ramifications -- trade secrets, nondisclosure agreements, conflict of interest, etc... And think of the potential for corruption, discrimination, censorship, and other abuses. All that red tape would add an indefinitely large amount of time to how long it would take to get a product to the market. It would annihilate the software industry! Companies struggle to get their products on the market as fast as they can. The bureaucratic delay would be fatal to small companies that depend on the income from their products to survive. Do you have any idea of the size of the software industry???! Flip through a copy of Computer Shopper some time! How many virus verification committees would there have to be to screen all the new software products on the market? They'd have to hire up half the competent programmers in the world just to be on committees, at salaries competitive with the ones offered by software companies that are already having a hard enough time finding people to hire. Just think about how much the overhead of "virus-free" certification would add to the price of software! Somebody's got to pay for it! Of course it would all be passed on to the users in the end. If software publishers had to pay for certification, then only companies the size of Microsoft would be able to afford all the salaries, legal fees, payoffs, and bribes that it would take to get a product to market before the hardware it ran on was obsolete. So should the government pay for it? Would you propose a software virus certification tax? (sheez, and I thought Stallman was radical! ;-) -Don From: dplatt@coherent.com (Dave Platt) 14-Jan-1989 20:23:47 To: misc-security@ames.arc.nasa.gov Subj: [9695] Re: Virus-writing < Since there is no regulartory agency whose job it is < to certify software and it's potential for harboring viruses and < legitimate bugs, proprietary software becomes just as easy to infect at < the publishing house as any of your own disks. Hmmm. This flies in the face of my own (limited) direct experience with viruses in the Mac world, and with what I've heard from other Mac users. In the Mac world, I know of only one instance in which a virus was propagated through a commercial/skrink-wrap package... this was the case in which a copy of Brandow's "macMag World peace" INIT virus infected a copy of the master distribution disk for Aldus FreeHand, and was shipped to customers. On the other hand, there are _many_ cases in which the nVIR and SCORES viruses have travelled around via public domain software, shareware, and via copies of commercial applications that people were carrying around on diskette for their own convenience. I received two shareware games from a friend, and (before running them) found that they were infected by SCORES. Last week, the brother of one of our employees dropped by to use one of our Macs to print a Microsoft Word document on our laserprinter; his copy of MS Word (on his diskette) was infected by the nVIR virus, and we almost suffered an invasion of our Macs' hard disks. Fortunately, all of our Macs are running with Vaccine, which stopped the infection. Stan writes that "there is no regulatory agency whose job it is to certify software ... proprietary software becomes just as easy to infect at the publishing house as any of your own disks." The first part of this statement is true, but I really don't agree that the conclusion follows, for a number of reasons: 1) Most people buy a relatively small number of commercial programs (say, a dozen or two), but tend to trade data and program (shareware, PD, etc.) diskettes with other users fairly frequently. Commercial programs tend to be installed on a hard-disk relatively soon after purchase, while shareware/PD diskettes float back and forth between machines quite a bit. 2) Commercial program disks usually go through a single "choke-point"; a master disk is created for a specific version of the program, and then copies are made from the master (through one or more generations of copying). Thus, if the master disk is checked for virus infections and found to be virus-free, the copies made from the master will also be virus-free. It's certainly possible for a single infected master-disk to cause many users' machines to become infected... but it's equally easy to ensure that the master is uninfected. 3) Stan's statement implies very strongly that it's necessary to certify a program (through some sort of regulatory agency) in order to ensure that it's virus-free (and/or bug-free). This is flat-out WRONG! Virus-detecting programs are available both commercially and for free; I have a suite of about a dozen antivirals for the Mac, which I use fairly regularly. I'm about as certain as I can be that my Mac library is virus-free. I trust the antivirals I have in-hand (and their authors, and the knowledgeable people on the Net) far more than I would trust an anonymous regulatory agency. 4) I'm curious about Stan's reference to "legitimate bugs". Are we going to assert that some regulatory agency will be competent to detect all (or most) bugs? or that such an agency should have the ability to forbid shipment of buggy software? Good luck, in both cases! My personal belief is that we do NOT need yet another regulatory agency to look at commercial software prior to sale and ensure that it's virus-free. For one thing, this agency would be unable to keep up with the changing and evolving nature of computer viruses... their tests would almost certainly be out-of-date and obsolete by the time that they were approved and put into general use. For another, the volume of programs that this agency would need to handle would be utterly incredible, and they'd almost certainly have a really serious backlog. Would _you_ want to have to wait 6 months to ship a new release of your software (or even a bug-fix that your customers were screaming for) because the certification agency was overbooked? To make matters worse, the presence of such an agency would do _nothing_ to keep viruses from spreading over noncommercial channels... via public-domain software exchanges, bulletin-board systems, or diskettes passed from hand to hand. Based on my experiences with viruses, and what I've heard from other people, virus distribution via commercial shrink-wrap products is only a very small portion of the problem. What I believe that we _do_ need is better education about viruses, more care and vigilance on the part of users and software distributors, and continued dissemination of good anti-virus software tools. I've been extremely impressed by the willingness of good software authors to write and hand out anti-viral utilities... mostly with no expectation of any financial return. These utilities (e.g. Vaccine, Interferon, AntiPan, etc.) have saved my bacon at least twice! By analogy: it's rarely been possible to make a dent in the incidence of sexually-transmitted diseases by making it more difficult to have sex, or by insisting that people be tested for infection prior to having sex. Education and honest information, on the other hand, has led people to change their behaviors and to avoid high-risk actions; as a result, the incidence of STDs tends to drop in well-educated populations. Nobody _wants_ to get an STD; if you teach people how to avoid exposure to disease, they'll usually do so. Similarly, nobody wants to have their computer infected by a virus; if you teach them what behaviors to avoid (e.g. indiscriminate swapping of diskettes with other folks; use of pirated software) and what behaviors to practice (running good antiviral programs), they'll usually do so. > Are there any [virus courses] at your school? I haven't heard of any such courses to date. There has been quite a bit of discussion (in comp.risks, for example) on the subject of teaching students about the ethics of computer use... for example, why it's a really bad idea to write viruses (even if it seems like a "neat idea"). I suspect that the current wave of viruses is a recent enough phenomenon that most colleges/universities haven't yet had the time to really consider what impact it should have on their curriculum, and that we will see some courses addressing this whole area start to pop up within the next year or two. System-administration people at quite a few universities have mentioned (in comp.sys.mac, for example) that they've been having serious problems with viruses spreading through their student-use computer populations. Some of these people (e.g. John Norstad at Northwestern University) have been leaders in the fight to analyze and protect against these viruses. < For gosh sakes, even floppy disks must under some sort of certification! < It's kind of silly to certify the integrety of floppy disks when we are < allowed to purchase disks with software that might very well have a < virus due to the lack of regulations and standards in this area. Wellll... there's at least one misunderstanding/misstatement-of-fact in the above paragraph. Although there is an ANSI standard for the testing of diskettes, there is no requirement (as far as I know) that diskettes be tested and certified according to this standard before being sold. The standard exists for a good reason... so that there is an agreed-upon indicator of diskette quality, that can be referred to by diskette manufacturers and by the diskette-purchasing public. I certainly wouldn't purchase diskettes from a vendor that didn't test and certify its product to the ANSI standard... but I know of no reason why such diskettes couldn't/shouldn't be marketed. If people refuse to buy uncertified diskettes, then eventually most or all vendors will test and certify their diskettes to the currently-agreed-upon standard. It's important to note, however, that the fact that a standard exists, and the fact that vendors claim that "our diskettes are certified to the ANSI standard", does _not_ mean that the diskettes are necessarily of good quality or will provide reliable service. I recently received a copy of a very interesting technical report on 3.5" diskettes. The report indicated (with statistics to back up their statements) that there's a great deal of quality variation between vendors, and that many disks that are sold as "100% certified to ANSI standards" are actually of mediocre quality and appear to fail the ANSI certification when purchased and tested. It may very well be that some manufacturers are lying... they may be shipping disks that don't meet ANSI standards, and saying that the disks are certified. THIS is something that should really be dealt with, at some level... perhaps ANSI should consider filing a cease&desist order against companies whose products are clearly substandard but which are being sold as having met the standard. I _really_ question the assumption that the solution to every problem is to set up a new regulatory agency, and to funnel the output of a whole industry through the agency's hands. -- Dave Platt FIDONET: Dave Platt on 1:204/444 VOICE: (415) 493-8805 UUCP: ...!{ames,sun,uunet}!coherent!dplatt DOMAIN: dplatt@coherent.com INTERNET: coherent!dplatt@ames.arpa, ...@sun.com, ...@uunet.uu.net USNAIL: Coherent Thought Inc. 3350 West Bayshore #205 Palo Alto CA 94303 From: jbrown@jato.jpl.nasa.gov (Jordan Brown) 16-Jan-1989 3:17:48 To: misc-security@ames.arc.nasa.gov Subj: [2146] Re: Virus-writing >it not the ethical responsibility of our government to establish laws >and guidelines which software must pass before being distributed? No. Impractical. Caveat Emptor. > We have laws regulating production of auto's and other consumer products No we don't. *Some* consumer products are subject to forcible recall, but there is no certification. >For gosh sakes, even floppy disks must under some sort of certification! Voluntary, and self-administered. There are ANSI standards for floppies, sure. Government doesn't enforce them, market does. I hesitate to even respond to this kind of thing. Who's going to do this testing? The government? Using whose money? The producer? Who's going to watch to make sure he does it, and does it "right"? How do you *exhaustively* test a complex piece of software? Software is more complex than *any* consumer product, up to and including small jets. (Excepting, of course, the software used by the avionics.) For an airplane, you can say "Must stand without deformation loads of 3 Gs at max weight" and "Must recover hands-off from a spin of less than one turn" and other absolute things. Can't do that for non-trivial software. (Of course, any good software producer will do some amount of testing. However, in a scenario like you propose, you must codify how much testing is to be done, and what the acceptance criteria are.) The real answer is rational application of existing liability laws, combined with market forces. If Ford makes a car that tends to blow up when rear-ended, people sue them and win. If a dairy sells bad milk, people sue them and win. If Chevy makes a car that breaks all the time, people stop buying Chevys. Do you really want the computer business (this really applies to hardware as well as software) to be like the drug business, where worthwhile products are simply discarded because the expense to certify them exceeds the possible revenue, and where things regularly take ten YEARS to come to market? Sure, this kind of care is necessary for life-critical applications, and they get it. For business apps? Maybe. For games? Are you kidding? From: lypowy@cpsc.ucalgary.ca (grep) 16-Jan-1989 4:11:17 To: security@rutgers.edu Subj: [2778] Re: Virus-writing Here at the University of Calgary there are no specific courses on Computer Security per se, however the Department does have a reading course at the undergraduate level (CPSC599.nn) that can handle any topic. I myself became interested in Computer Security only recently, and upon finding no courses in this area approached a member of the faculty with my dilemma. He gave me the information on CPSC599, and this last semester we studied viruses and other forms of 'Malicious Logic'. The very idea of teaching a course on this topic is a contentious one, the like of which, I am sure, we have all seen kicked around in one form or another in other newsgroups/on other systems. > Is it not the ethical responsibility of our government to establish laws > and guidelines which software must pass before being distributed? Ethics are always a problem. Ethically, perhaps it is, however the delays right now on the release of a piece of software are sometimes unbearable. Can you imagine the latency when each piece of software must be federally approved? Also, there is the argument that in enforcing such guidelines we might be limiting the sophistication of the software itself. > same should be true of software. There should be some sort of committee made > up of individuals from government and private industry who are responsible > for certifying software. For gosh sakes, even floppy disks must ... Keep in mind that the auto industry has had a number of years of production to call upon for their experience; their problems have been monitored and treated over a much longer period than what we are dealing with here. The widespread problem of Computer Viruses et al is fairly recent. > It's kind of silly to certify the integrety of floppy disks > when we are allowed to purchase disks with software that might very well have > a virus due to the lack of regulations and standards in this area. This is somewhat confused. Your point is valid, but the example is perhaps not the best. It IS important to certify floppy disks (the physical media) to maintain some sort of quality control; they do not certify what goes onto the disk (be it programs or data). You always take a chance with the software you buy - sometimes the risks are minor ("Will this program be as useful to me as the salesperson claimed it would be?"), sometimes major ("Is this program clean or has it been infected by some sort of Virus?"). There are a number of good points in your message, Stan! Many of the areas that you address may be in their embryonic stages as we speak. Greg Lypowy University of Calgary Computer Science Department 2500 University Drive N.W. lypowy@cpsc.UCalgary.CA Calgary, Alberta, T2N 1N4 ...!{ubc-vision,ihnp4}!alberta!calgary!lypowy From: tat@pccuts.pcc.amdahl.com (Tom Thackrey) 17-Jan-1989 11:14:28 To: misc-security@ames.arc.nasa.gov Subj: [1042] Re: Virus-writing >it not the ethical responsibility of our government to establish laws and >guidelines which software must pass before being distributed? On the contrary, it is the ethical and moral responsibility of good government to avoid censorship and encourage creativity. A highly regulated software industry would be just like the auto industry a very small number of very large corporations producing very uninteresting software that all looks alike. The assumption that government regulation can protect against bugs, time bombs, infections, poor documention or user carelessness is naive. Remember the Corvair, Pinto, DC-10, Electra, Tacoma Narrows bridge, Kansas City Holiday Inn, Titanic, Love Canal, Lawn Darts, and Challenger were all products of regulated industry. An independent testing organization along the lines of Consumer Reports might be useful. Publicity will probably be the most effective tool to kill off bad or poorly designed products. -- Tom Thackrey sun!amdahl!tat00 [ The opinions expressed herin are mine alone. ] From: gwyn@smoke.brl.mil (Doug Gwyn ) 17-Jan-1989 11:31:47 To: misc-security@uunet.uu.net Subj: [1272] Re: A response >I have personnaly arrested and convicted on posession of a baseball bat, >but rest assured that my defendant was not on the ball field. You could get away with that through the vagueness of the definition of "deadly weapon" (a proper interpretation of which must take intent or actual use into account; every kitchen contains potentially "deadly weapons"). But if the law said that possession of a baseball bat was a felony (and some laws are almost that stupid), then you would have to engage in "selective enforcement", which is fine when the officer exhibits good judgement, but many people now don't want to have to rely on that. (Too many cases of poor judgement have been reported.) My point is that a law should specify accurately what the intended effect is, rather than to address this indirectly by trying to manipulate possible causes. Indirect restrictions invariably also interfere with perfectly legitimate actions by non-criminals, and that is not usually logically necessary in order to fight actual crimes. To get back to the topic of computer security, laws and regulations that do not DIRECTLY address criminal actions involving computers will very likely hamper the application of computing power to meet human needs. That would be very sad .. From: gwyn@smoke.brl.mil (Doug Gwyn ) 18-Jan-1989 3:17:46 To: misc-security@uunet.uu.net Subj: [982] Re: Virus-writing >Is it not the ethical responsibility of our government to establish laws and >guidelines which software must pass before being distributed? Not in any country that considers the freedom of its citizens to be a virtue. I leave it to you to decide if that applies to the USA today. >For gosh sakes, even floppy disks must under some sort of certification! No, they don't HAVE to undergo "certification" (which is actually just MEDIA VERIFICATION performed by the manufacturer). However, quality assurance is quite important for manufacturers who plan to remain in business for a long time, and in fact most long-term successful manufacturers do realize this and have established quality assurance programs. Seldom does this involve the government; it's just good business. >... due to the lack of regulations and standards in this area. Government regulations seldom help ANYthing, and usually exacerbate the very problems they were intended to solve; haven't you noticed?? From: Barry Margolin 18-Jan-1989 3:47:37 To: security@pyrite.rutgers.edu Subj: [443] Re: Virus-writing Stan Horwitz asks about the possibilty of regulations against computer viruses. A bill was introduced this fall in Congress to make computer viruses and worms illegal. I recently saw the entire text posted to a Usenet newsgroup, but I don't remember which. Of course, the federal bill only covers viruses transmitted in interstate commerce, but it seems likely that states would follow suit. barmar From: ki4pv!tanner@bikini.cis.ufl.edu 18-Jan-1989 3:54:05 To: security@pyrite.rutgers.edu Subj: [2442] Re: Re: Virus-writing ) Is it not the ethical responsibility of our government to establish ) laws and guidelines which software must pass before being distributed? No. The legitimate functions of government are two: (a) provide for common defense against external powers, and (b) enforcement of contracts. If two parties wish to exchange money for any sort of buggy software (and most software is buggy), that is their business. All the government can do is assure that said buggy software is delivered as promised. ) I know that the government has guidelines for itself about the ) integrity of software for it's internal systems. Right. Any two parties can, if they wish, negotiate any sort of contract they desire. If they wish to agree that the software should be warranted free of bugs for a period, or that it should be of such a coding style, they are certainly free to do so. If the government is one of the parties to a contract, they may arrange such terms as please them. ) We have laws regulating production of auto's and other consume ) products and services. The same should be true of software. Simply asserting that there should be such regulation, in the absence of convincing argument (perhaps sent under separate cover) is not sufficient. Demonstrate that there should be regulation of software. ) For gosh sakes, even floppy disks must under some sort of ) certification! Floppy disks are regulated only by private industry. If a manufacturer wishes to call his disks "certified", he is free to. If he wishes to go farther and actually certify something, then you can check and see if his claim is true. Further: it is much easier to check floppy disks for bad spots of such a size or larger than it is to check a piece of software (given as object only) to be sure that it is entirely free of bugs and anti-social behaviour (virii, worms). If you are concerned about the quality of software you are purchasing, then wishing for government regulation is the wrong way to deal with your problem. The government will simply assist in restricting the supply, causing a price increase. Instead of hoping for the government to solve your problems, you should negotiate a contract somewhat more reasonable than those "shrink-wrap" licenses you find in so many packages. You may also be well served to insist on a source distribution; this latter is my personal advice. Dr. T. Andrews, Systems CompuData, Inc. DeLand From: J.D. Abolins 18-Jan-1989 4:26:45 To: SECURITY@pyrite.rutgers.edu Subj: [3205] Computer viruses / Shareware / Laws re: software standards Although I don't have stastics to compare virus cases between those vectored by commercial/shrink-wrapped software and those vectored by shareware/public-domain software, shareware often gets pinned with the blame for spreading viruses. Sometimes, various writers have panned any software that doesn't come in a shrink-wrapped package and with a hefty three-digit price as "leper software". Taking a closer look shows that the issue is not as clear cut as these critics claim. 1) The term "Shareware" does not describe the quality of the software. Rather, it describes the mode of distribution. That's all. (I guess some critics sucumb to the notion, "If it's good, it has to be expensive." and its inverse.) 2) Commercial/Shrink-wrapped software is distributed via a short chain to the user. Author-> Manufacturer-> Distributor -> Retailer -> User. If Shareware is obtained via a short chain, as in the case of buying it directly from the author or from a commercial distributor, the risks are almost equal to that of the commercial/shrink-wrapped software. (The main factor that increase the risk slightly is that many shareware software writers don't use or have isolated computer systems dedicated for their programming only.) 3) While the number of REPORTED incidents of viruses carried by commercial/shrink-wrapped software is very low (to solid cases anda couple of alleged ones), the number of people and systems affected by the known cases are large. In the case of viruses vectored by shareware, I have yet to hear of one originating with the author's system. Instead, the viruses are introduced further down the chain of distribution (in a user's group, on a BBS, etc.) and the spread is spotty rather than massive as in the case of the commercial/shrink-wrapped software. Stan Horowitz asked if laws can be enacted to set standards for software so that viruses could be prohibited. A good question. Here are some factors from a non-lawyer otherwise informed about computer laws... 1) Computer law is so new and complex that lawmakers are having a hardtime catching up. One challenge is to define the problem, the crime, the standards for determining guilt, and the appropriate action. This has to be done wisely, otherwise we can get laws that anybody who installs buggy software a criminal. 2) The issue of general software standards have been discussed elswhere on BITNET. (I think RISKS had mentioned it a couple of times.> Great Britain is considering such standards. Defining those standards into law is more difficult. In the case of "certified" diskettes, the hardware and other constrains have well defined the boundaries. It's very hard to find the boundaries with something as abstract as software. 3) Except for deliberate corporate "virus wars" as presented in a PC Magazine's colum's scenario, commerical software companies do not seek to put viruses on their products. The viruses get in by accident, by sabotage, etc. Here, liability and tort procedures apply. From: jef@helios.ee.lbl.gov (Jef Poskanzer) 19-Jan-1989 3:30:12 To: misc-security@ucbvax.berkeley.edu Subj: [1031] NO CARRIER This may already be common knowledge, but... Some terminal emulator programs have an amusing bug. When they see the text "NO CARRIER" at the beginning of a line, they stop listening to the modem. Like this: NO CARRIER If your emulator has this bug, you are no longer on line, and are not reading this. Yes, this sounds far-fetched, but I can personally assure you all that it's not just another chain-letter variation like the modem virus story. I discovered this on the WELL a while back when I opened a topic called "NO CARRIER", and then got mail from a user complaining that whenever he tried to read the topic his modem hung up. He was not computer-literate enough to have been making a joke. Recently another user reported the same problem. This represents a security risk of the denial-of-service type. Fortunately it's easy to fix -- just toss the buggy terminal program and get a better one. --- Jef Jef Poskanzer jef@rtsg.ee.lbl.gov ...well!pokey Burma Shave. From: hollombe@ttidca.tti.com (The Polymath) 19-Jan-1989 3:32:53 To: misc-security@sdcsvax.ucsd.edu Subj: [1214] Re: A response }1. Commission of a burglary _IS_ a crime. In fact, it's a Felony in }Pennsylvania, and it is defined as _any_ entry into a building with the }intent to commit a crime. This would mean any crime, from rape to theft to }criminal mischief. That's a statute with some teeth! Not as many or as sharp as you might think. It can be difficult to prove _intent_. Even if you catch the criminal red handed, in the act of committing a crime, you still have to prove they _intended_ to commit the crime _when they entered the building_ to make burglary stick. (Of course, they're still guilty of the crime you caught them in the midst of). "Honest, Judge, I just ducked in to get out of the rain. Then I saw all that stuff lying there and decided, 'What the heck ...'". Theft? Yes. Burglary? Try and prove it. (Granted, possession of burglar's tools would certainly be an indicator of intent and probably be considered sufficient proof of same). -- The Polymath (aka: Jerry Hollombe, hollombe@ttidca.tti.com) Illegitimati Nil Citicorp(+)TTI Carborundum 3100 Ocean Park Blvd. (213) 452-9191, x2483 Santa Monica, CA 90405 {csun|philabs|psivax}!ttidca!hollombe From: *Hobbit* 19-Jan-1989 3:38:29 To: security@pyrite.rutgers.edu Subj: [2112] Burglar tools Tom Mahoney points out [EMPHASIS mine] -- ... burglary ... is defined as _any_ entry into a building WITH THE INTENT to commit a crime. This would mean any crime, from rape to theft ... This seems to be how most statutes are laid out. Thus, if it can be proven that I entered a building to, for instance, shortcut through a block instead of having to walk around the end, and exited the building out another door, the most I've committed is trespassing. *Whether or not* I had my lockpicks in my pocket at the time. Correct? However: I do keep a homebuilt slimjim in my car [and in my office] and have on several occasions helped people bail themselves out of a lockout. I've never used same to enter a car unless someone authorized wanted me to do so. But how would I prove this to you if you simply encountered me and said slimjim returning to my car or office after rescuing someone's keys, and they've long since driven away? Would you arrest on the simple basis of this random hunk of metal in my hand? A good proportion of these "rescues" have taken place in the wee hours, since I and people I associate with are usually awake at those times anyway. At MIT and many other places, non-destructive entry for its own sake is a long-standing tradition among the students. The "hacker ethic" promulgated there is such that common thievery is shunned, although unfortunately there are always exceptions that keep the campus security people paranoid. The way the laws are written, it seems to me that simple *entry* isn't a crime unless some *other* crime was committed inside the entered premises. [Signing one's name on a concrete wall that nobody looks at is normally the most that happens on these building-hacking expeditions.] The real screw comes when a defendant claims to have entered purely for its own sake, and all too often it's left to subjective judgement by the authorities. Needless to say I don't cotton to this idea -- I love to explore buildings and such, but always have a hard time convincing other people it's harmless and creates no security risk. Comments? _H* From: "W. K. (Bill) Gorman" <34AEJ7D@CMUVM> 19-Jan-1989 4:25:20 To: SECURITY Digest Subj: [2980] Re: A response > I presume that you are using some sarcasm here... Absolutely none in this case... As a member of a law enforcement oriented family (father, brother) and with some security experience myself, there are one of two *more* points to be made here. >...and it is defined as _any_ entry into a building with the >intent to commit a crime. ... That's a statute with some teeth! And a Prosecutor's worst nightmare. Proving intent, or capacity therefor, is no easy task. >2. Posession of burglar tools is also a crime in this state. >... BTW the same logic applies to deadly weapons. Unless *specifically* defined by statute as a banned tool or device, applying this logic to everyday items can easily give rise to subjective interpretation, alias descretionary enforcement. The weapons example is a case in point (granting of licenses is a very subjective process in many areas), as can be drugs, alcohol, or almost anything else. Your dynamite reference offers proof of the converse: dynamite is federally regulated and those possessing it are either licensed to do so or they are in violation of federal, and probably state, statutes; a more clear cut and sharply defined situation than possession of something or other which may or may not be capable of use in an illegal manner by an individual who may or may not intend to use whatever-it-is illegally at a time and place which may or may not be suggestive of criminal activity depending or circumstances which may or may not be apparent to an officer who may or may not have training available to enable s/he to respond appropriately in the given circumstances. The point of all this is to enable an officer on the scene to make a good, solid arrest of someone who richly deserves it; an arrest that will stand up later in court, not one that may either be later shown to have been in error or worse, is thrown out of court and releases a criminal back into society. Don't bother sending me flames about this - my brother and I have both paid our dues. ******************************************************************************* * A CONFIDENTIAL COMMUNICATION FROM THE VIRTUAL DESK OF: * ******************************************************************************* ............................................................................... |W. K. "Bill" Gorman "Do Foust Hall # 5 | |PROFS System Administrator SOMETHING, Computer Services | |Central Michigan University even if it's Mt. Pleasant, MI 48858 | |34AEJ7D@CMUVM.BITNET wrong!" (517) 774-3183 | |_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_| |Disclaimer: These opinions are guaranteed against defects in materials and | |workmanship for a period not to exceed transmission time. | |.............................................................................| From: Chriz@cup.portal.com 20-Jan-1989 11:02:57 To: security-request@rutgers.edu Subj: [2089] value based fsa Consider the following value based finite state automaton: finite state name finite state action 00 My Father Sells Rubbers to Nato 01 My Mother Pokes holes with a pin 10 My Sister Performs the Abortions 11 My God, How the Money Rolls In! In each state the following value functions utilized by the empathizers of the young NATO soldier(and his girlfriends) are apparent: 00 Young soldier needs rubbers for sex so NATO supplies them 01 Young soldier trusts NATO 10 Girlfriend doesn't love Young Soldier 11 Young soldier must pay Now according to Hopcroft and Ullman (Introduction to Automata Theory, Languages, and Computation) a finite automaton is "a finite set of states and a set of transitions from state to state that occur on input symbols chosen from an alphabet _sigma_."[p.16] Hopcroft and Ullman utilize finite states in purely symbolic terms, citing that the set of transtions occur on input symbols. It is possible, in examples such as the above, that the symbols could be incentives to make a certain value judgment, and that the states could be a value-based or value-motivated action. >From this the idea of a perpetual strategy of manipulation, in which those people whose values are identical with those of the FSA are manipulated and molded to produce a desired result,ad infinitum. Notice that the system set up by the empathizer with the young soldier does not even depend on fooling the young soldier. All he sees is that his girlfriend somehow go pregnant, and he has to pay for an abortion. The finite state automaton does not depend on PT Barnum style deception, and it does not depend on the gullibility of the victim. In fact, even if the young soldier felt it was odd, he would still be forced to abort. Only an extensive investigation would reveal the entire scheme. This is the way to manipulate and the way to victory. From: zeeff@b_tech.ann_arbor.mi.us (Jon Zeeff) 21-Jan-1989 18:59:22 To: misc-security@uunet.uu.net Subj: [625] file change program wanted I'm looking for a program that will take and store crc and permission values for all the files on a file system and then at some future date, produce a report indicating what files have changed. Something like: /etc/inittab has changed date and crc value /xx has been removed /zz has been added /ff has changed crc value but not date /bin/su has changed permissions /gg has changed ownership Such a program would have obvious uses for security and file system corruption checks. -- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us Support ISO 8859/1 zeeff%b-tech.uucp@umix.cc.umich.edu Ann Arbor, MI umix!b-tech!zeeff From: mrc@blake.acs.washington.edu (Mark Crispin) 21-Jan-1989 19:19:19 To: misc-security@husc6.harvard.edu Subj: [1940] Re: Additional security to login Passwords do not belong in *any* file in the filesystem. Any file in the filesystem can be compromised by careless protections (or secret access left by someone who temporarily got into root). There are only two entities which have any business reading passwords; the system backup utility and the system agent which validates a password. All other entities which wish to validate passwords should do so via requests to the system password validation agent (that is, login, FTP server, etc. should never have access to passwords). Three operating systems which I am familiar with stored the password as part of out-of-band information in the user's primary directory. In one OS, the programs which validated passwords were privileged (equivalent to being setuid'd to root) and a user invoking those programs received the appropriate privileges for the duration of that program's execution. In the other two, all operations involving passwords were implemented as system calls inside the operating system. The programs executing those system calls had no special privileges; they were simply user interfaces. Any user could write a useful program using those calls, although (for other reasons) there were restrictions on writing programs which run un-logged-in. Although the equivalent of root could read passwords, the passwords were encrypted, by a much simpler algorithm than Unix (in fact, in earlier versions the passwords were stored as plaintext!). The difference was that it was much harder to get at the passwords in any form. Security-conscious sites could configure their system so that password reads could only be done by a process on a trusted terminal (e.g. the console) -- and privileged logins and/or privileged access could similarly be restricted. None of these measures, by themselves, make much of an improvement in security; but collectively it does make a difference! -- Mark -- From: nevin1@ihlpb.att.com 21-Jan-1989 19:39:19 To: security@pyrite.rutgers.edu Subj: [2419] Re: Virus-writing >I don't know of any courses offered ... Are there any at your school? There were none at my university. The problem is some people feel that their systems will be compromised by the 'wrong' people knowing about computer security; they would rather keep people in the dark and hope that no one discovers a way to break into computer systems. It boils down to "is this knowledge dangerous?" In the short term, perhaps; in the long term, however, knowing what the security problems are is the only way to combat them. >We have laws regulating production of auto's and other consume products >and services. The same should be true of software. Are we willing to pay the price for this 'protection'? First off, how does one really go about verifying software? Programs that output programs, such as compilers, all have to gain trust (see Ken Thompson's "Reflections on Trusting Trust", CACM Turing Award Lecture, 8/84). Who is willing to wait the months, or even years, that it would take to verify a compiler? Who would pay for this verification? Small software houses could not afford to have their software verified; should they just go out of business? Are we also willing to wait for our bug fixes/virus vaccines? Since these are also programs, they too must undergo the verification process. Are we also willing to pay for liability insurance for the software industry, in much the same way we pay for liability insurance for the pharmaceutical and medical industries? (Note: this may become an issue even without government regulation.) The price of software would go up exponentially; all but the biggest companies would start writing software for 'internal' use only (reinventing the wheel a thousand times over), and the growth in the software field would finally peak out. >There should be some sort of committee made >up of individuals from government and private industry who are responsible for >certifying software. I would rather see something like an Underwriters Laboratories for software, where one can get certification if one desires. This would alleviate some of the problems associated with government regulation, and we can see if certification really makes a difference to the market. You don't get regulations and standards for nothing. It is a heavy price to pay; is it really worth it? ___ NEVIN ":-)" LIBER AT&T Bell Laboratories nevin1@ihlpb.ATT.COM (312) 979-4751 From: koreth@ssyx.ucsc.edu (Steven Grimm) 22-Jan-1989 11:39:21 To: misc-security@ames.arc.nasa.gov Subj: [1071] Re: Zero knowledge passwords? Well, here at UCSC, we have something called a ".secret file". This is a file called ".secret" in your home directory, which is printed instead of the standard "Password:" prompt. When users first log in, they are instructed to enter a word or phrase meaningful to them (not their password), which is placed in the .secret file. With .secret files, fake login programs are easy to detect, because unless the program is running as root (in which case it would have access to all the accounts on the system anyway), it won't be able to read and print the proper .secret file. If there's sufficient interest, I can dig up the changes I made to SunOS /usr/bin/login, which should apply almost exactly to other login sources. (I can't take credit for the idea, even though I implemented it on one of our machines; I believe Jim Haynes, haynes@ucscc.ucsc.edu, came up with this scheme.) --- These are my opinions, which you can probably ignore if you want to. Steven Grimm Moderator, comp.{sources,binaries}.atari.st koreth@ssyx.ucsc.edu uunet!ucbvax!ucscc!ssyx!koreth From: Pete Nielsen 22-Jan-1989 19:19:23 To: SECURITY@UBVM.BITNET Subj: [703] Re: Zero knowledge passwords? One way of bi-dirrectional validation is to exchange authentication strings, rather than send the password. The way this works is that at logon, the workstation sends a string-to-be-encrypted along with the userid. The session access control, encrypts that string with it's copy of the users password, and returns it, along with a new string-to- be-encrypted. The workstation, receiving the first string, de-crypts it with it's copy of the users password, if there is no match, you're talking to a trojan, If there is a match, the workstation, encrypts the access control programs string, and returns that. The password never flows over the net. And both parties to the conversation are validated. From: smb@ulysses.homer.nj.att.com (Steven M. Bellovin) 22-Jan-1989 19:39:23 To: clyde!misc-security Subj: [1395] Re: Zero knowledge passwords? > Are there any systems out there that implement some way of verifying > that the program that you (the prospective user) are talking to is > really the login program? Any system rated B2 or higher by DoD has such a concept. It's called the ``trusted path'' or some such. Briefly, the user *never* sees a login prompt presented by the system. In order to receive one, the user must take some action guaranteed to reach the real ``trusted computer base''; this is the only way to receive a login prompt. Many B1 systems have similar concepts, though they aren't required to. Systems rated B3 or higher use trusted path for other operations as well, such as changing passwords. > Anyone got any good ideas on how to do this? There are a variety of techniques. Some systems use a ``secure attention key'' -- some key sequence (two breaks within a couple of seconds, for example) or other action to get the TCB's attention. There were several papers at the June '88 Usenix on similar topics; you may want to look them up. Particularly near and dear to my heart is (of course) my paper on the ``Session Manager''; it solves several other problems as well. There's currently a discussion on comp.unix.wizards on the same topic; I posted a brief description of my session manager to that group, so I'll forbear to repeat myself. --Steve Bellovin att!ulysses!smb smb@ulysses.att.com From: flynn@cos.com (Susan F. Symington) 22-Jan-1989 19:59:23 To: security@pyrite.rutgers.edu Subj: [1487] How to write an authenticatable login program One way to write a login program that is verifiable would be to have a random number field associated with each user (in addition to that user's login id, password and whatever else there may be). The login procedure would proceed as follows: 1) Program prints "login:" prompt to the screen 2) User types in his user id 3) Program looks up the random number associated with that user and prints it to the screen 4) User then checks whether the number is correct. If it is, the login program is thereby authenticated. 5) The login program prompts for the password and the the user can feel safe in supplying his password to the login program. 6) Upon receipt of the correct password, the login program permits the user to access to the computer. In addition, the login program also calculates a new random number, stores it in the allocated field associated with the user and prints it to the screen so the user will know what number the login program should send down the next time he tries to log on. Of course if you have the budget and don't want to have to rely on the user to remember a random number that changes with every login, then you can use some sort of additional physical device such as a datakey or smartcard to store the number. The computer could read it off of the medium directly and it would never have to be displayed for human eyes to behold. If you want to get fancy, you could encrypt it before transmitting it. Susan Symington, COS From: schoi@cmx.npac.syr.edu (Seokrim Choi) 25-Jan-1989 5:59:35 To: security@pyrite.rutgers.edu Subj: [357] Security equipment Hi, folks I'm not sure this is right place to ask this, but.. Does anybody know a place which sells electronic security equipment ? (ie. burglar alarm, fire alarm, various sensors etc etc..) If I can get their catalog first, that'll be perfect. Any comments will be greatly appreciated. Thanks. ----- Seokrim Choi > schoi@cmx.npac.syr.edu From: Stephen Wadlow 25-Jan-1989 6:19:35 To: security@pyrite.rutgers.edu Subj: [779] rotating pin locks Over the summer I managed to obtain a few Medeco cylinders for examination. After disassmbly, reassembly, and lots of referring to the medeco diagram, I knew enough to pick the little bugger open. It just took a *long* time (on the scale of hours for a fully loaded cylinder). I have heard stories of people being able to pick a fully loaded medeco in a matter of minutes, and have been trying to figure out how the h-ll they do it (assuming it's true). Anyone have any pointers or techniques they'd like to share? steve ====================================================================== Stephen G. Wadlow Internet: stephen.wadlow@andrew.cmu.edu System Manager Bitnet: wadlow@drycas Center for Fluorescence Research -- Carnegie-Mellon University From: stiatl!john@gatech.edu 25-Jan-1989 22:19:42 To: security@pyrite.rutgers.edu Subj: [2741] Re: EMP (Electro-Magnetic-Pulse) Luggage scanning. The problem with this scheme, even if it would not damage electronics is that it's very easy to defeat. Simply wrap the explosive in a conductive and/or magnetic material like Mu-metal and voila! No Boom. In a related issue. Much press has been given to this new Thermal Neutron explosive detector. Being a Nuke by training, the underlying assumptions give me some heartburn. The principle of operation is that nitrogen-rich explosives, when irradiated with a thermal neutron flux will have some nitrogen atoms transmuted to the N-16 isotope. N-16 has a half-life of a few second and decays with a highly energetic and characteristic gamma ray. This gamma ray is detected, processed and used to generate the alarm. Here's the rub.. Thermal neutrons are easily stopped by materials with high cross-sections like cadmium. No neutrons in the explosives = no N-16. No N-16 = no detection. Since it is likely that Californium is the source of neutrons, the flux is not likely to be high because of cost (several thousand dollars per microgram). Thus the flux could probably be stopped by a cadmium foil. By implication, a perfect explosive would be some plastique or C4 shaped like a candy bar and wrapped in cadmium "foil". this would look normal to visual and X-ray inspection and would defeat the neutron detector. So the question arises "Is this TOO easy or am I missing something". Considering the government's involvement, it's quite likely the former. I'm wondering if there is anybody on the net familiar with the specific design of the detector. If so, am I missing something? It seems to me that a much more suitable detector would be one of the proven nitrate sniffers. These things have been in use at Nuclear plants for at least 7 or 8 years. I can testify as to their sensitivity after setting one off with power residue from a weekend target practice session. The functionality test the guards used at one site was to try to carry one of these nitroglycerin despensing angina patches thru the gate. It would detect the fumes from the few milligrams of nitro in these patches. For even better sensitivity, the nitro sniffer could be coupled to the altitude chamber now in use. The vacuum chamber would enhance the mobility of emitted explosive molecules and the exhaust of the vacuum pump would contain a concentrate of the chamber atmosphere. As an added benefit, these things cost a few thousand bux, not a million or more like the neutron device. Comments? ------------------------------------------------------------------------------- John De Armond, WD4OQC Sales Technologies, Inc ...!gatech!stiatl!john Atlanta, GA (404) 841-4000 From: James M Galvin 28-Jan-1989 0:34:39 To: security@rutgers.edu Subj: [270] using RSA Cryptographic Algorithm I am sure that people have programmed the RSA Algorithm, but has anyone done an implementation they are willing to share? Also, for those who have done implementations, have you done any kind of benchmarking, or can you share any good or bad experiences? Thanks, Jim From: Russell Brand 28-Jan-1989 0:51:47 To: koreth@ssyx.ucsc.edu Subj: [419] Zero knowledge passwords? Cc: misc-security@ames.arc.nasa.gov With .secret files, fake login programs are easy to detect, because unless the program is running as root (in which case it would have access to all the accounts on the system anyway), it won't be able to read and print the proper .secret file. It seems that the attacking program could just "rsh" or such and send the username. It would then get the secret back to show to the user. What am I missing? From: felix!chuck@dhw68k.cts.com (Charles Vertrees (Chuck)) 28-Jan-1989 1:13:26 To: security@pyrite.rutgers.edu Subj: [1957] Re: EMP (Electro-Magnetic-Pulse) Luggage scanning. What happens when military electronics is exposed to a big EMP, like from a nuclear blast? You can unit test in chambers an such, but how does the design really work in place? The Air Force decided to find this out by building a huge wooden trestle next to Kirtland AFB in Albuquerque in the 70's. Really something to look at. This thing stuck out over the Tijeras canyon, which runs immediately south of the airport, roughly paralleling the main E/W runway. I never got to see it up close, but as you fly in or out of the airport, you can usually see it. (Albuquerque is joint use, military/commercial.) The plan was sort of simple: Test how a complete unit, electronics and all, (read that airframe) reacts to an EMP while flying in the air. This trestle is big enough for them to park a B-52 on the thing and have it end up 50 or 60 feet off of the ground. They had a taxi strip from the main airport area and would simply tow whatever the test subject was to be out there and push it out onto the trestle. I remember reading about the construction of this thing and about how they were going to zap the planes, but it has been a long time. Something about lots of capacitors and big coils. Normal stuff. The trestle was almost more interesting because of the problems they had building it. Seems that it was very difficult to find enough carpenters who could still build such a thing. The design call for 100% wood. No metal. No nails, no bolts. This was required because of the strength of the pulses they were going to be using. Urban legend had it that they would literally pull the nails from the structure if they had been present. I don't know if this was true, but, electrically, they would effect the test, since a flying aircraft usually doesn't have pieces of metal floating around it in space. I think both Sandia Corporation and EG&G were involved in the project, the results of which are probably classified. Chuck V. From: J.D. Abolins 28-Jan-1989 1:33:06 To: SECURITY@pyrite.rutgers.edu Subj: [1690] "Tools of burglery" Although I can't speak for other states, I remember from my EMT (Emergency Medical Technician) training that in New Jersey, the possession of a "slim-jim" or similar extrication tools OFF DUTY could considered possession of burglery tools. The instructors warned those of the EMT trainees who would be working with first aid squads to leave the extrication tools with the rig or the squad building. >From another experience, I also learned that other people's knowledge of one's tools or abilities regarding locks is a big liability. (I may have told this before, if so please have patience...) While in college, I worked as a porter (janitor) in a hospital. One day, the houskeepers had accidentally locked themselves out of the laundry room while a washing machine was overflowing. The suds were coming out of the room, flowing under the door. I offered to try to open the door. Fortunately, one of the housekeepers warned me that it would be far better to allow the flooding to continued and wait for the hospital to call in a locksmith. The wise reasoning for this advice was that if the hospital knew that I was "good with locks", the next time the drug inventory came up short or something was missing, I would become a major suspect. (Interesting enough, I find a similar hazard in the computer field. I am not a computer security manager/technician by title in my job. So there is some risk that if anything should happen with our computer systems, some of the Department's administra- torswould point their fingers at me. "After all, he writes articles about computer viruses; he studies them; he must be the culprit."But that a bridge yet to be crossed, if ever.) From: "AMSP2::CHRISTEVT" 28-Jan-1989 1:56:12 To: "security" Subj: [1758] MIT hacking ethics I'm MIT '86 and what Hobbit says about the hacker ethic there is completely true! Not only is common thievery shunned, but those unfortunate enough to be caught (by CPs or other hackers, which is probably worse) doing such things are black-listed by the other hackers themselves. NON-DESTRUCTIVE entry and common sense are strongly encouraged by MIY hackers and those who don't go along with this idea (in theory and, most importantly, in PRACTICE) don't get much help from those who do. And the sign-ins are indeed the most that usually happens while building hacking...the only people who look for these are other hackers, to see if they know who's already been there and such. I also love to explore buildings and such and my mother is one of those hard-to-convince-it's-harmless-and-creates-no-security-risk ones; but if one is careful and "ethical" (as described above, in part), it really IS harmless!!! However, I have to agree with my mom on one point: what is accepted at colleges/universities/educational institutions may not and probably will not be accepted by civilian police and similar. What we call hacking the police may call breaking and entering. By the way, if any hacks are being planned in the Dayton, OH, or Southern California (specifically around San Pedro, Long Beach, etc) areas, please let me know!!! Thanx! ET B ME VIC ! Victor ET Christensen "To the last I grapple with thee, christevt@wpafb-ams1.arpa From Hell's heart I stab at thee, christevt@p6.ams.wpafb.af.mil For Hate's sake I spit my last breath christevt%amsp6.decnet@wpafb-ams1.arpa at thee!!!" ~ Kahn From: nugent@anubis.uchicago.edu 28-Jan-1989 9:11:13 To: Stephen Wadlow Subj: [758] Re: rotating pin locks Cc: security@pyrite.rutgers.edu I understand from our local locksmith that Medeco still offers a reward for someone who can pick a Medeco lock on request and I think you get several hours. I have to admit, I'm curious how you do it since there is no way to apply pressure to the side bar (the part that checks the rotation of the pins) beyond what the springs supply. For those not familiar with Medeco locks, the keys incorporate a left, right or center rotation as well as the usual up and down positioning for each pin, so picking the lock requires adjusting 6 angles as well as 6 different heights. Collecting the Medeco reward probably requires that you pick one of their newer Biaxial locks, which include the forward and backward pin alignments as well as left and right. Todd From: aad@stepstone.com (Anthony A. Datri) 28-Jan-1989 9:31:12 To: security@pyrite.rutgers.edu Subj: [267] login simulators I ran into several of them at CMU. The most notable was one that ran on the PC's often used as terminals. The person behind it would collect the passwords and ravage the victim's directory. The best way to guard against this was to carry your own copy of Kermit. From: (Tom, Tech. Support) 28-Jan-1989 9:51:12 To: SECURITY@pyrite.rutgers.edu Subj: [3651] VAGUE LAWS, CONTINUED I see one problem in directly addressing any criminal activity. Many laws on the books are, like it or not, subject to selective enforcement based on intent. Using the baseball bat example: Section 906 (Possessing Instruments of Crime) of the Pennsylvania Crimes Code states that "A person commits a misdemeanor of the first degree if he possesses any instrument of crime with intent to employ it criminally". (The section defines "instrument of crime" as "anything specially made or adapted for criminal use or anything commonly used for criminal purposes possessed under circumstances not manifestly appropriate for lawful uses it may have." The section also defines the offense as possession of "a firearm or other weapon concealed upon his person with intent to employ it criminally" And "other weapon" is defined as "anything readily capable of lethal use and possessed under circumstances not manifestly appropriate for lawful uses it may have". (There's the baseball bat conviction). Since this discussion started relative to possession of locksmith tools, I should point out that this section clearly relates to those devices, yet there is no SPECIFIC exemption for locksmiths. I doubt that any locksmith in the course of business would have a problem. (There is a section on master keys for vehicles which DOES exempt locksmiths). The Pennsylvania Crimes Code has many other examples of this type of selective enforcement - Criminal Attempt, Criminal Solicitation, Conspiracy, Loitering or Prowling at Night, and Disorderly Conduct to name a few. These types of laws tend _not_ to be subject to poor judgement and they are usually brought in conjunction with other crimes.(How else can you _prove_ criminal intent). I think any laws relating to computer security would, because of the complexity of the subject, be equally vague if not more so. Clearly, virus writing would appear to be a violation of something. On the other hand, could something like the "Peace Virus" in the Macintosh fall into some hard and fast law? It did no damage and offended no one except for the emotional fury resulting from someone secretively getting into our private business (Should it be it a violation of the law to anger another? What is really "private"?) I wonder: * If any set of statutes can really cover everything that _should_ be illegal considering that nothing _is_ illegal unless there is a law against it. * If any set of statutes can be written without some vagueness somewhere. * If any computer security statute can be written without some clever and enterprising hacker getting around it the minute some new technology is available (which happens almost daily). * If perhaps the only statute we need would make it unlawful to access _any_ file that the perpetrator has no legitimate right to access. * What constitutes "legitimate right" ... Even that sounds vague! As an aside, there is a philosophy (which I don't subscribe to) that says the only reason there are criminals on the street is that the criminal justice system has failed. Perhaps it could be said that the only reason computer security is ever breached is because the System Managers and Security Administrators have failed. I doubt that, but ... * HAVE A GOOD DAY * * * * Tom Mahoney * * Computer Electronics Tech. * * * * FRANKLIN & MARSHALL COLLEGE * * Computer Services * * Technical Support Center * * Lancaster, PA 17604-3003 USA * * * * Bitnet Address: TOM@FANDM * ********************************* From: J. D. Abolins 28-Jan-1989 11:11:13 To: SECURITY@pyrite.rutgers.edu Subj: [1006] EMP methods for bomb detection; Security & personnelinfo req. I have only recently heard about the proposal to use EMP (electro- magnetic pulse) to detect bombs. So Ihave little information. Yet the comments that this method can detect bombs by detonating them is far-fetched. Yes, the EMP method would be useful against electronic timers for detonation. But if the explosives are not attached to any electronic device, it appears that EMP would do little. But the concern about legitimate electronic equipment being damaged is valid. ------------- About my recent posting about personnel risks in security, it can be editted and reprinted. All I ask is that the publication would send me a copy of the particualr issue. I am posting this because I received a request for use of the posting. Unfortunately, the person making the request does not have a BITNET id, so I can only reply through this listing. But if anyone does have questions, you can contact me at: J.D. Abolins 301 N. Harrison Street, #197 Princeton, NJ 08540 USA Phone: (609) 292-7023 weekdays From: tim@csc-lons.arpa (Tim Dennison) 28-Jan-1989 19:31:16 To: misc-security@sdcsvax.ucsd.edu Subj: [821] [819] Return-path: Date: Thu, 19 Jan 89 11:38:23 est From: tim@csc-lons.arpa (Tim Dennison) To: misc-security@sdcsvax.ucsd.edu In Virginia anyone can own and possess a "slim jim". I am an ambulance attendant part time and bought my slim jim from my uniform store. Sounds good huh???? If you get caught committing a crime (any crime) with the slim jim the crime automatically becomes a felony. An example is in order. In Virginia, entering someones car without their permission is "vehicle tampering" a misdemeanor, if you use a slim jim to open the door it becomes a felony. In my opinion this is a good way to handle "tools". A slim jim is one of the most important extracation tools I have on my ambulance, and in my car. If it became illegal to possess one I would be in trouble. This allows us law abiding citizens to help people, but penalizes those who choose to leave the accepted social norms. Tim Dennison tim@csc-lons.arpa From: Bernie Cosell 28-Jan-1989 19:51:15 To: misc-security@uunet.uu.net Subj: [5337] Virus on the loose in DEC's ENET? I heard a rumor from a friend that DEC's ENET is being plagued by a worm that is running rampant. Anyone have any details? comfirm/deny? whatever? __ / ) Bernie Cosell /--< _ __ __ o _ BBN Sys & Tech, Cambridge, MA 02238 /___/_(<_/ (_/) )_(_(<_ cosell@bbn.com **************************************************************************** [Moderator add-on: Do you mean the following, by any chance? I wasn't going to forward this since it was rather out of date even when I got it, but perhaps the thing is still going around. You did say DEC's network, and this says HEPNET, but decnet is decnet, so it may have hopped the tracks at some point. Caveat vaxer, then... _H*] **************************************************************************** Date: Fri, 23 Dec 88 19:54:27 est Sender: Virus Alert List From: lecgwy!lyons%RUTGERS.EDU@IBM1.CC.Lehigh.Edu Subject: VIRUS WARNING: DECNET Worm (forwarded from VALERT-L) The following information relates to the DECNET worm which hit the HEPNET and infects DEC VMS systems. Note that in addition to the information presented here, the possibility exists that a non-HEPNET system may have been infected. You should check your system for a file by the name of HI.COM, and a process running with the name MAIL_178DC. If you find either of them, your system more than likely has been infected. Read on for further background, as well as a more thorough explanation. Thanks to Ed DeHart at CERT, Fred Ostapik at ARPA-NIC, and all others who helped assemble this information. ---- Marty Lyons, Lockheed Electronics Company, 1501 U.S. Highway 22, CS #1, M/S 147, Plainfield, N.J. 07061-1501 (201) 757-1600 x3156 LYONS@LECGWY.LEC.LOCKHEED.COM or LYONS%LECGWY.UUCP@AUSTIN.LOCKHEED.COM Worm-fix distribution list: CERT, CMU (cert@sei.cmu.edu) John Wagner, Princeton (wagner@pucc.bitnet, wagner@princeton.edu) Chris Tengi, Princeton (tengi@deepthought.princeton.edu) Nick Cardo, JVNC Supercompuer Center (cardo@jvncc.csc.org) Chuck Hedrick, Rutgers (hedrick@rutgers.edu) Steve Keeton, NJIT (syssfk@njitx.njit.edu) Seldon Ball, Cornell (system@crnlns.bitnet) Nick Gimbrone, Cornell (njg@cornella.bitnet) Sandi Ivano, Yale (???) Anio Khullar, CUNY Graduate Center (ank@cunyvms1.bitnet) Shakil Khan, CUNY Queens College (khan@qcvax.bitnet) Meredith Coombs, Stevens Tech (???) Ken Ng, NJIT (ken@orion.bitnet) Dave Capshaw, Lockheed-Austin (capshaw@austin.lockheed.com) Marty Lyons, Lockheed Electronics (lyons@lecgwy.lec.lockheed.com) Randi Robinson, CUNY (rlrcu@cunyvm.cuny.edu) BITNET Laison Distribution List (laison@bitnic.bitnet) BITNET Linkfail List (linkfail@bitnic.bitnet) BITNET Virus Alert List (valert-l@lehiibm1.bitnet) UUCP/Stargate Announcements (announce@stargate.com) > From rutgers!sei.cmu.edu!ecd Fri Dec 23 17:59:18 1988 > Date: Fri, 23 Dec 88 17:28:48 EST > To: lecgwy!lyons, steinauer@ecf.icst.nbs.go > Subject: Re: NASA Virus The following information has been provided by one of the VMS experts on the Internet. Due to the holidays, the CERT has not been able to verify the information. If you do verify the information please let us know. Thanks, Ed DeHart Software Engineering Institute / Computer Emergency Response Team cert@sei.cmu.edu 412-268-7090 ======================================================================= There is a worm loose on NASA's SPAN/DoE's HEPNET network, which is an international DECnet-based network. The worm targets VMS machines, and can only be propagated via DECnet. The worm itself appears to be benign, in that it does not destroy files or compromise the system. It's purpose appears to be to deliver a Christmas message to users starting at midnight on 24 Dec 1988. It does have a hook in it to monitor it's progress; it mails a message back to a specific node (20.117, user PHSOLIDE) containing an identifying string of the "infected" machine. The worm exploits two features of DECnet/VMS in order to propagate itself. The first is the default DECnet account, which is a facility for users who don't have a specific login ID for a machine to have some degree of anonymous access. It uses the default DECnet account to copy itself to a machine, and then uses the "TASK 0" feature of DECnet to invoke the remote copy. There are several steps which you can take to protect yourself from this kind of attack. The easiest (and most restrictive) is to disable the default DECnet account on your machine altogether. This can be done with the following commands from the SYSTEM or other suitably privileged account: $ Run SYS$SYSTEM:NCP Purge Executor Nonprivileged User Account Password Clear Executor Nonprivileged User Account Password ^Z This requires that everyone who accesses your resources via DECnet to have a legitimate login ID or proxy login account on your machine (proxy logins are discussed in detail in chapter 7 of the _Guide to VMS System Security_). [There's more, but it's long-winded instructions on how to dink decnet objects which should be obvious to most of us. I'll forward the whole wazoo to people who ask for it; you can also probably dig it out of the valert-l archives [if there are any]. _H*] From: PGOETZ@LOYVAX.BITNET 30-Jan-1989 12:00:35 To: hobbit@pyrite.rutgers.edu Subj: [437] Burglar invitations I had a few keys copied, and I noticed a little item on sale by the key blanks: A keyring with a label to write down your name and address. The idea is that if you lose your keys, the honest soul who finds them will mail them back to you. Of course he would not go to your house, unlock the door, take what he wants, and drive away in your car. The trust some people show in their fellow man is truly touching... Phil Goetz From: len@csd4.milw.wisc.edu (Leonard P Levine) 30-Jan-1989 12:05:28 To: misc-security@uunet.uu.net Subj: [627] Re: rotating pin locks Does anyone know if any vendor makes a lock that reads a key and stores its keycode. (I mean read the bumps) + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.milw.wisc.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U.S.A. Modem (414) 962-6228 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + [Moderator add-on: A *lock*? If you mean a *tool*, then yes, it's called a pair of calipers and a cut chart. _H*] From: Jim Shaffer 30-Jan-1989 12:36:36 To: security@pyrite.rutgers.edu Subj: [905] Re: Virus-writing >In the Mac world, I know of only one instance in which a virus was >propagated through a commercial/skrink-wrap package... this was the case >in which a copy of Brandow's "macMag World peace" INIT virus infected ... Just to set the record straight, this depends on your definition of "commercial." Due to infection of a computer at Microsoft, a lot of European beta-test copies of Microsoft Word 4.0 for the Mac are reportedly infected with nVIR. (See recent issues of Virus-L[@LehiIBM1.Bitnet]) Also, through the same channel I've heard of a CD-ROM for the Mac that was a collection of many public-domain or shareware utilities, of which 11 on the disk were infected by a virus (I forget if it was Scores or nVIR). This of course defeats the purpose of the CD-ROM, because they must be copied to other disks and disinfected while the purpose of the CD-ROM was to have everything in one nice package. From: Russell Brand 30-Jan-1989 12:54:14 To: misc-security@uunet.uu.net Subj: [824] crypto '89 Crypto 89 Santa Barbara, CA (August) I am running a special session on practical and innovative uses of cryptography in computer security. I am still looking for another couple of speakers. If you are doing or have done something appropriate, please contact me. Ideally I am looking for papers in one of three categories: 1) we had this clever idea that uses cryptography and it worked. 2) our clever cryptogrpahic application failed for surprising reasons. 3) we have an application where there seems lie there should be something clever we could do with cryptography, but we haven't been able to find what we need in the literature. Of course I would be pleased to hear other innovative ideas. thank you russell brand brand@lll-crg.llnl.gov 415 548 1361 (Please forward/repost this as appropriate) From: stachour@cs.umn.edu (Paul Stachour) 30-Jan-1989 13:10:06 To: misc-security@rutgers.edu Subj: [1672] Re: Zero knowledge passwords? Well, to start with, any reasonable system tells you when you get on when you were last on. The login-simulator doesn't know, and thus can't tell you. At least you know you've been had, and can get off and back on and change your (just-compromised) passsword immediately. Better systems (such as Multics) have no way to login-from-within a-process. Thus the login-simulator can't do anything after it gets your password but force a logout, since otherwise you'd know immediately that it was a fake, since it doesn't have access to your start-up.ec, and other personal files (unless of course you are on a junky system where either the system or common practice makes all your personal files readable by the world). Login from within a process isn't ever needed, unless the system has such a poor sharing mechanism that you need to do that to get the kind of access you need. For example, that's why Multics has the "installer" in a SysDaemon process that no-one can ever login to. No system should ever allow the equivlent of the unix "login to root", but then Unix was built as a cheap cut-down Multics without most of the reliability that Multics was designed for. And the really good ones are set up so that each invocation of the login process gives you an authentication at the conclusion of your login (or maybe at your logout). When you login again, after you give your userid and before you give your password, the login processor gives you its authentication counter-sign. If it can't give you the right one, then you know it's a fake. And you don't give it your password. Old technology. But like most of computer science, forgotten by most. ...Paul From: Daniel Ray 31-Jan-1989 4:49:46 To: security@pyrite.rutgers.edu Subj: [1594] Re: password aging It seems that the prevailing opinion is that password aging is a complete waste of time. I think it can be of use it certain circumstances. Years ago when I was first exposed to UNIX, I lusted after having root privs. The admin encouraged me to learn everything I could, but, with good reason, would not give away the root password to regular employees. One day I carefully watched him su to root, and because the password was awkward to type, I was able to figure out what it was. Later I became root and trounced around the system. This lasted only a couple weeks, however, because there was a regular policy of changing the root password, and I was locked out from then on. If a privileged account has a well-chosen password, it is usually unlikely for a hacker to be able to guess it. However, a coworker might be able to piece it together if he sees the admin use it enough times, or if it is TOO "well-chosen" and is hard to type quickly. Regularly changing such a password will effectively limit this kind of "coworker attack". Password aging, per se, may not be needed if a regular policy of changing privileged passwords is used. norstar The Northern Lights, Burlington Vermont | tnl dialins: 802-865-3614 at 300-2400 bps. ` | / ------------------------------------------ --- * --- uucp: uunet!uvm-gen!tnl!norstar or / | . {decvax,linus}!dartvax!uvm-gen!tnl!norstar | [Moderator add-on: Facilities with this kind of "security" problem should seriously reconsider who they hire on as "co-workers". _H*] From: *Hobbit* 31-Jan-1989 5:27:14 To: security@rutgers.edu Subj: [2187] Friction is your friend This is sort of a followup to Steve Wadlow's medeco question. I should point out a common truth about most mechanical locks that in theory allows any of the "high-security" ones to be opened. I call it the Differential Pressure algorithm... The "method" for Medecos involves manipulating until you have every tumbler either at a correct position or a "false" position, whereupon the cylinder cocks over a little bit and binds. These false positions are highly touted as a security feature in any lock that has them -- the manufacturers perceive these as complete dead ends to anyone trying to pick the lock, and that if you hit any of them you've lost and have to completely start over. Wrong! Consider this: the difference between a real position and a false one is usually a few thousandths of metal. A tumbler at a correct position will no longer be binding the cylinder closed, and will have plenty of perceivable free play, while a false-notched tumbler will be held tightly in place and exhibit no slop at all. The Method involves finding these falsely-positioned tumblers and correcting them as they appear, usually by twisting them around with a pointy probe, until they allow the sidebar to drop. Naturally due to random machining slop you may lose a couple of other tumblers while backing out far enough to clear the false notch and get over to a real one, but they can be re-corrected. The point is that even while "stuck" at the false positions, one can "map" which positions are definitely false, and optionally correct them. This thinking can be applied to numerous other types of locks including but not limited to Simplex, most cheap combination padlocks and bicycle locks, Abloys, and quite possibly plenty I haven't had a chance to examine. This rather simple idea appears to be out of reach of most locksmiths, though, who seem to unquestioningly believe the manufacturer's party line... By the way, there is no longer a "reward" for picking Medecos. Even the Medeco people acknowledge that "it happens occasionally" when a bored locksmith decides to have a go at one. Neither is there a reward for Abloys, even if they're said to be harder yet... _H* From: scarter@caip.rutgers.edu (Stephen M. Carter) 1-Feb-1989 11:08:15 To: misc-security@rutgers.edu Subj: [262] Re: rotating pin locks Also, what are the various different types of Medecos? Our campus key shop guru told me that we have even a more advanced Medeco than the standard, and was almost foolproof (although they said the same thing about our 7 pin Yale cylinders a few years ago :-)) From: Jeff Martens 1-Feb-1989 11:19:53 To: misc-security@cis.ohio-state.edu Subj: [358] SCOMP Does anyone know what the present status of SCOMP Plus is? SCOMP was an operating system rated A1 secure by NSA NCSC several years ago. It ran on a modified Honeywell DPS-6. SCOMP Plus is an upgrade to a 32 bit DPS-6 Plus which should have been released by now. Has it been? Has it been evaluated by NCSC? Thanks. --Jeff (martens@cis.ohio-state.edu) From: Philip Peake 1-Feb-1989 11:39:53 To: misc-security@pyrite.rutgers.edu Subj: [548] Who *benefits* from viruses ? Just a passing thought ... Software merchants, particularly the home and small buisness types have a serious problem - piracy. Current methods obviously don't work. Copy protection methods just give rise to a sales boost for the latest copy programs which know how to defeat this sort of thing. Copyright as never worked - even for books ! So, some kind person comes along and starts to distribute a virus. This makes everyone SO SCARED of accepting a non shrink-wrapped diskette that the piracy problem just goes away ... Think about it ... From: dcdwest!sarge@ucsd.edu (Sergeant Bob Heddles) 1-Feb-1989 11:42:02 To: security@pyrite.rutgers.edu Subj: [869] Sargent & Greenleaf Lock I was wondering if anyone on the net has had the opportunity to try and open a S&G lock without the proper combination?? Does anyone know if the S&G people can open it and reset the lock to the factory settings then return same to me. I came across one in a storage box and with the price of these locks it would be a shame to have to trash it, since it is still in perfect condition, only won't open since everyone that had the combination is no longer working here and/or has forgotten it over the years.. Any and All help is appreciated.. Thanks in advance Sgt. Bob Heddles (Security) -- Bob Heddles | ITT Defense Communications Division ucbvax!ucsd!dcdwest!sarge | 10060 Carroll Canyon Road dcdwest!sarge@UCSD.EDU | San Diego, CA 92131 Opinions expressed are mine alone. No one else wants them.. From: crook@utgard.UUCP (Chris Crook) 6-Feb-1989 11:23:16 To: misc-security@ames.arc.nasa.gov Subj: [790] Re: Security equipment This is not meant to be an advertisement in my behalf so I will simply quote an article from an insurance magazine: "You may order a booklet about alarm systems from the National Burglar and Fire Alarm Association, 1120 19th Street N.W., Suite LL20, Washington, D.C. 20036. Enclose a check or money order for $2. If you install an alarm system... you may be eligible for a discount (on your insurance)." I sent in my $2 but have yet to recieve my booklet yet (although the check has cleared). Hope I have been of some assistance!!! C. Crook +-----------------------------------------------------------------------------+ | The opinions expressed here are clearly not my own, nor anybody elses! | +-----------------------------------------------------------------------------+ From: steve@ncsc.arpa (Mahan) 6-Feb-1989 11:44:12 To: security@rutgers.edu Subj: [1188] [1186] Return-path: Date: Tue, 17 Jan 89 06:57:10 CST From: steve@ncsc.arpa (Mahan) To: security@rutgers.edu Subj: EMP exposure for explosive detection I have done some study on the effects of EMP on various materials. Firstly, the EMP will not set off typical rifle or pistol ammunition, as the metal shell casing provides a good shield for the powder. I would assume that the shells that the Navy was having problems with were electrically fused. Any explosive that depended upon electrical means for detonation would be likely to detonate when exposed to an EMP. However, this is due only to the induced voltages and currents in the detonator circuits. Any electrical devices, especially those using integrated circuits, are most probably going to be rendered useless by the pulse. The intense magnetic field of the pulse will erase magnetic media unless it is extremely well shielded by a ferromagnetic material (Aluminum will not do). There are several papers and books on the effects of EMP dating from the 1950's to the present date. The best starting topic is probably nuclear weapons effects. Most of the information is unclassified and beats Stephen King for horror. :-) Stephen Mahan Naval Coastal Systems Center Panama City, FL 32408 steve@ncsc.ARPA From: jim@xanth.cs.odu.edu (Jim Duncan) 6-Feb-1989 12:49:53 To: misc-security@mcnc.org Subj: [1501] Re: Security equipment When I was in the alarm business a few years ago we bought more than half of our equipment from North Supply, a subsidiary of United Telecom. They originally were suppliers of telephone equipment, everything from central office switches and phones to telephone poles (and the strap-on steel gaffs for climbing them). The move into security equipment was quite natural because the product lines and the people who buy them are so similar. They carry a wide range of alarm equipment and hardware, more than what's listed in their catalog. North Supply 600 Industrial Parkway Industrial Airport, Kansas 66031 Phone: (913)791-7000 Telex: 4312079 When I was buying from them, they had a WATS line for me to call in my order and for talking to technical support; I don't know if they still do that. They might pay your shipping; they did for us. It was extremely difficult for other suppliers to beat North Supply's price on most items, especially hardware, since they were supplying so much of it to phone companies. Disclaimer: I don't have anything to do with North Supply; I am a satisfied past customer. The information in this posting is dated. The address and phone number listed above is current. When you call to ask for their catalog, be sure to tell them you need the catalogs for both security equipment *and* phone equipment. Jim Duncan, Computer Science Dept, Old Dominion Univ, Norfolk VA 23529-0162 (804)683-3915 INET: jim@cs.odu.edu UUCP: ..!uunet!xanth!jim From: SPOCK@CALSTATE (Commander Spock) 6-Feb-1989 13:27:52 To: security@marist Subj: [3249] "Viri Logicum" I am currently an undergraduate student at California Polytechnic University, Pomona, CA, majoring in Computer Information Systems. I am a senior and have a couple more "core" classes to go before graduating. Right now, I'm in a interesting class called "Information Resource Management". In our class, we are supposed to give a 40-minute presentation on a topic that he has listed and we have selected. Mine was on "computer security". Now I have several questions. For one thing, what sort of "satisfaction" (if any) does the person receive when he (or she) hears that their little program is wiping out have the country's defense network system or ruining entire departments within large Fortune 500 (not to mention the smaller companies) companies? Most of the reading that has been published so far on those caught say that they did not write the programs on purpose. If so, why the **** did they write it in the first place? Second, what right do they have in attempting to distribute the program(s) and ruin other people's property? I fail to see how lawyers, judges, and bureaucrats alike don't REALLY sit down and conjure up some good, punishing laws. If the virus (or "viri...plural) destroys systems and the author of the program is found, should privacy laws or trespassing laws punish those who created the material? I have to admit: part of the problem with the spread of viri is that people often destroy the systems themselves with little or no aid from the viri; that is, in a state of panic, people are the virus, not the virus. To me, it sounds like funny logic, but look at the special viri that have affected the Macintosh community (P.S. I'm a Mac user). For instance, the "nVIR" virus has little if no special consequences from its disruption(s). Yet, when people run programs like Interferon or Ferret (for SCORES) or a message pops up (like with Vaccine), people go into a frenzy...a state of shock almost. By trying to fix the problem, people make matters worse. In addition, the emphasis of backing up your system should be (STRONGLY) emphasized. I myself have a rather large hard drive (70 Mb). Several hours and disk-paks later, it's all done. People complain about the time it takes to make a lousy 6 to 8 hour backup, *BUT* when the virus (or viri...let's suppose double-wammy) attack the system, it takes much longer to recoup the material that was lost. What's the logic here? Logic and physcology play important emphasis here in addition to fixing the actual problem. Now as a special request, can anyone provide me with any background behind viri? Two, are there any good books on how viri work or how people react psycologically to these problems? Three, can anyone name of some good laws that have been or currently being written into effect to remedy such situations as what has happened this past year or two? I would appreciate *ANY* comments, suggestions, information, or sent material to either of the two addresses listed below. Thanks for listening, and thanks in advance for any information. Pax vobiscum. Spock INTERNET: cbds080@ccs.csuscc.calstate.edu cbds080@c730.c730.csupom.calstate.edu BITNET: cbds080@calstate.BITNET From: Lynn R Grant 7-Feb-1989 18:58:54 To: misc-security@rutgers.edu Subj: [290] Government Certification of Software There is government certification of software, of a sort: the National Computer Security Center ratings for trusted systems. And just as everyone has said about certification, it is slow, labor intensive, and imposes a lot of work upon both the vendor and the government. Lynn Grant From: ask@cbnews.att.com (Arthur S. Kamlet) 7-Feb-1989 19:14:19 To: misc-security@att.att.com Subj: [571] Re: Burglar tools If you are charged with burglary, then the prosecution must prove you had intent to commit a crime. Possession of lockpicks is evidence which a jury could believe to mean you planned to enter rooms in the building to remove items, even if you never did. A defendant caught in this position would be expected to say he just wanted to trespass, and never intended to remove any property. So, a defendant who says what he would be expected to say may not be believed by a jury. It's a tough situation. -- Art Kamlet ask@cbrmb.att.com AT&T Bell Laboratories, Columbus From: adamj@e260_4f.berkeley.edu (Adam J. Richter) 7-Feb-1989 19:34:11 To: misc-security@ucbvax.berkeley.edu Subj: [811] Re: Zero knowledge passwords? >a file called ".secret" in your home directory, which is printed instead >of the standard "Password:" prompt. [...] With .secret files, >fake login programs are easy to detect... You must also modify /bin/login so that it doesn't do this on a pty. Otherwise, the trojan horse can spawn a real /bin/login on a pty, and duplicate what that process prints from the same input. Even if you make /bin/login only executable by root, and pty's only accessible by setuid programs, it can still find out what login will print by using whatever mechanism normal users use for logging in across the network. Other than that, I think you've got a really bright idea. --Adam J. Richter Adam J. Richter adamj@widow.berkeley.edu 2600 Ridge Road ....!ucbvax!widow!adamj Berkeley, CA 94709 Home: (415)549-6356 From: jimkirk@outlaw.uwyo.edu (Jim Kirkpatrick) 8-Feb-1989 2:49:56 To: security@pyrite.rutgers.edu Subj: [1445] Login Insurance, CDC style Cory Kempf asks -- Are there any systems out there that implement some way of verifying that the program that you (the prospective user) are talking to is really the login program? I have forgotten most of the details, but one idea CDC has tried is as follows -- in the Device Interface (DI; "terminal server" in generic talk) one may define a trusted character sequence. It is usually something wierd like ^a^b, something a user would not normally enter. When the DI receives this sequence, it immediately terminates any connections/sessions in progress and starts a new one connected to the login process. Thus, if you know your terminal is connected to such a DI and you enter that sequence, you are now genuinely logging in. Of course you have to trust the ethernet cable too and so on. If you aren't sure your DI is set up that way and enter the trusted sequence, of course a good login simulator could simulate the proper response. You MUST know the DI was set up and what it's trusted sequence is. One problem is if you are on a PC, transferring files/data that use all 128 ASCII values, and "stumble" across the trusted sequence. BOOM, you're blown away and asked to login. That's also why the sequence is usually control characters. Terminals like Tek graphics terminals only use printable characters for the most part; I don't know about ALL file transfer protocols, but some stay away from control codes as well. From: "W. K. (Bill) Gorman" <34AEJ7D@CMUVM.BITNET> 8-Feb-1989 3:09:56 To: Security Digest Subj: [1613] Re: A response >Even if you catch the criminal red handed, in the act of committing a >crime, you still have to prove they _intended_ to commit the crime _when >they entered the building_ to make burglary stick. I have seen *exactly* this defense used successfully in court numerous times. >(Granted, possession of burglar's tools would certainly be an >indicator of intent Not necessarily. Consider the *incidental* thief who is also regularly and legitimately employed as a carpenter/plumber/construction worker/whatever and just happens to carry all these around in his vehicle, since they are necessary to his/her regular employment. Good luck with that one! ******************************************************************************* * A CONFIDENTIAL COMMUNICATION FROM THE VIRTUAL DESK OF: * ******************************************************************************* ............................................................................... |W. K. "Bill" Gorman "Do Foust Hall # 5 | |PROFS System Administrator SOMETHING, Computer Services | |Central Michigan University even if it's Mt. Pleasant, MI 48858 | |34AEJ7D@CMUVM.BITNET wrong!" (517) 774-3183 | |_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_| |Disclaimer: These opinions are guaranteed against defects in materials and | |workmanship for a period not to exceed transmission time. | |.............................................................................| From: 8-Feb-1989 4:06:45 To: SECURITY@pyrite.rutgers.edu Subj: [2900] Mac Virus - Guardian The following excerpt is forwarded from Spock@calstate: I recently downloaded a CDEV file named "Gatekeeper". Current version is 1.0. I'm not sure whether or not this is a BETA copy or not. But in lue of the situation, I thought it was worth a try testing the program. This program allows users to actually see what's going on with their resources as far as possible viri programs are concerned. it lists out there resource name, ID number, application that they attacked (or in this case, attempted to attack), application which\ they attacked from, and what source disk; not to mention the date and time. The program, by default, keeps a record log of everything from startup to shutdown. It prevents possible viri programs from attacking either the Finder or System files. I'm not sure whether the program prevents attacks on the Desktop file, but since both the author and myself have tested the SCORES virus, I feeel that the program DOES include the Desktop as one that is innoculated. Once gatekeeper is taken off the disk, the viri programs DO attack the applications and/or three files. When Gatekeeper is in the System Folder, nothing (ABSOLUTELY NOTHING) happens. As a personal testing of my own, I've tested "nVIR" as well as "SCORES" on Gatekeeper. In addition, I've tested "mutated" versions of "nVIR" at Gatekeeper. Gatekeeper STOPS ALL of those! I'm not sure whether or not it stops either "Hpat" or "INIT29"; however, someone has a copy of "Hpat" on his hard disk, and sometime this week, I plan on getting a copy of it. Hopefully this weekend, I'll have it isolated and disassembled. I've used MacNosy 2.35 (I have a newer version, but it doesn't seem to work real well with my Mac Plus) for disassembling into source code. However, there are some problems here with Gatekeeper. When exiting, Gatekeeper either locks up (with an ID=02 msg) or simply clears and redisplays (rapidly) a blank dialog (with NO msg) repeatly. I cannot seem to define a parmeter file for customizing certain applications that DO require certain resource checks (like MS Excel or ResEdit). That provides the same error message or dialog. The ID=02 message shows up on my Mac Plus, and the other message shows up on either the Mac SE or II. The IIx has NOT been tested yet. Other than that, I've been quite impressed with the product so far. And what's best is that it's FREE! Spock INTERNET: cbds080@ccs.csuscc.calstate.edu cbds080@c730.csupom.calstate.edu BITNET: spock@calstate.BITNET -David Richardson, The University of Texas at Arlington Bitnet: b645zax@utarlg Internet/Domain: b645zax@utarlg.arl.utexas.edu UUCP: ...!{ames, texbell!cs.utexas.edu}!utarlg.arl.utexas.edu!b645zax USnailMail: P O Box 192053, Arlington, TX 76019-2053 PhoNet: 817-273-3656 (FREE from Dallas/Ft. Worth, school months only) From: Russell Brand 8-Feb-1989 10:42:27 To: galvin@twg.com Subj: [291] using RSA Cryptographic Algorithm Cc: security@rutgers.edu RSA is patented algorithm. You can contact their corporate address to get details about conditions for use. Jim Bidzos RSA 10 Twin Dolphin Drive, Redwood City, CA 94065 As I understand it, unless you are either MIT or part of the government you will have to license it. /wuthel From: Jeff Makey 8-Feb-1989 11:02:27 To: Security Interest Group Subj: [1257] Re: Additional security to login Cc: Mark Crispin Mark Crispin recommends an "out-of-band" storage place for passwords, which would only be accessible by an appropriately privileged program, and suggests as a good example an unnamed operating system that sounds suspiciously like DEC's RSTS/E for PDP-11 computers (which I broke into as a college sophomore using a simple Trojan Horse attack). Unfortunately, this offers no more protection than a hypothetical UNIX password file protected as follows: drwxr-xr-x 13 root 1024 Jan 9 13:31 / drwxr-xr-x 2 root 3584 Jan 23 03:42 /etc -rw------- 1 root 2899 Jan 10 12:48 /etc/passwd except that there is no possibility of *accidentally* setting the file or directory permissions wrong. Any addition of some sort of "out-of-band" storage place on UNIX (say, /dev/passwd: a special device that is readable only by root, regardless of the inode mode) would be a kludge with limited benefit, and would no doubt be subject to its own special class of attacks. This scheme will have virtually no benefit on a well-administered UNIX system, whereas the cost is moderate and may be very high (if early implementations are easy to subvert). :: Jeff Makey Makey@LOGICON.ARPA From: EVERHART%ARISIA.decnet@ge_crd.arpa 8-Feb-1989 11:32:42 To: security@pyrite.rutgers.edu Subj: [1634] Dangers of password changes The benefits of changing passwords periodically SOUND fine. However, if I convince people to use passwords that are long (typically derived from sentences) and well chosen, and then ask them to repeat it every month or two, the response is to either write the passwords down OR to choose MUCH less secure passwords. Consider that if one requires changes quarterly, passwords like "Quarter11989" are easy to remember. They are also not so very secure once this discussion is overheard. Jan1989uary would be another template variation. Given that people have to remember their passwords, we should remember that if they choose their passwords well, they should NOT have to change them often. Try to force frequent changes and you'll get lousy password choices OR you'll have them written down near the terminals. Which you accept depends on how responsible your system's users are. A responsible computer user will choose a hard password to guess and will NOT need to change it often. Some guidance in choosing good passwords is valuable. I suggest people use first letters of words in some sentence they can remember, or combos of words and numbers not all of which may be English but which they can remember easily. If your system accepts random punctuation characters between words, they can be useful too. VMS is a bit limited there, unfortunately. This is said in the hope that people will not blindly go expiring peoples' passwords monthly and expecting that their system security will be improved by the practice. The actual effect on security may well be to lower it a lot. Glenn Everhart Everhart%Arisia.decnet@ge-crd.arpa From: Mark Crispin 8-Feb-1989 12:02:27 To: Jeff Makey Subj: [2655] Re: Additional security to login Cc: Security Interest Group My comments were not referring to RSTS/E, which was essentially a cheap imitation of the operating systems I was referring to (just as Unix was essentially a cheap imitation of Multics...:-)). While it is true that "security through obscurity" is of limited value (most of these crackers are following cookbook procedures that they couldn't figure out on their own), that isn't the benefit of having the passwords stored outside of the filesystem. The benefit exists in making trap doors more difficult. On one operating system, where passwords were associated with directories, the trap doors took the form of passwords secretly applied to system directories which normally never have passwords (so only privileged users could write to them). It could be a long while before the system manager notices that the root directory (or the directory on which the login procedures reside) has had a password applied to it. In the meantime, the cracker can get owner access to this directory from any account at any time, just by knowing the password. This isn't a problem on Unix, although you do need to audit for fake accounts with powerful group access rights. However, you CAN have file links to the password file in some unobvious (and quite accessible) place known only to our friend the cracker. Both forms of trap door are applied by a villian who "borrows" a privileged job/terminal while the owner isn't looking. The villian never knew any privileged passwords, and his time on the terminal was quite limited; he just had enough time to put in the trap door and cover up his traces before the owner got back from the bathroom. I fixed this on the aforementioned OS by having a list of directories which could not have their passwords set or modified without a special flag being set in the kernel (the mechanism was kept obscure, of course; it caused great amusement to the systems programmers who stumbled across it but to my knowledge no villians ever found out about it). Any attempt to set or modify a password of one of the special directories would cause a hardcopy log on the system console even if the magic flag was set. Any attempt to set or modify when the when the kernel flag was not set would cause a system error event which made a hardcopy log and a log in the system error event file. This happened no matter what privileges the user had. None of this was bulletproof, but it didn't matter. Most villians don't have access to your hardcopy console log, and this change was never announced. I just starting catching attempts...I also found out who the careless privileged users were. One of them was me. -- Mark -- From: hplabs!gberg@hpindda.hp.com (Greg Berg) 9-Feb-1989 4:57:35 To: misc-security@rutgers.edu Subj: [126] Re: file change program wanted The AT&T toolchest has a program named 'watchit' that can be tailored to execute various alarms on file access/modification. From: 9-Feb-1989 4:57:58 To: security@ubvm Subj: [331] Hard disk protection We are about to install a lab with a number of hard drives that will support training and general student use. When students have access, we would like to make those programs and files used for training to be "locked" in some way. Any suggestions for this. At the moment, there is no networking in- volved with these machines. From: Jim Yang <21117JYY@MSU> 9-Feb-1989 5:12:03 To: Any Subj: [359] Security software for PCs Hello, I need PC software which can grant several passwords for one machine usage. This can be freeware, shareware, or commercial software. If anyone in the net know those kinds of programs, please let me know. Thank you in advance for your help. -Jim BITNET: 21117JYY@MSU.BITNET InterNet: YANG@FRITH.EGR.MSU.EDU From: Tom Dimock 9-Feb-1989 7:17:35 To: security@pyrite.rutgers.edu Subj: [668] Re: Zero knowledge passwords? Russ - The method of authentication described is fairly well known, and is in fact a simplified version of the authentication protocol used by Kerberos. The major change Kerberos makes is that part of the "string to be encrypted" has a defined structure which communicates the privilege being requested. It can be used in a network where all workstations are smart, or where the protocol is supported by a smart card or other external device. The Racal-Guardata RGL 500 Watchword Generator, for example provides a one-way version of this protocol ( it authenticates the user to the host - the user must assume that he/she reached the desired host and not a fake). From: merrill@bucasb.bucasb.bu.edu (John Merrill) 9-Feb-1989 7:32:46 To: misc-security@husc6.harvard.edu Subj: [940] Re: EMP (Electro-Magnetic-Pulse) Luggage scanning. Here's the rub.. Thermal neutrons are easily stopped by materials with high cross-sections like cadmium. So the question arises "Is this TOO easy or am I missing something". You're missing sonething obvious. If a thermal neutron screen were used by itself, then your argument holds. If, however, it is used in conjunction with X-ray screening, then the presence of a large, square, box of metal in the middle of a suitcase will surely raise some eyebrows, won't it? Of course, placing your bomb in the middle of a large vessel of water would have much the same effect...but I think that would be just a little hard to conceal. By contrast, the nitrite sniffers are already known to be relatively easily defeatable. Consider the bombing of the Brighton hotel where the Conservative Party held its 1986 party conference. That hotel was very thoroughly `sniffed' prior to the conference...and a bomb still slipped through. From: Luke OConnor 9-Feb-1989 7:37:37 To: misc-security@watmath.waterloo.edu Subj: [1668] Zero Knowledge Login Procedures There have been several messages that present methods to authenticate the user and the system through a straight forward protocol that involves a few exchanges. I do not challenge their correctness directly, but they do not deserve the title of "zero knowledge". Zero knowledge proofs rely on randomness to provide a small chance of fraud. Let P be the prover and V the verifier. The Prover maintains he has a secret, which only he knows, and can thus identify himself with. The Verifier is to be convinced that P does know this secret. A secret may be the factorisation of a large integer, the discrete log of an integer mod q, or the solution to a problem that is NP-hard. There are others. P and V conduct exchanges, where at the conclusion of the exchanges V is convinced with overwhelming probability that P knows the secret. On the other hand, P has an infinitely small chance of fooling V. Say there are k exchanges. At each exchange, P answers the questions of V. If P knows the secret then P can always answer the questions correctly. If P does not know the secret then there is some chance, say E, that P can guess the correct answer to V's enquiry. P can fool V with probabilty roughly E^-k, which when k is chosen suitably, is next to impossible for P. A zero knowledge proof for quadratic non-residuosity only requires one exchange of k integers. Passwords are easier to guess than the solutions to intractable problems. Passwords are easier to remember than solutions to intractable problems. Zero knowledge proofs are tedious. Their implementation on a smart card is a sensible alternative, allowing two processors to interact. Luke OConnor From: norm@ultra.com (Norm Finn) 9-Feb-1989 7:57:36 To: security@rutgers.edu Subj: [1667] Re: using RSA Cryptographic Algorithm I implemented key generation, encoding/decoding, and primitive key management based on the Rivest, Shamir, and Adleman's MIT/LCS/TM-82 paper and Knuth's Seminumerical Algorithms on Data General 32-bit computers. I wrote an arbitrary-precision integer math package to support it, using o(n**2) multiply and divide algorithms implemented in assembly language. The biggest time-pig is key generation. An essentially random process, it took anywhere from 20 minutes to eight hours to generate a keyset for a 200-(decimal)digit key. 40-digit keys come out in a few seconds to a few minutes. The time was used in going two levels deep in making sure that phi-1 had very large factors. (Or something like that -- it's been four years since I looked at it). Encryption speeds were reasonable for 40-digit keys, but took about 10 seconds per 80 characters for 200-digit keys. The encryption time goes up as the cube of the key length, if I remember correctly. I had to invent a message format, there being no standard. I used a variable-length record format (each record starts with a binary record length) to make it easy to chop up and combine records to accomodate varying key widths. That's where most of my own design effort went. Key management is a pain; who can remember 200-digit keys? I settled for hiding keys behind an XOR mask generated by operating a well-known key upon a user password. The algorithm itself is easy to implement; the paper is very clear. The most time consuming part of the implementation was writing the arithmetic library and the test package to veryify that the library worked in ALL the corners. All-in-all, a fun project. From: GREENY 10-Feb-1989 23:57:36 To: Subj: [247] More on Morris Jr. Anyone who is wondering what Robert Morris, Jr. looks like should have a looksee at Page 66 in Discover Magazine (January 1989 issue)... Bye for now but not for long Greeny BITNET: MISS026@ECNCDC Internet: MISS026%ECNCDC.BITNET@CUNYVM.CUNY.EDU From: J.D. Abolins 11-Feb-1989 0:06:14 To: security@pyrite.rutgers.edu Subj: [1128] Information exchange and security /air safety Today, I read an article in THE JEWISH PRESS (Brooklyn, NY) about EL AL airlines withdrawal of sponsorship from an air safety conference scheduled for next month in Israel. The reason for the withdrawal is reportedly EL AL's concerns that disclosure of its excellent security measures could be obtained and used by hijackers and terrorists. Although the conference organizers promise that the sessions would be closed meetings, the concern still stands. Many Israeli security experts are dsimayed at recent public exhibition of technology available to terrorists. In one such case, a security firm (also scheduled to be a major participant at the conference next month) displayed a booby trapped suitcase and radio tape recorder. Although this and similar displays were intended to emphasize the need for developing better counter-measures, they also can provide useful information to terrorists. Whether it is computer security or airline security, the dilemma of just how much information to share persists. J.D. AbolinsNJ DEP 301 N. Harrison Str. #197or Div. Water Resources Princeton, NJ 08540CN-029 Trenton, NJ 08625 From: brad@uicsgva.csg.uiuc.edu (Brad Schoening) 11-Feb-1989 0:17:37 To: security@rutgers.edu Subj: [833] Re: EMP (Electro-Magnetic-Pulse) Lu There was a report on NPR in early January about the Navy's attempts to run EMP tests. It seems that sometime in the early 80's the navy developed a plan to build a giant EMP generator barge, tow it out into the middle of the Chesapeak Bay near Baltimore and see what the actual effects would be upon an actual destroyer (or similar ship). Two problems developed with this (1) The Chesapeak is the nations most fertile fishing escuary and the Navy had performed *no* tests to determine what the effect of thousands of volts per sq inch would be upon the little fishies (2) the destroyer was to be fully manned - because of course EMP's effects upon the crew would also be important. As I recall, there was such great community opposition to the project that it was eventually canceled. brad schoening schoenin@cs.uiuc.edu From: "Michael J. Chinni, SMCAR_CCS_E" 11-Feb-1989 0:26:11 To: security@pyrite.rutgers.edu Subj: [1742] Re: Burglar tools Hobbit writes Needless to say I don't cotton to this idea -- I love to explore buildings and such, but always have a hard time convincing other people it's harmless and creates no security risk. Comments? You bet. If you think that it's ok to break into a building just to explore, them I suppose you wouldn't mind if you caught someone breaking into your house/apartment just to explore. If you would mind then why is it ok for you but not for anyone else. You may think that this is ok, but I see it as an invasion of the privacy of the building owner (or do you believe that no one has the right to forbid you to explore buildings as you see fit). I believe that what you describe IS a crime. A crime called 'breaking and entering'. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Michael J. Chinni US Army Armament Research, Development, and Engineering Center User to skeleton sitting at cobweb () Picatinny Arsenal, New Jersey and dust covered terminal and desk () ARPA: mchinni@ardec.arpa "System been down long?" () UUCP: ...!uunet!ardec.arpa!mchinni /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ [Obligatory, I suppose, moderator add-on: Most of the MIT buildings I was referring to are open all the time, and people wander through at all hours. Of course this doesn't normally include the HVAC rooms and service shafts and such that the hackers like to get into. Buildings that are genuinely *closed*, like the alumni pool, they do get upset about. In general when one says "exploring buildings", assume he's already *in* the building for a nominally legitimate purpose. In general. Most of the time. _H*] From: Anand Iyengar 14-Feb-1989 10:06:16 To: misc-security@uunet.uu.net Subj: [416] Re: rotating pin locks Sears once sold a "programmable" lock. Insert one key (called the reset key (?) or some such), and twist. Remove it, and insert a second key that you want to use to unlock the door from now on, and the lock's "rekeyed". I don't think that the "reset key" could be re-programmed, which makes the usefullness of the whole system somewhat questionable to me...Anyone have one, and want to comment? Anand. From: stanleyw@dasys1.UUCP (S Wosciechowski) 14-Feb-1989 10:13:51 To: security@pyrite.rutgers.edu Subj: [565] Re: rotating pin locks > After disassmbly, reassembly, and lots of referring to the > medeco diagram, I knew enough to pick the little bugger open. Congratulations. In order to effectively open a Medeco cylinder in under an hour, One must feel the bind on the pins. As you may well be aware, in picking a regular cylinder the bottom pins will not have any pressure on them when the top pins are trapped in the shell. Using this knowledge one can determine if the side bar is binding against the bottom pin in the false notch or other part of the pin and not in its appropriate notch. From: KARYN@nssdca.gsfc.nasa.gov 14-Feb-1989 10:27:35 To: security@rutgers.edu Subj: [727] Computer virus crime I believe that entering another's PC or MAC to place a 'benign' virus there would be akin to breaking and entering, and I also believe that perpetrators should get the same kind of penaltyy. How would you like it if someone got on your directory and renamed all your files? Wouldn't that be something 'benign'? Nothing was destroyed, was it? I am attending (this week) a computer virus symposium, and the first day a Congressman from California spoke about a proposed law, HR 55, which would specifically make it a crime to prance about in others' computer areas, through 'break-in', through a virus, through anything. Also this law would allow civil cases to recover damages from the creator of such an item... karyn From: gwyn@smoke.brl.mil (Doug Gwyn ) 14-Feb-1989 10:39:41 To: misc-security@uunet.uu.net Subj: [966] Re: Friction is your friend > This rather simple idea appears to be out of reach of most locksmiths, > though, who seem to unquestioningly believe the manufacturer's party line... Now, be nice. Most genuine professional locksmiths are well aware of how to attack all kinds of locks. The first step, when feasible, is to gain a thorough understanding of the principles of operation of the lock. Generally from there, along with some experience of picking techniques in general, it is fairly obvious how to attack the lock. For some reason "Cipher" (Simplex) locks are considered secure where I work. It's fun to manipulate them open, and it doesn't generally take more than a couple of minutes once you know how. [Moderator add-on: My impression was always that Cipher locks [electronic, five bidirectional rocker switches in a big klunky box] were different from Simplex locks [all mechanical, five buttons in a column or a circle]. Is there some name crossover or am I confused? _H*] From: "Michael J. Chinni, SMCAR_CCS_E" 14-Feb-1989 11:07:36 To: security@pyrite.rutgers.edu Subj: [5293] Breaking into computers is a crime, pure and simple The following is a reprint (with permission) of an article that appears on the "The Open Channel" page of the Jan. 1989 issue of "Computer" magazine. This magazine is published monthly by the IEEE Computer Society. The article's reprint footnote is as follows: Reprinted from the Los Angeles Times, OpEd page, Sunday, December 4, 1988. At that time Parrish was serving as president of the IEEE Computer Society. The author is Edward A. Parrish Jr., Past President, IEEE Computer Society. The article is titled "Breaking into Computers is a crime, pure and simple". The article is as follows: During the last few years, much has been written to publicize the feats of computer hackers. There was, for example, the popular movie War Games, about a teen-ager who, using his home computer, was able to tap into a military computer network and play games with the heart of the system. The games got out of control when he chose to play "thermonuclear war." The teen-ager, who wa depicted with innocent motives, eventually played a crucial role in solving the problem and averting a real nuclear exchange, in the process emerging as hero. A real-life example in early November involved a so-called computer virus (a self-replicating program spread over computer networks and other media as a prank or act of vandalism), which nearly paralyzed 6,000 military and academic computers. Unfortunately, perhaps because the effect of such "pranks" seems remote to most people, it is tempting to view the hacker as something of a folk hero - a lone individual who, armed with only his own ingenuity, is able to thwart the system. Not enough attention is paid to the real damage that such people can do. But consider the consequences of a similar "prank" perpetrated on our air-traffic control system, or a regional banking system, or a hospital information system. The incident in which an electronic intruder broke into an unclassified Pentagon computer network, altering or destroying some files, caused potentially serious damage. We do not raelly know the full effect of the November virus incident that brought many computers on the Cornell-Stanford network to a ahlt, but credible published estimates of the cost in man-hours and computer time have been in the millions of dollors. The vast majority of professional computer scientists and engineers who design, develop, and use these sophisticated networks are dismayed by this total disregard of ethical practice and forfeiture of professional integrity. Ironically, these hackers are perhaps driven by the same need to explore, to test technical limits that motivates computer professionals; they decompose problems, develop an understanding of them and then overcome them. But apparently not all hackers recognize the difference between penetrating the technical secrets of their own computer and penetrating a network of computers tha belong to others. And therein lies a key distiction between a comuter professional and someone who knows a lot about computers. Clearly a technical degree is no guarantee of ethical behavior. And hackers are not the only ones who abuse the power inherent in their knowledge. What, then, can we do? For one thing, we - the public at large - can raise our own consciousness; Specifically, when someone tampers with soneone else's data or programs, however clever the method, we all need to recognize that such an act is at best irresponcible and very likely criminal. That the offender feels no remorse, or that the virus had unintended consequences, does not change the essential lawlessness of the act, which is in effect breaking-and-entering. And asserting that the act had a salutory outcome, since it lead to stronger safeguards, has no more validity than if the same argument were advanced in defense of any crime. If after experiencing a burglary I purchase a burglar alarm for my house, does that excuse the burglar? Of course not. Any such act should be vigorously prosecuted. On another front, professional societies such as the IEEE Computer Society can take such steps to expel, suspend, or censure as appropriate any member found guilty of such conduct. Finally, accrediting agencies, such as the Computing Sciences Accreditation Board and the Acceditation Board for Engineering and Technology, should more vigorously pursue their standards, which provide for appropriate coverage of ethical and professional conduct in university computer science and computer engineering curriculums. We are well into the information age, a time when the computer is at least as vital to our national health, safety and survival as any other single resource. The public must insist on measures for ensuring comuter security to the same degree as other technologies that are critical to its health and safety. END OF ARTICLE /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Michael J. Chinni US Army Armament Research, Development, and Engineering Center User to skeleton sitting at cobweb () Picatinny Arsenal, New Jersey and dust covered terminal and desk () ARPA: mchinni@ardec.arpa "System been down long?" () UUCP: ...!uunet!ardec.arpa!mchinni /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ From: "Dennis G. Rears (FSAC)" 17-Feb-1989 21:57:53 To: security@pyrite.rutgers.edu Subj: [288] Re: Burglar invitations Phil: It doesn't necessarily show trust. I have them imprinted on some my keys. My post office box keys are an exception. My address is my PO Box and phone number is my work number. If a dishonest person gets my key he can't do anything as my names are not on the keys. Dennis From: Sorrel Jakins 17-Feb-1989 22:21:38 To: Security discussion Subj: [639] Re: Virus-writing I had occasion last month to be involved with a major 'shrink-wrap' product that was infected with nVir. Fortunately, it was discovered right away and the product was withdrawn and destroyed and reshipped. This was a major embarassment for the manufacturer and had a definite 'bottom-line' effect. 'Shrink-wrap' is still the safest way to go, but do not be lulled into a false sense of security.... ------------------------------------------------------------------- Sorrel G Jakins | Bitnet: JAKINS@BYUADMIN Brigham Young University | Internet: JAKINS@admin.byu.edu ICBM: 40 40 W 111 50 N | Bellnet: (801) 378-7130 From: gwyn@smoke.brl.mil (Doug Gwyn ) 18-Feb-1989 20:26:31 To: misc-security@uunet.uu.net Subj: [538] Re: Simplex locks -Yes, but that is because most owners give a simple three digit code for -their lock, and there are only 125 simple three digit codes. You miss the whole point. These locks can be MANIPULATED open, not GUESSED, in very short order. This is not dependent on use of one-digit members of the combination. -Any mathmeticians out there want to compute the number of possible -combinations? As usual, even though this can be done, it is not relevant to security (although it can produce a lower bound for the level of security provided). From: heilpern@tbd.ARPA (Mark A. Heilpern ) 18-Feb-1989 20:51:32 To: misc-security@uunet.uu.net Subj: [760] Re: Friction is your friend >For some reason "Cipher" (Simplex) locks are considered secure where I >work. It's fun to manipulate them open, and it doesn't generally take >more than a couple of minutes once you know how. Yes, but that is because most owners give a simple three digit code for their lock, and there are only 125 simple three digit codes. It is MUCH harder to guess, for example, 1-(2,4)-5, where the 2 and 4 are pressed simultaneously. Or imagine trying to guess (1,3,5)-(2,4)! Any mathmeticians out there want to compute the number of possible combinations? The rules: Each number can only be used once, but may be simultaneously used with any or all other (unused) numbers. The code can be zero numbers, five numbers, or anywhere in between. Happy computing :) From: _David C. Kovar 18-Feb-1989 20:54:45 To: misc-security@rutgers.edu Subj: [1121] Login simulators >Well, to start with, any reasonable system tells you when you get on >when you were last on. The login-simulator doesn't know, and thus >can't tell you. It's very easy to tell when someone last logged into a UNIX or VMS system. At worst, finger the user and grab the line that says "Last logged in at:". There are much more elegant ways. >Better systems (such as Multics) have no way to login-from-within >a-process. Thus the login-simulator can't do anything after it gets >your password but force a logout, since otherwise you'd know immediately So you just give the user a "bad password" message and kick him off. He'll figure that he's typed it wrong, it's been changed by a system administrator, or something similar. Gives you plenty of time to do nasty things. By the by, is it really necessary to take so many cheap shots at UNIX? -David C. Kovar Technical Consultant ARPA: kovar@husc4.harvard.edu Office of Information Technology BITNET: corwin@harvarda.bitnet Harvard University MacNET: DKovar Ma Bell: 617-495-5947 "The difficult we did yesterday, the impossible we're doing now." From: Alex Nishri 21-Feb-1989 11:11:10 To: security@rutgers.edu Subj: [724] Re: Viruses Three copies of a garden variety nVir were included on the "QLTech MEGA-ROM" CD-ROM, Volume 1 October 1988, produced by Quantum Leap Technologies, Inc. This CD-ROM is a collection of public domain and shareware Macintosh software, available for about $35. Quantum Leap Technologies sent a letter out once the virus was discovered, and subsequently released a replacement disc, labelled Volume 2 December 1988. Unfortunately for us here at the University of Toronto Computing Services, the virus had already spread by that point. We know the virus has spread into our University Community, but have no way of estimating how many people were affected. Within the Computing Services itself about twenty machines were hit. From: gwyn@smoke.brl.mil (Doug Gwyn ) 21-Feb-1989 11:22:15 To: misc-security@uunet.uu.net Subj: [769] Re: Sargent & Greenleaf Lock >I was wondering if anyone on the net has had the opportunity >to try and open a S&G lock without the proper combination?? Yes, but S&G make and have made many different locks. Are you talking about one of those chrome padlocks or a vault lock or what? A good safe man can open most models of vault locks via manipulation. There are a few models that are extremely difficult to open without drilling at least an inspection hole. >Does anyone know if the S&G people can open it and reset the >lock to the factory settings then return same to me. They might have some staff who are ABLE to do it, but I doubt they WOULD. Lock manufacturers tend to leave that sort of work to locksmiths. >I came across one in a storage box Use it for a paperweight or something. From: Barry Margolin 21-Feb-1989 11:31:09 To: misc-security@rutgers.edu Subj: [935] Re: Zero knowledge passwords? Actually, Multics does have a form of "login-from-within-a-process". If the login-simulator user has access to open a pseudo-TTY, it could read the user name and password, open a STY, send the login command and password through, and then turn itself into a transparent dial_out session. And if the user doesn't have access to a STY, but does have access to an autocall terminal line, it could do the same thing by dialing out over a phone line. And the same can be done with a network connection. I suspect that most installations allow ordinary users to access at least one of these. The only real protection against a password-stealing Trojan horse is a trusted path. B2 security only requires trusted path for login, so our solution was that a trusted path may be obtained by hanging up and redialing, since dialups always connect you to the standard Answering Service process. barmar From: Lazlo Nibble 21-Feb-1989 11:48:26 To: security@rutgers.edu Subj: [1126] Re: Who *benefits* from viruses? > So, some kind person comes along and starts to distribute a virus. > This makes everyone SO SCARED of accepting a non shrink-wrapped diskette > that the piracy problem just goes away ... It's already happened, at least in the Apple pirate community. Last summer, CyberAIDS and Festering Hate, two Apple //-specific viruses, were released into the pirate community. They were real killers, and Festering Hate is apparently still floating around in some quarters. But even though the pirate community was hit (and hit HARD -- several of the largest pirate BBSes in the country were knocked down before anyone even knew what was happening) things are still trundling happily along today. There are no simple solutions to software piracy. All the ones I've heard that sounded to me like they might work involved measures so draconian that only the most singleminded anti-pirate types would consider them feasable. Nothing short of a complete reprogramming of society's views on WHO OWNS INFORMATION is going to put an end to it, and frankly I don't see that happening in my lifetime . . . laz (cs1552ao@charon.unm.edu) From: Brint Cooper 21-Feb-1989 17:51:09 To: security@pyrite.rutgers.edu Subj: [864] EMP (Electro-Magnetic-Pulse) Luggage scanning. > I think both Sandia Corporation and EG&G were involved in the project, the > results of which are probably classified. The specific results may be classified but only because they predict the vulnerability of US equipment. The phenomenon has been likened to a "super" lightning strike: the flow of very large currents with the expected sorts of damage. The Navy want(s,ed) to build an EMP test facility on the Patuxant River in Maryland. The first time around, they fudged their environmental impact statement. When the environmentalists got ahold of it and held the Navy's feet to the fire, the revised statement admitted that there was some danger to people in aluminum boats or boats with metal masts in the area and that possible damage to fish and other aquatic life was "unknown." So far, the Navy's not building the EMP simulator there. _Brint From: cray%lvvm6.span@sds.sdsc.edu (Robert Cray) 21-Feb-1989 18:11:09 To: security@pyrite.rutgers.edu Subj: [1132] Re: password aging >It seems that the prevailing opinion is that password aging is a complete >waste of time. I think it can be of use it certain circumstances. In theory, I think it is a waste of time, but this assumes that users choose good passwords, and don't share them with others. I know this isn't the case for some of the 600 users at this site, and I don't know what can be done about it. I've just about finished a "set pass" replacement that doesn't accept words in dictionary, etc. but what about the secretaries and word processing people who share their password with everyone in their group? And what about people who choose acronyms, or just plain stupid passwords? We expire every 90 days, so at least it keeps the cycle fairly short. At a university you may be able to say "you chose a stupid password, its your fault you were screwed", but I don't think that washes in the real world. Even backups (which we do daily) aren't good enough - one of the documents our WP people work on has an 8000 page chapter; it wouldn't take much to modify it just enough to look embarassing right before it went to print... --robert