----MESSAGE-BEGIN---- <1987010113124100> 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? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987010506092300> 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987010805175300> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987011215501700> 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] ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987011504004800> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987011507375500> 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 :-) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012007062300> 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*] ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012100434900> 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012101204200> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012105352300> 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012206133300> 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012312581900> 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012407050700> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012504204300> 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012509122000> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012614463600> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012812193200> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012902392700> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012909342700> 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012910342700> 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? ----MESSAGE-END----