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 1