RISKS-LIST: RISKS-FORUM Digest Thursday, 12 November 1987 Volume 5 : Issue 57 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Mobile Radio Interference With Vehicles (Steve Conklin, Bill Gunshannon) Optimizing for cost savings, not safety (John McLeod) "Welcome To My World", BBC1 Sundays 11PM -- A Review (Martin Smith) Re: A simple application of Murphy's Law (Tape Labels) (Henry Spencer) Overwrite of Tape Data (Ron Heiby) Misplaced trust (B Snow) Bar Codes (Elizabeth D. Zwicky) Password truncation and human interfaces (Theodore Ts'o) Re: UNIX setuid nasty (Geoff, David Phillip Oster) How much physical security? (Martin Ewing, Alex Colvin, Mike Alexander) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM. For Vol i issue j, FTP SRI.COM, CD STRIPE:, GET RISKS-i.j. Volume summaries for each i in max j: (i,j) = (1,46),(2,57),(3,92),(4,97). ---------------------------------------------------------------------- To: KL.SRI.COM!RISKS@uunet.uu.net Subject: Mobile Radio Interference With Vehicles Date: 11 Nov 87 08:47:55 CST (Wed) From: b14!steve@uunet.uu.net (Steve Conklin) My father installed his two meter rig on his new G.M. car three years ago, and every time he would key it to transmit, the engine would die. The engine control computer was rendered useless by the radio frequency field. The reason that the car manufacturers do nothing to fix this is that they have no incentive to do so. The only laws applicable to this situation are the ones concerning how much rf energy gets OUT of the computer in the car. (A related note - this is why when the first P.C.s came out, if you called Big Blue and said that when you turned on your TV/dryer/etc you got garbage characters on the screen, they wouldn't help you, but if you said that every time you turned the system on your neighbor's TV went crazy, they would replace your keyboard, motherboard, and chassis.) My father never found a solution to the problem. Maybe as cellular phones gain in popularity, the auto manufacturers will have an incentive to take steps to prevent rf from affecting their computer systems. This also will become a very important issue when functions other than engine control are taken by the computer. One final issue is that of outside intentional interference. After this happened, my father and I speculated that cars with computer engine control could be disabled from another vehicle by the application of the appropriate frequency of rf energy with a directional antenna. This could be used by law enforcement agencies, or by terrorists wishing to kidnap someone, etc. Steve Conklin, Intergraph Corp., Huntsville, AL 35807, (205) 772-6888 {uunet,ihnp4}!ingr!tesla!steve ------------------------------ Date: 12 Nov 87 15:14:48 GMT To: philabs!gatech!comp-risks@csl.sri.com Subject: Mobile Radio Interference With Vehicles From: bill@trotter.usma.edu (Bill Gunshannon) Organization: US Military Academy, West Point, NY As a curious aside to Leo Schwab's article: A letter was published in an amateur radio oriented magazine called QST a few years back by a ham who tried to install a UHF mobile radio in his newly purchased Japanese import. He too had problems with interference to the electronic ignition in the car. A call to the US Service Representative for the cars manufacturer resulted in a very simple solution to the problem. They told him "don't install the radio in the car". A novel approach to preventing interference. bill gunshannon ------------------------------ Date: Wed, 11 Nov 87 02:12:56 EST From: jm7@pyr.gatech.edu (John McLeod) To: RISKS@kl.sri.com Subject: Optimizing for cost savings, not safety (Re: RISKS-5.56) A brief comment about the cost of items in automobiles. Anything that costs a nickel more per car, and does not affect performance under normal conditions is very likely not to get done, as this will save $50,000 per million cars. The shielding of electronic ignitions and engine performance computers will cost more than a nickel per car, and does not affect performance most of the time. John McLeod VII, Georgia Insitute of Technology, Atlanta Georgia, 30332 uucp: ...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!jm7 ------------------------------ Date: 11 Nov 1987 19:43:33 GMT From: mcvax!minster.york.ac.uk!MartinSm@uunet.UU.NET To: comp-risks@ukc.ac.uk Subject: "Welcome To My World", BBC1 Sundays 11PM -- A Short and General Review The BBC is currently showing a series called "Welcome To My World" which deals with the future of information technology. It covers areas which seem to be relevent to readers of this newsgroup so here is some information on it. It portrays a world, not too far in the future though the exact date is not given, where development of technology has taken place without proper thought and control. Civil liberties are virtually nonexistent. A camera on every street corner watches for crime, dissent or deviation from the "norm". Computers direct almost every aspect of industry, commerce and war. Books are curious collectors items, though knowledge is more widely available - if you can pay for it. The programme is introduced as a fictional documentary, interviews with real and imaginary people are intercut with news footage of fictional events and it presents a very pessimistic view of what life may be like. I have yet to decide whether this is because they sincerely believe it or because it makes more interesting TV. The presenter, Robert Powell, likes to say that his world doesn't have to be ours, if we make the right choices. Extra topicality was gained a fortnight ago when one of the programmes, made months earlier, considered the possibility of a worldwide stock market crash caused by the global computer networks doing the dealing. Impressive pictures of rooms full of cabinets were shown with the implication that there is something intrinsically frightening in having computers handle money. What frightens me is the way people handle it. Another programme dealt with databases and secrecy. In this one a fictional organisation called FREDI (freedom of digital information) hacked a top secret database and released the contents to a public network. Added spice was added by official denials that the database existed. An interesting scene showed the presenter being stopped on the street and made to state his ID number which was then checked on a terminal. Last week a somewhat more unusual topic was chosen and interesting questions were raised. Would artificial intelligence make artists redundant? If a computer produces a work of art who owns it? Should a film director be allowed to electronically recreate actors to get certain scenes how he wants? In conclusion then I do not think that much in this series would be new to readers of this newsgroup but it is being shown on BBC1 with a potential audience of millions. It does go out at 11PM on Sundays but I can't be the only viewer! Even though I do not agree with the viewpoint of this programme I regard it as one of the more thought provoking things to hit the small screen recently. Martin Smith Langwith College, University Of York, Heslington, York YO1 5DD England. ------------------------------ From: decvax!utzoo!henry@ucbvax.Berkeley.EDU Date: Tue, 10 Nov 87 00:26:42 est To: ucbvax!KL.SRI.COM!RISKS Subject: Re: A simple application of Murphy's Law (Tape Labels) > ...When > you attempt to overwrite a labeled tape on our system an operator message > appears asking if you really want to write to the tape. The operator must > have answered yes to this question... > This is of course an example of the seeing, hearing, reading what you expect > to see, hear or read rather than what is actually there. There appears to be > nothing that you can do to prevent this kind of error... Actually, no, there are things that can be done to prevent this kind of error. I don't think you have diagnosed it quite correctly. I strongly suspect that the operator saw the question and understood it, but that he/she sees that question a dozen times a day, and the normal answer has become a reflex. *That* behavior is fully predictable and a conscientious interface designer will avoid such situations. "Do you really want to do this?" is a question that should never be asked unless there is truly a good chance that the answer will be "no". Note also that the question was directed to the wrong person: the operator, who probably doesn't know enough about the work to judge whether the request is a reasonable one. Since the system insists on asking him/her questions that would require considerable investigation to answer intelligently, the questions will quite predictably be answered unintelligently. It is not unreasonable to request manual intervention when major data destruction is requested, but it *is* unreasonable to place the decision in the hands of someone who gets paid for throughput, not thought. Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry ------------------------------ To: bellcore!ulysses!clyde!comp-risks@rutgers.EDU From: gatech!mcdchg!heiby@RUTGERS.EDU (Ron Heiby) Subject: Overwrite of Tape Data Date: 11 Nov 87 16:23:44 GMT Organization: Motorola Microcomputer, Schaumburg, IL About ten years ago, I was doing some work where I had quite a few reels of tape (and very little disk space by today's standards). Also, I was working in an environment where I couldn't trust the operators to *not* insert write-enable rings in my tapes. I also couldn't trust them not to mount my tapes in response to a tape request from another user. The information on the tapes contained my master databases and selected subsets which were monetarily expensive to re-derive from the masters, as I had to pay for my resource usage. After being burned once, and losing a tape full of subsets, I ran across a tape accessory in a computer supply catalog called "write protect rings". These were thin rings of red plastic that were to be inserted into the write enable ring slot. The idea was that they would interfere with the ability to insert the write enable ring into the tape, yet would not activate the switch in the tape drive, themselves. These worked quite well for me and I had no further incidents. I took a peek at the November Inmac (major computer accessory distributer) catalog and did not find these rings. Now, I can't recall from whom I purchased them. These "write protect" rings still wouldn't stop an operator who was determined to put a write ring in, as they were removable (with a screwdriver or an overpriced "removal tool" sold by the same company). However, the operator would have to go to some fairly extreme lengths. That, coupled with a label threatening the loss of certain body parts if a write ring were inserted in the tape would probably deter just about anybody. A similar approach could be used with the newer tape cartridges. I'm currently using 3M DC600A cartridges, and they have a rotatable write protect "notch". A sticky red label could be placed over the turning slot to help provide cues that it would be a big mistake to write on the tape. Ron Heiby, heiby@mcdchg.UUCP Moderator: comp.newprod & comp.unix ------------------------------ Date: Wed, 11 Nov 87 12:54 EST From: BSnow@DOCKMASTER.ARPA Subject: Misplaced trust [Banned AIDS?] To: risks@csl.sri.com An entertaining quote from the Washington Post of November 10, 1987. It is from a front page story on Idaho's drive to stop AIDS. "Doctors, hospitals, and laboratories would be legally required to report the name and address of anyone who tests positive, information that would be kept in a locked file and on COMPUTER." (emphasis added) ------------------------------ To: bellcore!ulysses!cbosgd!comp-risks@rutgers.EDU From: zwicky@ptero.cis.ohio-state.edu (Elizabeth D. Zwicky) Subject: Bar Codes Date: 10 Nov 87 04:51:57 GMT >Bruce N. Baker > The bar codes are identical ... When you were comparing bar codes, did you actually compare bars, or only the numbers across the bottom? UPC *does* encode more numbers than the ones shown on the bottom; usually two digits, used for check digits. This is because in UPC there are four ways to encode a digit, left or right, and odd or even; the left and right ones are used to tell you whether you read the barcode forwards or backwards, but the odd/even distinction gives a meta-code. That is, every time you read a character you have four facts about it: 1) what number it was 2) whether it was right or left 3) whether it was odd or even. The pattern of odds and evens can encode a digit. I suppose that if you knew in advance what orientation the barcode would come by in you could probably use the pattern of rights and lefts to encode another digit. 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. Of course, they could be doing something even simpler, like printing a number that is not the number encoded in the barcode above. This would probably be easier to see with the naked eye, though. Elizabeth Zwicky, The Ohio State University Dept of Computer and Information Science ------------------------------ Date: Tue, 10 Nov 87 00:28:59 EST From: Theodore Ts'o To: imagen!geof@decwrl.dec.com Cc: risks@csl.sri.com Subject: Password truncation and human interfaces 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. - Ted ------------------------------ From: munnari!elecvax.oz.au!geoffw@uunet.UU.NET Date: Thu, 12 Nov 87 17:01:26 EST To: risks@csl.sri.com Cc: peteri@uunet.UU.NET, davec@uunet.UU.NET Subject: Re: UNIX setuid nasty -- Watch your pathnames Sydney Uni's fate might be seen as an example of the risk taken when an originally distributed function is centralised. In the original give system developed at UNSW, each class instals a copy of the give/take pair. The second of these is setuid to the class account and constructs the destination pathname from entirely validated components: the class directory, assignment name and login name. The former are compiled into the program while the last is extracted from the password file. The purpose of give is to collect the student submission only. Now the modifications made at SU removed the responsibility for determining the target from the relative safety of take to the total insecurity of give, while at the same time increasing the destructive power of take. No wonder they got into trouble. ------------------------------ To: comp-risks@ucbvax.Berkeley.EDU From: oster%dewey.soe.Berkeley.EDU@Berkeley.EDU (David Phillip Oster) Subject: UNIX setuid stupidity Date: 6 Nov 87 20:08:36 GMT Organization: School of Education, UC-Berkeley munnari!basser.cs.su.oz.au!steve@uunet.UU.NET (Stephen Russell) describes a problem that happened to him as a result of a fundametal misunderstanding he has about the way the Unix security system works. His misunderstanding is so fundamental that he completely misanalyzed his problem and the moral that should be drawn from it. He describes a task: He needed a program that would copy a file owned by a student into a directory owned by a teacher. The correct solution is: If the file has read access to all, then the teacher, himself, could copy the file to his directory. Unix has a mechanism called setuid (it stands for "set user id") that lets a user authorize a program to act as the user's agent. The teacher can write a program to act as teacher's agent. The student can run it, and the file gets copied. Mr. Russell made two mistakes. 1.) He made his program setuid "root" instead of setuid teacher. As a result, the program let students copy into any place, not just those places that the teacher was allowed to. This means that the damage caused by his second mistake was not contained by the Unix protection system. 2.) When you make a program "setuid" you are giving the program the ability to act in your name. That means that the program must check, just as you would, that it is performing a legal act. Mr. Russell kindly explained that he got this part wrong. Now, all of the above works only if the teacher can read the student's file. We need some way of arranging for the teacher to be able to read it but not the other students. Unix also has a mechanism for doing this. A "group" on unix is a list of users. Each file has both a user id and a group id, and both user and group permissions. It is quite reasonable to have a separate group for each student<->teacher pair. If a student wants to give a copy of a file to a teacher, he runs a program that: 1.) changes the group of the file to the student<->teacher group, 2.) runs a setuid="teacher" program to copy the file to the teacher's directory. 3.) changes the group of the file back. Now, if you have M students and N teachers, this means you need M*N groups. Groups in turn are defined in a sequentially read text file, owned by root. One can argue that having all these predefined groups would make the system slow, but you can use a small, simple setuid=root program to dynamically create a group with just the membership it needs, use it long enough to do the copy, then destroy the group again. The whole thing could almost be packaged as a standard utility for user A to give copies of his files to user B. User A would run such a program to give a file to user B. It would or would not do the copy based on its execution of a set of rules, written by user B, defining the circumstances that must be true for B to accept A's file. (For example: "must be smaller than 100k, must leave at least 1Meg free space on disk, must not clobber any file already owned by B.") The problem with such a packaged utility is coming up with a reasonable language for user B to express under what conditions he would be willing to recieve files. Now, why do I need to say this? Why wasn't this all obvious to Mr. Russell? All of this is implied by the standard Unix manuals. Perhaps there should be some test you must pass before they let you have the root password. --- David Phillip Oster --A Sun 3/60 makes a poor Macintosh II. Arpa: oster@dewey.soe.berkeley.edu --A Macintosh II makes a poor Sun 3/60. Uucp: {uwvax,decvax,ihnp4}!ucbvax!oster%dewey.soe.berkeley.edu ------------------------------ Date: Sat, 24 Oct 87 01:59:00 PDT From: mse%Phobos.Caltech.Edu@DEImos.Caltech.Edu (Martin Ewing) Subject: How much physical security? (Re: RISKS-5.48) To: risks%Phobos.Caltech.Edu@DEImos.Caltech.Edu In reply to Brent Chapman and PGN on the subject of Computer Center physical security: I also recall the situation at MIT in the early 70's. The key punches and job submission area were on the second floor, while the CPUs were on the "secure" third floor. (The elevator wouldn't stop there.) This worked OK, until Vietnam-related movements escalated. (I was a minor participant.) At that point an actual guard was posted on the first floor, and you had to show ID to go beyond. Expensive, but apparently effective. [The MIT CC was my first introduction to computer bulletin boards. There was a big newsprint pad on the wall, along with felt-tip pens with which to vent your spleen. The pads would disappear after some days and reappear later with Staff's annotations added. Good, appropriate technology.] These days, I have some responsibility for a departmental facility (2 Vax 780s, a Convex C-1). Inside doors are never locked, and an exterior door to a loading dock is only about 6 feet away from the computer room. I don't foresee risks from political protests (astronomy being perceived as benign, I think), but there is always the deranged ex-student or -employee, not to mention old-fashioned vandals off the street. 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? 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. My tentative answer is not to do anything about physical security. The Institute is insured against equipment losses. 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. I'd appreciate comments. Martin Ewing, Caltech Astronomy ------------------------------ Date: Tue, 27 Oct 87 10:21:21 EST From: "Milton A. Colvin" Reply-To: mac3n@babbage.acc.virginia.edu To: cbosgd.uucp!comp-risks@mcnc.org Subject: How much physical security? Organization: University of Virginia > In RISKS-5.45, Brent Chapman (koala!brent@lll-tis.arpa) writes: > >Have there been any cases of terrorist or political attacks on comp centers? At Dartmouth in 1969 the College was closed for a day of political activity. Instead of attacking the computer center, hordes of students headed for the terminals and used the computers to generate mail to Congress. Dartmouth had always made an effort to demystify computers. I have this on hearsay. Perhaps someone who was there could comment. ------------------------------ Date: Fri, 23 Oct 87 17:19:46 EDT From: Mike_Alexander@um.cc.umich.edu To: RISKS@csl.sri.com Subject: How much computer room security? The various storyies in Risks recently about the effects of the student unrest of the 60s and 70s on computer room security remind me of an incident that occured at the University of Michigan during that period. It is somewhat amusing and might be of interest to Risks readers. The University of Michigan was the scene of a number of student demonstrations and other activities (SDS was founded at UM, for example, and it was the site of the first teach-in), although there wasn't much physical damage or other real violence here. One of these incidents involved a small group of students who were attempting to shut down the University by seizing control of the University power plant, an effort that proved ineffective. The incident I have in mind occured during this protest. At the time, the Computing Center was directly across the street from the power plant (which meant we had clean power, by the way). While the students were milling around outside the power plant, a few of them broke off from the main group and headed toward the Computing Center. Since university computing centers elsewhere had been the object of some violence by then, the CC staff members who were watching this were somewhat concerned. However, it turned out that the students were just going to pick up some of their output, not to trash the Computing Center. Fortunately, that was as close as we came to real trouble at the Computing Center during that period. [Thesef last three contributions were backlogged, and reflect old history. Nevertheless I think terrorism and vandalism represent an important area to be aware of, so I dusted them off. PGN] ------------------------------ End of RISKS-FORUM Digest ************************