RISKS-LIST: RISKS-FORUM Digest Monday 28 August 1989 Volume 9 : Issue 18 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Proposal for SDI software center (Gary Chapman) Computerworld article on high-tech weapons (George Entenman) CHAOSNet used in `SNUFF' snuff (PGN) DMV records, and individual privacy and safety (PGN) Another vehicle guidance system (Pete Lucas) Medics touch computers?!? (Sam Bassett) Unfounded fault-probability claims (Dieter Muller) Lowest-bidder or weak specs? (David A Honig) Automated roads, drive-by-wire, bicycles, and the elderly (PGN) The Guardian vs computer passwords (Brian Foster) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line (otherwise they may be ignored). REQUESTS to RISKS-Request@CSL.SRI.COM. *RISKS NOW ON csl.sri.com. FTPable ARCHIVES ON KL.sri.com UNTIL 4 SEPT 1989.* FOR VOL i ISSUE j, ftp KL.sri.com[CR]login anonymous (ANY NONNULL PASSWORD)[CR] get stripe:risks-i.j ... (OR TRY cd stripe:[CR]get risks-i.j Vol summaries (i.j)=(1.46),(2.57),(3.92),(4.97),(5.85),(6.95),(7.99),(8.88). ---------------------------------------------------------------------- Date: Mon, 28 Aug 89 17:58:15 PDT From: chapman@csli.Stanford.EDU (Gary Chapman) Subject: Proposal for SDI software center This is an item from the newsletter Advanced Military Computing, 8/28/89, p.6: Strategic Defense Initiative managers wrestling with the computer aspects of nuclear war plan to develop a Strategic Defense System software center to meet their application needs. "If there is an Achilles heel to SDI, it is the critique that we can't make all the software work; if we do get it to work, it may not work right; it won't be reliable; and it will cost millions of dollars and comprise millions of lines of code," said Lloyd Acker, associate department head National Testbed Systems for the MITRE Corporation. Acker expects the center to be fully operational by 1991. He said identification of the center's software engineering environment requirements should be completed this year with early prototypes identified and in development. He said the software center, which get off the ground soon, can help reduce SDI software development risks as well as improve software productivity, integrity, integration, security, practices, standards, and training. Acker said the software center would: * Be a training center for software managers and engineers. "A significant turnover in experienced software managerial and engineering personnel can be expected in the next decade, while software engineering practices will undergo rapid change." * Exhibit software engineering environments to include tools supporting methods and standards, and serve as a testbed for SDS software quality. * Be a research center for software technologies suited to the SDS mission. Acker said some of the areas of research include parallel processing, neural networks, object-oriented program- ming, and expert systems. * Track the technology development in other programs that could have an effect on SDI including those of DARPA, NASA, Software Engineering Institute, industry, and academia. * Be a trusted repository for SDS software as it is validated and certified. An early focus will be how to prevent the injection of computer viruses into the system. ------------------ Jeez, where have I heard all this before? I thought this was what the National Test Facility in Colorado Springs was supposed to be doing. Now we're going to build something with an identical mission, a facility which will do world-class research on parallel processing, neural networks, object-oriented programming, and expert systems to boot. Sounds like yet another SDI boondoggle to me. The center will "Be a trusted repository for SDS software as it is validated and certified." How do they expect to do this? "An early focus will be how to prevent the injection of computer viruses into the system." If this center has to be built, it would seem to me that a more reasonable place to start would be to figure out whether the SDI makes any sense at all, or whether it's just a screwball idea designed to "bucket brigade" taxpayer money to defense contractors and think tanks like MITRE. Who cares if there are viruses in something that's not designed to actually "work"? Gary Chapman, Executive Director, Computer Professionals for Social Responsibility ------------------------------ Date: Fri, 25 Aug 89 10:07:11 EDT From: George Entenman Subject: Computerworld article on high-tech weapons Risks readers should be interested in an article in COMPUTERWORLD (August 21, 1989, Vol. XXIII, No. 34, page 1) by James Daly of the CW staff entitled "High-tech weapons, low-tech GIs". The article contains few surprises for readers of this newsgroup, but it neatly summarizes many of the risks associated with computerized weaponry. The article's main thesis: Despite the investment of huge amounts of training time, effort and money, some critics argue that today's super-sophisticated armaments have become so complicated that they have outgrown the ability of sailors and soldiers to use them effectively. It also explains why we may be irrevocably stuck with high-tech weapons: Reports ranging from a B-1 bomber crashing when it hit a pelican to the embarrassing Divad project -- a computer-operated anti-aircraft gun that once identified a rotating latrine fan as the closest threatening target -- have initiated brass-filled investigative hearings.... The trouble is, the military culture may already be too infatuated with leading-edge devices to ever turn back.... [The] Pentagon's electronics procurements have more than tripled since the beginning of the decade and now account for more than 40% of the military's production costs. The Pentagon's "solution": Because the list of the Pentagon's high-tech goof-ups is long, the Defense Department has begun to seriously investigate the use of artificial intelligence. ------------------------------ Date: Thu, 24 Aug 1989 10:44:34 PDT From: Peter Neumann Subject: CHAOSNet used in `SNUFF' snuff Undercover police in San Jose, California, have been tracking BBOARDS for several years, looking for computer users who boasted about their criminal exploits. It was such activity that led them to Virginians Dean Ashley Lambey, 34, and Daniel T. Depew, 28, who have been accused of conspiring to kidnap a young boy to be filmed as they molested him and then killed him. [Source: San Francisco Chronicle, 24 August 1989, article by Tracie L. Thompson] ------------------------------ Date: Sun, 27 Aug 1989 11:30:04 PDT From: Peter Neumann Subject: DMV records, and individual privacy and safety In previous installments in RISKS, we have discussed the relatively open availability of the database of the California Division of Motor Vehicles. In response to the July 18 murder of actress Rebecca Schaeffer by someone who tracked her down through DMV records (via an Arizona private investigator), Gov. George Deukmejian has directed the DMV to restrict release of information, to protect individual privacy and safety. (The DMV had 41 million requests in 1988, mostly seemingly business related.) New rules take place 1 Oct. They require bulk users to register and sign restrictive agreements, and impose a 10-day delay on the response in certain cases. The current practice of notifying the driver when an individual request is made will thus give the driver a little warning before the record is mailed out. (DMV information is all public record info, but the home addresses of certain drivers -- judges, law-enforcement officers, etc. -- are supposedly not released. Whether they are actually on-line but suppressed by the system is another matter.) ------------------------------ Date: Fri, 25 Aug 89 16:16:22 BST From: "Pete Lucas - NERC Computer Services U.K." Subject: Another vehicle guidance system (Pete Lucas) More on vehicle guidance: The following is summarised from an article in 'Personal Computer World' september 1989. A description is given of a system called AUTOGUIDE, being developed by the Transport and Road Research Laboratory (TRRL) near Reading, England. The pilot system uses a digitised map of the area concerned, and a set of 'beacons' (which use an infra-red digital link to inform passing vehicles of their position, and local traffic conditions). Passing vehicles presumably 'poll' the beacons which respond by sending data. Information ('Take the next left', 'Road closed at intersection') is displayed on an alphanumeric LCD display on the vehicle instrument panel. Information from the beacons is relayed back to a central computer which is able to compute vehicle speed by the time taken for individual cars to pass between the beacons. In this way, the central computer can identify congested areas as the congestion develops, and be able to determine alternate routes. Siemens, Logica, GEC and Plessey are all involved in the development of the system, the RAC and AA (both British motoring organisations) are also part of the various consortia doing the development. The British government are currently deciding on which consortium to choose to award the pilot study project to. Initially, around 300 beacons are likely to be needed in an area the size of London, at an estimated cost of 5 to 10 million UK pounds. Possible things to consider as potential risks with such a system:: 1) Such a system COULD be made to identify individual vehicles, hence allowing the authorities to 'track' individuals as they drive around cities. Civil liberties people will no doubt have some comments on this indirect 'electronic tagging'. 2) Since the system can 'divert' traffic, there is a risk that residents who suddenly find a high-speed stream of vehicles diverted down their normally quiet streets and may get somewhat uptight about it. 3) I dont know about the details, but it sounds like such a system could be easily tampered with. Criminals who wished to could, for example, operate a very powerful beacon and create either congestion or open roads to foil police chases. Anyone remember the film 'The Italian Job' in which the robbers crashed a trafficlight computer to cover their escape by creating traffic chaos? 4) Governments/city authorities could 'fiddle' the system to give an unfair advantage to public transport by unethical means - make the roads *APPEAR* more congested whilst creating congestion-free zones for buses. Pete L. ------------------------------ Date: Thu, 24 Aug 89 00:35:11 PDT From: Sam Bassett RCD Subject: Medics touch computers?!? I was a bit astounded by Brint Cooper's story of medical personnel in the hospital he was consulting for being willing to learn the basics of booting and caring for the computers that held their medical database. In my experience, this shows an uncommon amount of good sense on the part of the medical personnel, and a sharp departure from the normal behavior of (non-computer-literate) professionals who use computers. One wonders how many gripes there would have been in the Toronto stock exchange if the stockbrokers had been willing to take a similar interest in the machines on which their living depends. ------------------------------ Date: Thu, 24 Aug 89 12:48:52 MDT From: dworkin@Solbourne.COM (Dieter Muller) Subject: Unfounded fault-probability claims In RISKS 9.17, mentat@walt.cc.utexas.edu (Robert Dorsett) has a gripe with flight automation: * Unfounded fault-probability claims by manufacturer (both in program ver- ification and hardware reliability). This is not necessarily true. Many aircraft manufacturers believe they have a very firm foundation for the reliability of their hardware. One of my former employers leases programs for this very purpose. However, these programs are known to have bugs in sections that ``no one uses'' [read: no one's complained about it being wrong]. Also, in the theoretically working sections, they are using data for components that was out of date 10 years ago. By the way, the justification for all this was that ``the numbers are only used for advertising anyway. No one believes them.'' So, the manufacturers are reporting in good faith what the reliability software tells them, but the software lies. I was amazed to find out this software producer has never been sued as a result of the software's claiming a product would last X amount of time, when the product actually failed much more often. Maybe no one *does* believe the numbers, but it isn't noised about much.... Dieter Muller ------------------------------ Date: Wed, 23 Aug 89 19:37:47 -0700 From: David A Honig Subject: Lowest-bidder or weak specs? I have seen at least two incidences of RISKS contributors decrying the fact that they had to deal with systems provided by a "lowest bidder". It seems to me that if the specifications are complete and correct then there should be no problem. And I cannot think of another decent way to buy systems (the next-to-lowest bidder? the highest bidder?) that will solve the problems. I realize that formal software techniques are considered pie-in-the-sky, and the "iterative design techniques" are what really happens, but isn't the process of analysing and writing specs, and checking that a purchase meets them, a sufficiently important thing? I know it takes more effort to specify what you *really* want and it'll cost more when suppliers give you bids, but at least you're not trusting something you don't want to. [It was of course John Glenn who commented on how he felt knowing that he was astronauting around in something that was built by the lowest bidder. The real problem is the extent to which corners have been cut so that the contractor does not lose money, or indeed tries to maximize profits. If the "ethic" is that anything goes if you can get away with it, then THAT is a problem. If systems are really built to spec, then you should certainly worry whether the spec was adequate. PGN] ------------------------------ Date: Mon, 28 Aug 1989 18:29:24 PDT From: Peter Neumann Subject: Automated roads, drive-by-wire, bicycles, and the elderly RISKS received a huge flurry of stuff as follow-ups on this topic [singular], with considerable overlap, as well as second-order and third-order discussion. I'll try to cull out the highlights. Sorry to you contributors who might have thought there was a big black hole out here where RISKS is supposed to be. By the way, the cutover to the new system and its mailer has improved my life, and has resulted in only a few dropped subscribers. Thanks for your patience. Your underautomated moderator ------------------------------ Date: Fri Aug 25 11:15:15 1989 From: blf@scol.UUCP Subject: The Guardian vs computer passwords The Guardian newspaper (London, U.K.), Thursday 24th August (reprinted without permission). My comments follow. Any errors in the transcription are entirely mine (but the Guardian's reputation for poor proofreading is of no help). - - - - - - - - - - - - - - - - - - - - - - - - - - - A daily changing password is a simple but ridiculously under-used anti-hacker device, argues P. Nath GIVE US THIS DAY ... There is a growing acceptance of the view that little can be done to deter hackers, since they have successfully penetrated so-called secure systems including those of the US and Nato commands. But computer users could take some measures which are ridiculously simple and will only need a couple of minutes each week, to stop more hackers than armies of policeman ever could. These measures could be put into operation immediately and do not involve any new hardware of software. All computer systems allow information to be protected with passwords, but this facility is not properly exploited. To be effective a password should be unguessable and temporary, and yet most passwords are based on names or addresses familiar to the users, and very seldom, if ever changed. It's like hiding the keys of the house under the doormat in the belief that no burglar will be clever enough to discover them. The fact that hackers arrange meetings where they exchange, sell and circulate interresting passwords proves that those passwords are not changed often enough. If passwords are selected carefully and changed every two or three days, even the most experienced hackers will find it impossible to discover them. Although every protection system should be different, some general rules for coining and deploying the passwords can be easily laid down. Perhaps the users may even learn to derive as much thrill in coining un-hackable passwords as hackers noe get in breaking them. Ideally a password should be based on things which are in no way related to the user or his organisation, and the word should be new, pronounceable and easy to remember. The easiest method is to start with common names like Mexico, Dublin, France, Durham, London, Moscow, Cyprus etc, and form new words like Icomex, Lindub, and Cowmos by interchanging their first and second halves. A better group of new words can be made by combining halves of different words; for example Lonlin, Frarus, Mexrus and Mosham. Such words become very easy to remember if a large item is paired with a smaller one, and the two are linked in some way. A better idea is to use two passwords. Easily remember pairs of words may be made up by linking an item with one of its features. For example, the onion domes of Moscow being to mind words like Onimos and Onicow. A pair of words like this can be used interchangeably as passwords, by an individual or a group. Other members of the group will not be inconvenienced, since even the strictest computer system allows two or three attempts to key-in the password correctly. By just typing Onicow as a guess, a user will happen to be right about half the time. If the computer rejects this word, he is sure to gain access by typing Onimos. This tolerant nature of computers is well exploited by hackers, and there is no reason why users should not take advantage of it as well. Computer users suffer from an irrational fear of forgetting their passwords, so they adopt unforgettable names like those of their wives or children, and sometimes their own names. The idea of a password which changes frequently, say once or twice a week, seems like mental torture, but it is not. The underlying rules for such passwords are so simple the once learnt they become very easy to recall. Consider a hypothetical international company and imagine that all its salesmen are enjoying a new year party. All the data concerning products and prices are kepy only in the central computer, the password for which is to be changed every day. The salesmen do not wish to spend more than five minutes to learn the password rules and they insist that no written record of the rules should exist, and that no member should ask or divulge the rules to another member or anyone else. Is it possible for them to invent a totally reliable but unwritten set of rules which will churn out a new password every day? Yes, and the procedure is quite simple and easy to remember. To be chanageable daily the password must be linked in some way to the calendar, but the information has to be coded in such a way that hackers will not be able to crack it in 24 hours. As a starting point take an uncommon three-letter base word, for example, ULM. This leaves room for three letters or digits to codify the date, for example, Sunday, April 30. This day is in the 17th week of the year, is the 120th day of the year, and is 245 days from the end of the year. The password can be any of the following: ULM30S (30th, Sunday) ULM30A (30th, April) ULM304 (30th, April) ULM430 (April, 30th) ULM17S (17th week, April) ULM301 (30th, Sunday) (1=Sun, 2=Mon, 3=Tue etc) ULM125 (difference between 245 and 120) and so on. These passwords may be modified by taking the code letters for days and months from another language (for example, German) or by adding a fixed number to the digits relating to dates and months; or by multiplying these digits by a 2 or 3; or by writing them differently, for example in an octal base. Other combinations can be obtained by putting the calendar information inside the word. ULM30S can be written as UL30SM or U30LMS or U30LSM. Reversing this order provides another set of words. The attraction of such a system is that although the users have to agree on only one of these simple rules and remember it for a year (assuming the system is renewed annually), the hacker will need, if he is very lucky, hundreds of trials to find out how the daily information has been encoded and 24 hours will not be long enough to do this. If by some miracle a hacker breaks the daily code, he still has to discover the fixed letters U L M in their correct order, and this task will need thousands of additional trials. By that time he may decide to give up hacking as a bad job. - - - - - - - - - - - - - - - - - - - - - - - - - - - Whilst this column gives some good advise (e.g., "a password should be unguessable and temporary"), reasonable suggestions for chosing decent passwords (e.g., invention of "Onicow"), and implies other sensible precautions (e.g., no written records or disclosure), it is flawed. Ignoring the factual errors (passwords exist only on MS-DOS via add-on products; ergo, new software and/or hardware may be required), it omits several key points. The most obvious omission, perhaps, is that with the ULM scheme the rules must be changed everytime a salesman leaves the company. (If the information is so valuable to require daily passwords, then it would be unacceptable for any former employee to still efectively know the password.) For the type of company described, this could be rather frequent, presenting the problem of how to distribute the new scheme (which is, quite sensibly, neither written down nor ever divulged). The column also supposes that unauthorised agents (called "hackers", but I refrain from that debate) gain access only by guessing passwords. I suspect that such (random) guessing is the among the rarest attacks. (But the problems with short passwords and restricted alphabets are hinted at.) Assuming that the passwords control the ability to log onto the system (i.e., authenticate system access) then the implication that passwords should be shared (amongst all the salespeople, in the ULM example) is a disaster. Shared passwords imply shared accounts, which frustrates any concept of accountability -- since no one is individually responsible (for a shared account), a breach cannot be traced back (assuming some auditing facilities exist) to an individual person actions or inactions. It is good to see passwords discussed in the mainstream press, and even better when the discussion includes sound instruction. But it unfortunate that the discussion is so flawed that the good points are overlooked. Brian Foster, SCO Trusted UNIX Project, The Santa Cruz Operation, Ltd., London [We have also mentioned in past isseus the risks that the passwords may be stored unencrypted in accessible places, may be transmitted unencrypted via easily readable transmission media, and that passwords are intrinsically vulnerable. But you should not be surprised to see a technical topic mauled in the press... PGN] ------------------------------ End of RISKS-FORUM Digest 9.18 ************************