Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
Computerized voice mail is providing rich opportunities for creative misuse, including the exchange of all sorts of illicit information — credit card numbers, passwords, etc. There is the old tradeoff between easy-to-use short passwords and hard-to-break long passwords. Opting for user friendliness often results in breakability. There is the problem of tracing illegal activities back to the misusers, which appears to be more difficult in voice mail than in the EMAIL counterparts, especially in that voice mailboxes are currently harder for law enforcement agencies to identify. Something like $12 can rent you one for a month. Many familiar problems also exist, such as authentication, integrity of the messages, presence of Trojan horses (e.g., monitoring interesting calls, editing calls), etc. Ain't technology wonderful? [For Bay Area folks, there was a nice front-page article on the subject by John Markoff in the Sunday Examiner and Chronicle, 15 November 1987.]
I sent a more detailed response direct to Hugh Miller, but here is the gist of Capt Brindel's letter to Navy Times. The failure of Stark to defend against the Iraqi Exocets was, according the Capt Brindel, due to the failure of Stark's search radars and EW system to perform as advertised. He asserts that his equipment operators, watch officers, and maintenance techs did their jobs correctly, but the equipment did not do what the FFG-7 Class Combat Systems Doctrine said it could. To address Mr. Miller's question about the Phalanx gun, Capt Brindel said that it was not activated: "The TAO stated that had he received proper indications from either the radars or SLQ-32
Re: How much physical security? (Re: RISKS-5.48)
Rich <RMRichardson.PA@Xerox.COM> 16 Nov 87 15:51:46 PST (Monday)> There is some fractional risk from physical assault. The cost of > significant improvements seems high. The value of the facility, > including data files, is high also. How does one rationally decide > whether the risk is acceptable? > My tentative answer is not to do anything about physical security. > The Institute is insured against equipment losses. This should be taken care of by trading off between investment in security facilities and insurance costs. Is the insurance company astute enough to check your physical security and adjust the premium accordingly? (Is "competent insurance company" an oxymoron? Oh, sorry. :-) Also check the change in probability of loss against losses not covered by insurance (does your insurance cover the cost of lost work while the equipment is being replaced?). How long will it take to get replacement equipment in, up, and running? Do you "lay off" everyone who needs the computer to do their job until you're running again? What is the cost of lost opportunities during the replacement time? Do you lose valuable people because your "slovenly security" is a sign of incompetence? Do you lose valuable people because your "Draconian security" is unendurable? Some thought should expand this list of questions to help you make the decisionSomewhere in the middle of all these factors is a reasonable area to operate. You could even ask your users about this. > The one thing we don't do is to keep copies of valuable files > stored in an independent environment. This can be done for fairly > low cost, although it goes against the grain for researchers to > make backups at all. Since you have a "mainframe" (rather than workstations), it should be much easier to backup your file systems (at least the project and user directories) to mag tape on a weekly basis and take those tapes off site. > As far as I can see the absolute risk from power surges, flooding, > and network breakin is greater. We have had instances of all of these. Are any of these covered by insurance? I'd guess flooding might by and power surges and breakin are not. Power surges can be protected against by equipment and I would think would be worth at least some investment. At the very least, you might save some equipment with a latch that must be reset by hand before re-applying power after an outage. This allows you to bring the system back up in an orderly manner. If you haven't done something about network (or telephone) breakin by now, your case may well be hopeless. :-) Rich
Navy SH-60 Seahawk helicopters
"LT Scott A. Norton, USN" <4526P%NAVPGS.BITNET@wiscvm.wisc.edu> Mon, 16 Nov 87 14:05:58 PSTThe probable reason the Navy required heavier shielding on their version of the SH-60 is that when landing on a ship's flight deck, the aircraft passes right through the main lobe of ship's air search radar(s), about 50 ft from the antenna. The need for shielding is obvious: you stare right down the radar's feed horn as it swings around. LT Scott A. Norton, USN, Naval Postgraduate School, Monterey, CA 93943-5018
UH-60 problems
Peter Ladkin <ladkin@kestrel.ARPA> Mon, 16 Nov 87 17:34:46 PDTOne should note that the problems with the UH-60 are of disputed origin. Aviation Week and Space Technology, Nov 16 1987, p27 , "Army Modifies UH-60s To Cut Electromagnetic Interference in Controls": "Washington - Concern about the vulnerability of the Sikorsky UH-60 Black Hawk helicopter to electromagnetic interference has led the Army to modify its aircraft, but the Army and Sikorsky deny that electromagnetic interference has caused any crashes of the helicopter. [.....]". One should beware of inferring by association, because of its social consequences. A case in point is the V-tail Bonanza, a light aircraft that has been in production for almost forty years. Over the years, a number were lost in unexplained in-flight breakups, some with very experienced pilots at the controls. Beech, for good legal reasons, maintained that the airplane satisfied the requirements of certification, and did not investigate. Apparently the presumption was that if they were to conduct their own tests, this could be used as evidence that they were not completely sure of the airframe quality, in hypothetical litigation proceedings (this is my personal interpretation, as well as that of others). This is not by any means unsound reasoning. They willingly conducted extensive tests when required to do so by the FAA (which seemed in retrospect to be the obvious solution - one can wonder about the FAA's tardiness). Meanwhile, many v-tail owners died. We all suffer from the consequences of this kind of political/legal conundrum, and so one should note that the facts are disputed in the UH-60 case. None of which means that the press is wrong, of course. peter ladkin
External risks (Re: RISKS DIGEST 5.58)
John McLeod <jm7@pyr.gatech.edu> Mon, 16 Nov 87 16:31:47 ESTAnother class of risks to computers is accidents external to the complex. A couple of years age at the University of New Mexico, several of the computers were shut down by a backhoe breaking a large water main on central. The water from the main flooded the steam tunnels while the steam pipes were hot. The temperature in the computer room reached 100F, and the humidity reached 100%. This triggered the shutdown sequence for the computers. However, the air conditioners overloaded when attempting to cool this mess to a suitable temperature. The computers were down for two weeks while new air conditioners were purchased and installed. A few weeks ago here at Georgia Institute of Technology, we had a backhoe break the power cable and the network cables. The computer was down for about 12 hours. JOHN MCLEOD, Georgia Insitute of Technology, Atlanta Georgia, 30332 uucp: ...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!jm7
Re: A simple application of Murphy's Law (Tape Labels)
Barry Gold <lcc.barry@SEAS.UCLA.EDU> Sun, 15 Nov 87 10:46:13 PSTIn designing the "secure" operating system KVM/370, we considered the danger of an operator mounting the wrong tape from a different perspective. In an environment that mixes applications with different classification levels, an operator error can result in the data on a Top Secret tape becoming available to a user who is cleared only to Secret--or in Top Secret data being written on a tape whose external label claims it is "unclassified". We decided to assign a separate "authenticator" to each removable volume (tape OR disk). The design was to work as follows: Every volume, even "foreign" tapes, is assigned a volume id ("name" and/or location when racked) AND a "password". This information is entered in a database, along with the classification level and owner. The "password" is NOT given out, but is written on the tape's external label. When requesting a tape mount, the user specifies the volume id. The operator retrieves the tape (or disk) and gives the system the volume id, the name of the user who is to receive access, and the "password". The system checks that: 1. the "password" is correct for the volume id. 2. the classification level of the tape matches the user's current classification level. (A user cleared to Top Secret can choose to work on the Unclassified subset of his data, but will then not get access to Top Secret tapes!) If either of these checks fails, the operator is prompted to try again. The operator can try again with the same tape (possible typing error) or a different one, or abort the mount request. Note that there's no deep dark secret about the volume's "password". It's just a check that the right tape has been mounted. I think the above scheme would also work to protect against accidental destruction of data in an unclassified environment. Just leave out the classification check. You might or might not get additional protection by adding a check that the user who is to get access is the owner. If not, the USER gets a prompt "do you want to read (viz write on) xxxx's tape?" You could even add a third password that the user gives out to people who should be able to write on that tape. Of course, the operator can always get around these checks by "adding" a new tape and claiming that the tape to be mounted is that tape, or by calling all tapes a certain standard one with a known volume id and password. You need to make sure that operators understand that just ONE use of that facility that results in overwriting the wrong user's tape will get them fired.
EAN and PIN codes
<MAKELA_O%FINJYU.bitnet@csl.sri.com> Mon, 16 Nov 87 10:42 OIn RISKS 5.57 Elizabeth D. Zwicky writes: >To the best of my knowledge, this feature is not used by actual UPC (that >is, in the Uniform Price Code standard), but is used in EAN, the European >standard which uses the same bar codes. If they use the check digits for >something else, then only they will be able to figure out what they are; >anything that reads UPC will reject it, since UPC specifies what the >odd/evens must be, anything that reads EAN will reject it because the check >digits are wrong, and programs that read both will read everything but the >numbers of interest, because they ignore odd vs. even. This is both correct and not. The EAN standards actually comprise of two distinct product coding systems: the EAN-8 and the EAN-13. The EAN-8 is an eight-digit no-frills barcode which is encoded only in the "set A" bars. The EAN-13 comprises of 13 digits (see, we aren't superstitious over here :-) coded into a dual barset of 6 digits each. The 1st digit of the product code is encoded into the usage of "set A" and "set B" bars in the first barset, and the last (13th) digit of the barcode is a checksum from the previous 12 digits. So the EAN-13 barcode looks something like this: !!!!!!!!!!!!!!! !!!!!!!!!!!!!!! !!!!!!!!!!!!!!! 0!123456!789012! With the first "0" being the digit encoded into the A/B bars in the first barset. The second barset does not contain any coded information in the usage of bars, it is done simply in "set C". Why this type of encoding was chosen, beats me! It is however compatible with the american UPC coding, since I once tested a bar code reader program with mixed EAN-codes and UPC-extended codes (you know, the ones you get on book covers with the price on a little extra barset after the main code). Also, in RISKS 5.57 Theodore Ts'o writes: >There is a similar problem with the (Massachusetts) BayBanks teller system: >it truncates your PIN to FOUR numbers (even though they tell you to pick a >PIN between four and six numbers). Yes, it's still there. When (or if) >they will ever fix it is unknown. Can someone out there in netland tell me how the international PIN system works (in principle, I'm not expecting the top secret algorithm :-) ? The cards one gets around here have a 4-digit PIN field in the magnetic stripe plus one digit of "PIN version". The PIN system would seem to me to be a *very* great risk indeed, since as far as I know, the cash registers that can take a PIN code from a keypad instead of having you sign a sales slip ARE NOT CONTROLLED ITEMS, ie. I could just go out and buy one. At least, an organized and determined group of criminals could steal one. I would assume that the part of the cash register that handles PINs works on the "black box" principle, that is you feed in a card number and what was typed on the keypad and it says yes or no. The problem is that a maximum of five digits on the PIN (if we count the "version" in) would give only 100000 possible codes. One would not have to actually reverse-engineer this device (how about calling it a "PIN Black Box" ?), only use it for testing through the possible keys. It's designers would have taken reverse-engineering into account (per the PIN security requirements), but an attack of this type would be very hard to counteract in the design criteria, since the actual Black Box has been obtained, and can be used at leisure for "cracking" card security. On the other hand, a determined person with enough technical skill could most certainly reverse engineer such a device. A public knowledge of the PIN algorithms would make stolen/lost credit cards a real disaster, since most of your money would probably be gone even before you could get to a phone. Comments, anyone ? Otto J. Makela, U of Jyvaskyla, Kauppakatu 1 B 18 SF-40100, Jyvaskyla Finland voice phone: +358 41 613 847 BBS phone: +358 41 211 562
Computerized Fuel Injection (RISKS DIGEST 5.58)
<James_M._Bodwin@um.cc.umich.edu> Mon, 16 Nov 87 11:10:44 ESTIn the mid seventies Volkswagen developed a fuel injection system for all of their vehicles. The system has a logic box that that measures the rate of air flow and then controls valves attached to the injectors in order to obtain the correct air/fuel mix. According to the story I heard, the system worked fine in Europe so they brought a few models over to the US to test out. For some unexplained reason the cars would occasionally stall out completely and fail to restart. Then, a few seconds later (before thgey could even get the hood up) the engine would start working again. This delayed shipment of the cars to the US market. After much head scratching someone finally figured out the problem: CB radio transmissions from nearby cars were inducing enough current in the injector control wires to cause the injectors to malfunction. Of course, the problem went away as soon as the CB stopped transmitting or when the car got a reasonable distance away. The problem was only noticed in the US because of the relatively large numbers of CBs in this country (remember the CB craze in the 70s?). The fix was to shield the control wires. Unfortunately, this was long enough ago that I can't remember my original source for this story nor can I verify its accuracy. I don't know enough about the power or frequencies used by CBs and cellular phones to know whether or not they are significantly different. However, CBs remain popular enough that I'm surprised that the car companies haven't already taken sufficient steps to sheild car electronics from radio transmissions. Or perhaps they just designed them to filter out junk in the CB frequencies.
Re: Password truncation and human interfaces
Franklin Davis <fad@Think.COM> Mon, 16 Nov 87 13:01:36 estMark W. Eichin <eichin@ATHENA.MIT.EDU> writes: What is especially interesting (in the BayBanks case) is that 2) The screens actually flicker visibly once you have pressed the fourth digit, making this feature easy to suspect... In fact, on the newer machines I can't enter my password at my normal rate — the system pauses after the fourth digit, and won't accept the fifth for a moment. A poor interface indeed! --FranklinPlease report problems with the web pages to the maintainer
xTop