Subject: RISKS DIGEST 14.27 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Weds 13 January 1993 Volume 14 : Issue 27 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Under 50 miles hurts with Hertz [Hertz hat kein Herz?] (Bruce Baker) Re: Computer games may endanger your health (Rick Russell, J. Eric Townsend) Medical Records on smart cards (John Gray) DoJ Has NOT "Authorized" Keystroke Monitoring (Dennis D. Steinauer) More on the Orange Book (Kraig Meyer) Slipstreamed Software Changes, the Titanic, and my Pontiacs [Re: Version Numbers, sort of] (A. Padgett Peterson) Public Service for Cornell Hackers (dclawson) Killing me with kindness [extra MHz] (Bear Giles) Re: name+birthdate=no driver's license (Jim Roberts, Andrew Koenig) Re: Upcoming Telephone Number problems [4 messages, somewhat redundant] (Andrew Klossner, Kraig Meyer, Randal L. Schwartz, Spencer W. Thomas) The RISKS Forum is a moderated digest discussing risks; comp.risks is its undigested Usenet counterpart. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with appropriate, substantive "Subject:" line. Others may be ignored! Contributions will not be ACKed. The load is too great. **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS, especially .UUCP folks. REQUESTS please to RISKS-Request@CSL.SRI.COM. Vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 14, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1". =CarriageReturn; FTPs may differ; UNIX prompts for username, password. For information regarding delivery of RISKS by FAX, phone 310-455-9300 (or send FAX to RISKS at 310-455-2364, or EMail to risks-fax@cv.vortex.com). ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ---------------------------------------------------------------------- Date: 3 Nov 1992 10:48:24 -0800 From: "Bruce Baker" Subject: Under 50 miles hurts with Hertz [Hertz hat kein Herz?] Hertz Rent-A-Car has recently implemented an advanced fuel purchase option. The option permits drivers to pay for gas at the average self service price in the area of the car rental. The option only benefits those drivers who use more than a full tank of gas. Otherwise, you must show your gas receipts upon returning the car, if you claim that you are returning the car with a full tank. An interesting quirk of this system is the programming of the portable check-in palm-top computers used by the attendants who wander along the lanes where you return your car. If you have driven less than 50 miles, the system is programmed to automatically charge you $5.00 for gas, even if you have a receipt showing that you have filled it up. Hmmm... let's see... if the average distance driven by those who have driven less than 50 miles is about 35 miles, that equates to about one gallon of gas for the $5.00 charge (vs. about $1.15 at the tank). Are Ross Perot's gas prices already here? To override the check-out slips provided by the attendants from their palm-tops, you have to take your receipt into the main check-in area. If you're in a hurry, chances are you won't. Then Hertz has the full tank of gas *and* your $5.00. Luckily, my attendant informed me of this quirk. Chalk up another one for American ingenuity! Bruce N. Baker, SRI International [My apologies to Bruce. He sent me this long ago and it slipped through the crack. It should have preceded the first item in RISKS-14.26. PGN] ------------------------------ Date: Tue, 12 Jan 93 20:02:02 CST From: Rick Russell Subject: Re: Computer games may endanger your health (RISKS-14.26) When I read this passage, I knew I'd heard a story somewhere like this before. It turns out the story is in the Nintendo Entertainment System manual! The Super Nintendo Entertainment System "Consumer Information and Precautions Booklet", which comes with SNES and NES systems sold in the US (and the UK, to the best of my knowledge), issues the following warning: EPILEPSY WARNING: READ BEFORE USING YOUR NES OR SUPER NES A very small portion of the population may experience epileptic seizures when viewing certain kinds of flashing lights or patterns that are commonly present in outr daily environment. These persons may experience seizures while watching some kinds of television pictures or playing certain video games. Players who have not had any previous seizures may nonetheless have an undetected epileptic condition. Consult your physician before playing video games if you have an epileptic condition. Consult your physician if you experience any of the following symptoms while playing video games: altered vision, muscle twitching, other involuntary movements, loss of awareness of your surroundings, mental confusion, and/or convulsions. Looks like this British case is another classic version of RTFM! Rick Russell | TAMU Meteorology | wrr3118@tamsun.tamu.edu ------------------------------ Date: 12 Jan 93 14:07:54 From: jet@nas.nasa.gov (J. Eric Townsend) Subject: Re: Computer games may endanger your health (OMJ C-L, RISKS-14.26) Owners of Commodore 64's might remember a program in the C64 Programming manual (I think) which changed the color palette for the text, screen and border as fast as the 64 was capable. There was a warning message to the effect of "don't run this if you or someone in your family has a history of epileptic problems". J. Eric Townsend -- jet@nas.nasa.gov -- 415.604.4311 (DoD# 0378) ------------------------------ Date: Mon, 11 Jan 93 14:09 BST From: John Gray Subject: Medical Records on smart cards Over the holidays, in the "Aberdeen Press and Journal" and its evening equivalent, the "Evening Express", was a description of a trial scheme for holding patients medical records on cards: ... The 750,000 pound patient data-card system is one of the first of its type in Europe, according to one of its pioneering developers, Dr James Beattie. Around 8000 hi-tech cards, the size of a credit card, will be distributed to patients registered with the Inverurie Health Centre. NHS Chief Executive in Scotland, Don Cruickshank, said if it proves successful, the system could become the basis for an all-Scotland one. He said: 'This project has the potential to greatly improve the communication of individual medical histories and to which the individual patients will themselves have access'. Special machines which can read the coded cards will be installed at various points in the North-east. [The article then states that the machines will be installed in the health centre, another doctor's surgery, three outpatients clinics in Aberdeen (for diabetes, asthma and hypertension) and "chemists shops in Inverurie and Kintore"] ... When a patient has treatment from a clinic, their card will note what has happened and course of action taken which will be available to their own doctor much more quickly than at present ", he [Dr Beattie] said. Dr Beattie hopes cards will be distributed in about a years time. The pilot project will run until 1996, when it will be evaluated by health chiefs. [What intrigued me first was the level of security: the Evening Express of the same day was more explicit on some technical details:] Plastic cards which can hold more than 1,000 pages of information on NHS patients... To maintain confidentiality, the cards can be read only by special machines. A portable version will be used by GPs on home visits. Mr Cruickshank said patients will also have access to their own medical records, using number similar to those used for bank cash cards. [It also mentions that half the population will remain as a control group for the study.] Brief note for those not in the UK: The NHS (National Health Service) is an arm of the government which is responsible for the vast majority of medical services in the UK. Thus, perhaps 90+% of the population would be involved if the scheme were implemented nationwide. I'm not going to dwell on why I think this is of interest to Risks, but I'll mention two points: 1) If an entire medical record is stored on card, it will contain a great deal of very confidential information (about as much so as it gets) and a lot of very important information: how secure is a chemist's shop for such a system? Also, such a system on its own would be very vulnerable to card failure. 2) Because the cards are read electronically, there is a risk/benefit in terms of doing computerised card searches remotely (although the article doesn't say the machines will be networked, I can imagine that happening eventually. [I didn't know there were any 750,000 pound patients! Wow. That is really heavy. Somewhat like the seven foot patrolmen I read about last week. PGN] ------------------------------ Date: Mon, 14 Dec 92 17:08:12 EST From: dds@csmes.ncsl.nist.gov (Dennis D. Steinauer) Subject: DoJ Has NOT "Authorized" Keystroke Monitoring Date: Fri, 11 Dec 92 16:14:11 EST >From: dds (Dennis D. Steinauer) To: privacy@cv.vortex.com Subject: DoJ Has NOT "Authorized" Keystroke Monitoring The Subject line on the recent [PRIVACY] reposting by David Banisar of the 7 Dec 92 advisory from CERT/CC is highly misleading and inappropriate. As with some newspapers, it is important that people read more than just the headlines. The Department of Justice hasn't "authorized" anything. Rather, they are advising system administrators that certain activities, namely the monitoring or recording of user-to-computer session transmissions (hence "keystroke monitoring") MAY be found illegal in certain circumstances and that notice should be given to users. The CERT advisory was extracted from a letter to the National Institute of Standards and Technology (NIST) from DoJ. Justice asked NIST in its role of providing computer security guidance to Government to circulate the letter and provide appropriate guidance. We have made the letter available, without comment, through several government and other channels (including CERT, I4, etc.). The letter is intended to advise system administrators of an ambiguity in U.S. law that makes it unclear whether session monitoring, often conducted by system administrators who suspect unauthorized activity, is basically the same as an unauthorized telephone wiretap. I repeat, the law is *unclear* -- and the fact that one can argue either way on the issue does not clarify the law as currently written. DoJ advises, therefore, that if system administrators are conducting session monitoring or anticipate the need for such monitoring, they should ensure that all system users be notified that such monitoring may be undertaken. The DoJ advice, therefore, is not "authorizing" anything -- even implicitly. They have simply observed the types of activities that diligent system managers often undertake (a la Cliff Stoll in "The Cuckoo's Egg") in an attempt to protect their systems from unauthorized users, and they have rendered some prudent legal advice. Clearly, there are lots of issues here -- technical and otherwise -- that will need to be discussed and sorted out. Indeed, changes in agency/organizational policies and even the law are probably needed. However, none of this changes the fact that system administrators need now to be aware of the potential impact of their activities, and the DoJ advice attempts to do this. We (NIST) are developing additional guidance for system administrators to assist them in implementing the DoJ recommendations. I expect that others will be doing likewise. We also hope to encourage discussion of the related technical and other issues. In the meantime, system administrators are well advised to read the basic DoJ advice and examine their systems and agency policies to determine if, where, and how notices should be provided to users. We welcome comments and suggestions, particularly regarding approaches that various organizations take in dealing with this issue. Dennis D. Steinauer, National Institute of Standards and Technology A-216 Technology, Gaithersburg, MD 20899 USA 1-301-975-3359 FAX 1-301-948-0279 DSteinauer@nist.gov (e-mail) NIST Security BBS: 301-948-5717 (cs-bbs.nist.gov) ------------------------------ Date: Mon, 14 Dec 92 09:38:46 PST From: kmeyer@aero.org Subject: More on the Orange Book In response to an article I wrote, W. Murray (WHMurray@DOCKMASTER.NCSC.MIL) cautions against applying the orange book in situations for which it was never intended. While the orange book is not an appropriate criteria for many environments, it is currently the ONLY criteria regularly used in the United States to assess the security features of operating systems--and as such, there is a lot that can be learned from it, even in non-military environments. It is an unfortunate fact that many vendors of commercial operating systems either do not know or do not care about security--the result being that most of us do not have much in the way of security in the computer systems we use every day. If we insist on keeping the bugs of DOS and UNIX for backward compatibility into eternity, we will never have secure systems. Kraig R. Meyer, Trusted Computer Systems Dept, The Aerospace Corp, El Segundo, CA kmeyer@aero.org ------------------------------ Date: Wed, 13 Jan 93 09:24:59 -0500 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Slipstreamed Software Changes, the Titanic, and my Pontiacs Re: Version numbers (Marchant-Shapiro, RISKS-14.26) > ... "Version 6.37a." "Yes, but WHICH version 6.37a...?" Actually this is nothing new. My other hobby is automobiles and we regularly get into arguments as to whether certain options were available, both sides citing references as "proof". A recent case concerned the Pontiac GTO "Judge" in 1970 - for years there had been a rumour of a 455 option that year but all available sales literature showed only a 400 engine. Recently a brochure turned up dated November that looked exactly (same cover artwork and everything as the September issue which is very common). but which did mention a 455 engine option. Turns out that 17 cars were built. Shortly after the Titanic incident, the White Star Line refitted the Olympic with an extensive increase in the double hull coverage also fitted to the third ship in the series (the ill-fated Britannic which incidentally sunk much faster than its sibling), along with a number of other "safety" features. The ones I liked the best were the giant cranes used with rotary lifeboat launchers. Originally billed as being able to launch all boats from either side of the ship, there was one minor difficulty - some of the smokestacks would have had to be jettisoned first. Minor problem. This was also apparently "slipstreamed", at least I never saw a mention of "Triple Screw Steamship Revision A" - but then what can you expect from a company that would add a fourth stack for pure sales appeal (well maybe the cigars in the lounge did need that much ventilation...). The fact is that manufacturers have been quietly fixing products at least since the introduction of mass production and it is always a stressful time for the engineers when the easy changes of development are replaced by the rigorous requirements of configuration control. Sometimes even management is not told about such "fixes", occasionally with disastrous results (it is very easy to remove the motor mounts in one of my cars so that the engine can be raised allowing the spark plugs to be changed. Seems that the power steering was in the way of an air conditioner duct so it was moved just a wee bit 8*). ------------------------------ Date: Wed, 13 Jan 93 09:56:50 -0700 From: dclawson@clipr.colorado.edu Subject: Public Service for Cornell Hackers "Public Service for Hackers" by John Marcham _Cornell_Alumni_News_ magazine Two former [Cornell] students will develop a computer program to make it easier for a quadriplegic man in Tennessee to use a computer he owns, as part of their punishment for launching a computer virus that damaged programs and caused hard drive crashes last February. David Blumenthal '96 and Mark A. Pilgrim '94 were sentenced by a Tompkins County Court judge to pay restitution to users whose computers were jammed by the men's virus, at and near Stanford University and in Japan, and to perform ten hours of community service per week for a year. A computer buff who knew the quadriplegic and heard of the Cornell virus case wrote the judge in Ithaca, and asked if the students' public service could be worked off developing a less expensive and cumbersome program for the disabled man, who uses a mouthstick and outdated software to operate his McIntosh computer. The judge and the former students agreed to the proposal: the students start work in November. A third former student, found guilty of a lesser infraction, was asked by not required to do public service, and declined. ------------------------------ Date: Wed, 13 Jan 93 21:13:49 GMT From: bear@eagle.fsl.noaa.gov (Bear Giles) Subject: Killing me with kindness -- have a (M)Herz? After nearly two _months_ at the integrator to repair a bad motherboard, I finally got my computer back last night (tip 'o the hat to UPS for leaving it outside of my apartment in near-zero (Fahrenheit) weather)... and it still has frequent parity errors. In fact, the problem is worse now than two months ago! A curious fact has come up: I ordered a 20 MHz system, and have an invoice stating they shipped a 20 MHz system, but apparently they actually shipped 25 MHz systems. The manager I talked to claimed he was doing me a "favor" by shipping a better system -- and doesn't seem to understand my statement that I would have refused a 25 MHz system out of concern for unreliability. (When I purchased my system a year ago 16 MHz 386-SXs were standard and 20 MHz systems were just starting to get carried. A 25 MHz would have been first-generation and hence rather unreliable, as my extensive down-time demonstrates). Bear Giles bear@fsl.noaa.gov ------------------------------ Date: Wed, 13 Jan 93 09:51:50 EST From: Jim Roberts Subject: revoke license where i.birthdate=dwi.birthdate and name like "%...%" The RISK of having your licence revoked is greater than merely that of having the same name and birthdate as another person, as discussed in RISKS 14.26 by Bruce Hayden - you need only a *similar* name and birthdate in common. Yesterday I received in the mail from the state of Maryland, in which I live, a notice that my driver's licence is revoked based on a DWI arrest by a person with a similar name in 1985. On all official documents, including driver's licenses, I use my full name William James Roberts. The miscreant with the same birthdate and named James Roberts resided in Florida, a state I have never visited, and was arrested in Tennessee. To have my license reinstated, I must *prove* to the hearing *board* that I am not the DWI James Roberts, something I suspect it will not be easy to do. If one has a real DWI he gets a day in *court*, but if one has merely a computer generated DWI he has no such right. The notice indicated that James Roberts had no sex (sigh), weighed 0 pounds, was 0 ft 0 in in height, and had blank eyes. So the folks who programmed the database join use the fact that the information you are required to have on your driver's license is not useful when they want to roll up the numbers on license revocations. I suspect that if I were Barbara James Roberts (sex:F), I would have gotten the same notice. In that case it might be easier to fight. But what if I were a woman with an ambiguous middle name, say Barbara Kelly Roberts and the revokee were just Kelly Roberts, really a male but to Maryland an M or F? Then I would again be in difficulties. The next step in the widening scope of the database joins may be just to use your birthdate and the Soundex code of your last name. That should considerably improve the numbers achieved by the "responsible" bureaucrats in their hunt for more revocations. Jim Roberts roberts@stsci.edu 6559::roberts ------------------------------ Date: Wed, 13 Jan 93 10:45:55 EST From: ark@europa.att.com (Andrew Koenig) Subject: name+birthdate=no driver's license A common mistake (and sometimes, I suspect, a deliberate decision) in system design is to assume that things that are purportedly the same in theory are actually the same in practice. Thus, for example, politicians who want to prohibit people from using illegal drugs think it is equivalent to punish people who fail drug tests, forgetting that there are sometimes false positives, fraudulently altered results, and so on. So it is with the driving story. Someone else turns up who appears enough like you, at least superficially, and suddenly it's up to you to prove innocence. Here's another example. This was told to me second hand, so I won't swear it's true, but it's plausible enough and the lesson is there anyway. New Jersey, like many (all?) other states, has a mechanism for revoking driver's licenses for various reasons. Moreover, they have laws mandating stiff penalties for people caught driving with a revoked license. But how does one tell if a license has been revoked? New Jersey's answer is to have a list of revoked licenses; their law specifically prohibits driving while one's name is on the revoked list. I know a guy who says his name was placed on the revoked list due to a clerical error. He had not done anything wrong, and had never been informed that his name was on the list. He found out about it when he was stopped for speeding; of course he was immediately charged with driving while on the revoked list. At the hearing, the state readily admitted that his name had been placed there in error. However, they argued that that was irrelevant: the law prohibits driving while one's name is on the list and that's just what he had done. The judge had no option but to find him guilty. ------------------------------ Date: Tue, 12 Jan 93 14:45:31 PST From: andrew@frip.wv.tek.com (Andrew Klossner) Subject: Re: Upcoming Telephone Number problems (Rob Horn, RISKS-14.26) "The change (as I understand it) is that the leading 1 digit should be used ONLY when dialing outside the area code, ... No, the change is that a leading 1 will always be followed by an area code. The old practice of dialing 1-nnn-nnnn to make a long distance call within one's area code is being abolished. This will separate the area code and exchange number spaces, which at present are distinguished by the second digit (0 or 1 for area code, other for exchange). This is vital because North America has run out of area codes. In Oregon, we will convert to this scheme in July, and we will still use a leading 1 when making toll calls within the area code, but we will have to punch the area code as well. This preserves the characteristic that "a leading 1 means you're paying money," considered desirable. Andrew Klossner andrew@frip.wv.tek.com uunet!tektronix!frip.WV.TEK!andrew ------------------------------ Date: Wed, 13 Jan 93 14:21:05 PST From: kmeyer@aero.org Subject: Upcoming Telephone Number problems You will probably both get dozens of messages about this...anyway: In Risks 14.26, Rob Horn stated that the North American dialing scheme is changing; but in fact, it started changing (at least) 5 or 6 years ago and the dialing scheme is no longer consistent around the country. In the old days, area codes were 3 digits of the pattern x0x or x1x; prefixes (the first 3 digits of a "local" number) could not be either of these patterns. Toll calls within your area code were dialed as 1 + number; toll calls outside of your area code were dialed as 1 + area code + number. When area codes started running out of prefixes, the dialing instructions started changing. I know of three different dialing schemes currently being used in the U.S.: (1) The original scheme, described in the paragraph above, (2) The scheme used in Southern California, in which you do not dial "1" to call a number in your area code (even if it is a toll call) (3) The scheme used in the Detroit area, in which you dial 1 + 313 to place a toll call within your area code. When they start using area codes that don't conform to the x0x or x1x format, any regions still using dialing scheme (1) will have to switch to either scheme (2) or scheme (3). Kraig R. Meyer ------------------------------ Date: Wed, 13 Jan 93 14:31 PST From: merlyn@reed.edu (Randal L. Schwartz) Subject: Re: Upcoming Telephone Number problems (Horn, RISKS-14.26) What's worse is that some areas (like California) have chosen to go strictly with "+1 means area code", while other areas (such as Oregon and Washington) have retained the "+1 means long distance" meaning as well. This gets confusing for computer autodialers, as well as humans. This means that in-area-code-but-long-distance numbers are dialed differently in the two plans: Local, in-area-code: both=xxx-xxxx Local, out-area-code: Oregon=n/a, California=1 yyy xxx-xxxx Long distance, in-area-code: Oregon=1 yyy xxx-xxxx, California: xxx-xxxx Long distance, out-area-code: both=1 yyy xxx-xxxx (Oregon doesn't have any local calls that are in a differing area code.) Blech. Your PUC at work. :-) [Further comments from D King, king@ukulele.reasoning.com.] ------------------------------ Date: Wed, 13 Jan 93 09:49:35 EST From: "Spencer W. Thomas" Subject: Upcoming Telephone Number problems What's happened in 313 is exactly the opposite -- we now have to dial 1-313-xxx-yyyy for calls WITHIN the area code, instead of just dialing 1-xxx-yyyy. This allows them to use the x[01]x prefixes as new exchanges (postpones the need to split the area code by a few years). I hadn't thought of it before, but of course, when this is done everywhere, then it will be possible to use (almost) any 3 digit area code, too. ------------------------------ End of RISKS-FORUM Digest 14.27 ************************