RISKS-LIST: RISKS-FORUM Digest Monday 18 April 1988 Volume 6 : Issue 64 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Risks of reprogramming keyboards (John Coughlin) Fear of flying? (Daniel B Dobkin) "Flight international" magazine about civil avionics (L. Strigini) Another STARK investigation; faulty simulation implicated? (Jon Jacky) Re: Ethnics and UCB (Bob Ayers) Re: More evidence for an old risk -- Enigma (Henry Spencer) Re: DEC's recent security patch (Darren Griffiths) NY TIMES ARTICLE BY JOHN MARKOFF ON THE LAWRENCE BERKELEY LAB SAGA NOTED IN RISKS-6.63 BY CLIFF STOLL IS IN KL stripe:risks-6.markoff for FTPing. I will RISKS it if the demand is sufficient. But I'll wait a few days to see what else hits... PGN 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 kl.sri.com, get stripe:risks-i.j ... . Volume summaries in (i, max j) = (1,46),(2,57),(3,92),(4,97),(5,85). ---------------------------------------------------------------------- Date: 18 Apr 88 11:21:00 EDT From: John Coughlin Subject: Risks of reprogramming keyboards Last week a user of one of our mainframe systems called me with a couple of problems. She had logged on to a printer terminal to produce a hardcopy of important electronic mail messages. After a couple of messages had printed, garbage characters appeared on her terminal. "Sounds like a problem with flow control, this shouldn't be difficult to set right," I assured her. She then explained that when she later logged on to her CRT, the messages which she has tried to print had been deleted from her email folder. She insisted that she had not typed the DELETE command herself. It was not very likely that some malicious individual had selectively deleted the exact same range of messages which had been displaying, so I was at a loss to explain their disappearance. I was able to restore most of her email from backup tapes, after which I proceeded to investigate her terminal problem. The mainframe she uses recognizes several different flow control algorithms for asynchronous terminals, although DC1/DC3 is the only one honoured under most conditions. The user's hardcopy terminal had a microswitch set to use ACK/ETX protocol, so I switched it to use DC1/DC3. Before I had changed the position of the microswitch the terminal would have been sending ACKs to the mainframe, which would have passed them through to its typeahead buffer. Now, I knew that this user's logon was one of a large group which operate within a more-or-less canned environment. All users within this group share a set of key bindings defined using a program called the Input Manipulation Processor (which is aptly known as IMP for short). I discovered (to my horror) that one such IMP key binding mapped ^F (the ACK character) to the string 'DELETE' followed by a carriage return. So what must have been happening is this: 1. The unfortunate user enters the mail program and directs it to display a range of messages (this also has the effect of selecting them for further operations). 2. At some point the terminal's buffer is getting full, so it ACKs the mainframe to instruct it to stop sending for a while. This ACK is translated to a DELETE command, which is placed into the typeahead buffer for processing. Meanwhile, the mainframe keeps on blasting data at the terminal. 3. The terminal's buffer is overrun, so many characters are lost and garbage is spewed upon the paper. Hidden at the end of this garbled mess is an illegible message informing the user that some of her email messages have been deleted, as "requested". This experience brings to light three RISKS. First, it is risky to set up naive users to have automagical key bindings of which they are unaware. Such users are not likely to understand the possible ramifications under unusual circumstances (or even normal operation). Second, destructive commands, such as deletions not requiring confirmation, should not be bound to 'magic' keystrokes such as PF keys, escape sequences and so on, for *any* user. This just makes it too easy to cause irreversible damage with a typing mistake. Finally, system-defined keystrokes are not a good place to start redefining one's keyboard. Communications control characters (DC1, DC3, ACK, etc.) and interrupt keys (BREAK/ATTN, ^C or ^Y on many systems, etc.) should probably be left alone. ------------------------------ Date: Mon, 18 Apr 88 11:52:56 EST From: Daniel B Dobkin Subject: fear of flying? The following is excerpted, without permission, from the May 1988 issue of "Private Pilot" magazine: The problem of maintenance is sometimes aggravated by the occasional mechanic or technician who doesn't believe that any pilot can report symptoms accurately and therefore ignores whatever the pilot says. I encountered this with an instrument years ago, when the technician flatly refused to believe what the instrument was doing. Instead, he just assumed it was something else for which he performed some unnecessary repair and returned the instrument with the original defect still preseent. This resulted in four separate attempts to correct the malfunction. Admittedly, some pilots are not precise in their reports, an this naturally leads to some degree of skepticism on the mechanic's part, but in most cases a few questions and a little discussion will clarify the uncertainties. The most important way to avoid this trap is to tell the mechanic exactly what you observed, @i{without interpretation}. There's plenty of chance to compare your conclusions with his after he knows what symptoms there are. If you tell a person your conclusion in advance, it can bias and channel his thinking into a particular problem, which may be incorrect and delay the ultimate resolution. This was passed on to me by a friend who reports similar failures of communication between the systems group and the data center operators; he has been awakened at 4:30 too many times by operators who report their analyses of the problem, rather than the clear, concise descriptions he needs. Of course, at that hour he is more likely to follow the operator's erroneous logic at first, thereby prolonging his discomfort; during the day, SOP is to reject the operator's conclusions and attempt to coax him into describing the problem. \dbd ------------------------------ Date: Mon, 18 Apr 88 18:00 SET From: L. Strigini Subject: "Flight international" magazine about civil avionics The April 16 issue of "Flight international" features a 4-page article "Software versus the black box", about current trends in civil avionics (software-based fly-by-wire, etc.). There is much about the A-320 (partially critical: maintainance still difficult, for instance), some discussion of the pros and cons of innovation: e.g. some think multifunctional displays to be difficult to deal with in emergencies, more software in fewer black boxes should simplify maintenance (of the boxes) but increase complexity, etc. On software diversity: comments by several people to the effect that it is possible to build "a lot more" than in the past in software, but "Software risk cannot be quantified in meaningful terms" (attributed to Brian Tucker, GEC Avionics): hence the need to protect oneself somehow. On the other hand, one of the managers in the Airbus program is quoted as saying "Common mode failures are not possible" ("confidently" says the magazine. !!!). Other topics: the huge costs of avionics maintainance and ways to deal with it (redundancy, self-reconfiguration to keep aircraft flying, automated diagnosis to help repair, expert systems - of course); proposals to "increase" airport capacity by better precision in arrival times of flights (computers making sure an aircraft fits exactly in the time slot reserved for it). It may make interesting reading for RISKS readers, in particular because it is written for non-computer specialists with an interest in computer risks. Final quote: "What the airlines want .. is avionics designed for certification and operating profits - a discriminate use of new technology". Worth considering in relation to the recent discussions about responsibility. Lorenzo Strigini ------------------------------ Date: Mon, 18 Apr 88 16:52:15 PDT From: jon@june.cs.washington.edu (Jon Jacky) Subject: Another STARK investigation; faulty simulation implicated? From IEEE INSTITUTE 12(5) May 1988 p. 1: FRIGATE DEFENSE SYSTEM IS INVESTIGATED BY CONGRESS by John A. Adam Apparently unsatisfied by US Navy reports, the Congress is investigating the combat capability of FFG-7 class frigates - those similar to the USS STARK. The STARK failed to deter two Exocet missiles, fired by an Iraqi fighter jet in the Persian Gulf May 17, 1987, that resulted in 37 deaths and more than $100 million in damage to the ship. ... The investigation was requested in November 1987 by Rep. Barbara Boxer (D-Calif), a member of the House Armed Serviced Committee and its investigations subcommittee. ... (Much discussion of weapons systems under investigation...) (Former STARK captain Glenn R.) Brindel told THE INSTITUTE that the Navy combat systems doctrine manual said both the SPS-55 surface search radar and the SPS-49 air search radar should detect Exocets fired from aircraft at ranges over 15 miles. "That is just a bunch of baloney," he added. It gave the persons in the ship's combat information center a false sense of security, he said. The Navy's reported to have found that the capability listed in the manuals, put out by the commanders of the Atlantic or Pacific surace fleets to address the capabilities of each ship class against specific missiles, was "significantly overoptimistic." Boxer's aide says the GAO is investgating how these capabilities are derived. Brindel says much of the data for these manuals is based on simulations. ... The NAVY TIMES, quoting an unnamed source, reported on March 28 that (in a live test) Exocets (obtained for testing) "popped up" and were detected briefly by the frigate's radar while they were at high altitude. But after the missiles swooped low over the wave tops and began homing in on the ships, the frigate was unable to detect them. (This test occured before the STARK attack. Discussion followed of whether the fleet was informed of the test results). - Jonathan Jacky, University of Washington ------------------------------ Date: Mon, 18 Apr 88 09:52:03 PDT From: ayers@src.dec.com (Bob Ayers) Subject: Re: Ethnics and UCB (RISKS-6.63) This is hearsay, so take it with a grain of salt, but I was told by a friend that he started filling the ethnicity slot on forms at UCB with "prussian". This apparently did not default to "white". Of course not. It defaulted to blue. ------------------------------ Date: Mon, 18 Apr 88 06:02:29 EDT From: mnetor!utzoo!henry@uunet.UU.NET Subject: Re: More evidence for an old risk -- Enigma Those interested in this should probably also read Patrick Beesly's book "Very Special Intelligence" (1977). It's the story from the user end: an account of the British Admiralty's Operational Intelligence Centre, which was charged with putting intelligence information together into a useful form for naval operations. In particular, it was effectively the nerve center for the Battle of the Atlantic. It had a dedicated teletype link to the Bletchley Park cryptanalysts. Apart from the inherent interest of the user's-eye view, most of what OIC did is declassified, unlike a lot of the detailed doings of the cryptanalysts. Concerning "probable word" attacks on ciphers, Beesly observes that a possible factor in the success of the cryptanalysts was that situation reports from weather aircraft were often sent to shore in relatively low- security ciphers and then rebroadcast verbatim in the high-security naval ciphers. Later in the war the Admiralty had to make a substantial effort to discourage the RAF from shooting down those aircraft, without revealing why! He also sheds some light on the question of why the cryptanalysis was not discovered. The Germans did persistently suspect either treachery or cryptanalysis. Against the former they took increasingly elaborate precautions. The possibility of the latter was investigated not once but several times. Unfortunately, the investigation was always run by the signals people themselves, and the conclusion invariably was that they were not at fault, i.e. the ciphers were unbreakable. The situation wasn't as obvious as people might think, also. Encryption keys changed daily, and the cryptanalysts were often two or three days behind in finding the new ones. Cryptanalysis was often incomplete. And the Germans used increasingly-elaborate map codes for geographic locations, meaning that a message was often hard to interpret even if cryptanalysis was complete. The result was that OIC had to work hard to put things together with other intelligence reports (e.g. direction-finding and actual sightings), and errors did creep in. These errors showed, and made it harder to see that cryptanalysis was involved. (For the same reasons, Beesly has a low opinion of some of the popular books on wartime cryptanalysis. Some of them make it sound like the Allies knew everything the Germans were doing, and if any Allied ships were lost, it was because of Machiavellian scheming by Allied commanders. Beesly makes it clear that it just wasn't that simple.) A contributing factor may have been something that Beesly mentions as a problem with OIC: because there were few people qualified, cleared, and available to do the work, and the workload was heavy, and the atmosphere was one of constant crisis, nobody ever really got a chance to stand back for a while and think about the deeper implications of events. Nobody was charged with looking for things like signs of hostile cryptanalysis. Only a lucky hunch by a senior man would reveal such a situation. The British got lucky: early in 1943 the head of OIC, Rodger Winn, noted for his lucky hunches, concluded (correctly) that the *Germans* were reading the *Allied* naval ciphers, and made enough of a stink to get things done about it. Evidently none of his German counterparts ever had a similar stroke of insight. Beesly's account also has something to say about the perils of becoming obviously dependent on one information source. OIC had little cryptanalytic intelligence for most of 1942, because the Germans had changed ciphers and the cryptanalysts took a long time to solve the new one. The OIC people decided to try to continue detailed tracking of all U-boats, recognizing that there would be many more errors. Many people thought that this was silly and wasn't going to work. In fact it worked moderately well, and the skeptics were proved wrong, but only because Winn and others insisted that this "obviously" ridiculous scheme was worth trying. Henry Spencer @ U of Toronto Zoology {ihnp4,decvax,uunet!mnetor}!utzoo!henry ------------------------------ Date: Mon, 18 Apr 88 16:42:34 PDT From: dagg@Csa1.LBL.Gov (Darren Griffiths) Subject: Re: DEC's recent security patch This is a follow up to my recent article. In the article I talked about problems with the latest security patch from DEC. In summary the problems were caused by a fix to the TTDRIVER that helped stop trojan horse programs. The fix, in some situations also broke the VAX Workstation Software, stopping uses from autologging into a window. Other things that were broken include programs like PHOTO that use psuedo-terminal drivers to act as session loggers. It seems that some of the programs that use psuedo-terminal drivers will have to be modified before they will be able to work again. This is unfortunate, but it is necessary to provide extra security on VMS systems. I believe DEC is planning to send out a letter describing these problems. The problems with workstation software being broken can easily be fixed. Patches to WTDRIVER.EXE and UISBG.EXE were distributed with the security update, when these patches are installed the workstation software will work as advertised with a secure TTDRIVER. The problem is that the procedure that checks to see if the workstation has VWS installed has a bug in it, and it sometimes reports that the workstation software isn't installed when it is. If this happens the good software won't be installed and things will be broken. The easy fix is to look in the install save set for four images: WTDRIVER031.EXE;1 WTDRIVER032.EXE;1 UISBG031.EXE;8 UISBG032.EXE;1 Take the ones appropiate for your versions and place them in SYS$SYSTEM:WTDRIVER.EXE and SYS$SYSTEM:UISBG.EXE, that should fix things up. I do encourage everyone to install these security fixes. They ARE important and they do help protect your system. DEC has been getting a lot of flames regarding their policy towards security issues, I am not sure that all of these flames are deserved. DEC engineers have spent a lot of time helping find this problem, and they have always been eager to look for problems and suggest solutions. Before we go and flame DEC, why not spend some time flaming the people (pond-scum?) who are trying to break into systems and wasting valuable time and resources. It is people like this who are the true cause of the problem, not companies like DEC. I have heard comments recently that suggest it is the computer manager's responsibility to maintain a secure environment for the users. While this is true it can only be taken so far. It is reasonable to ask home owners to lock their front door when they leave, it is not reasonable to ask them to hire security guards and install a $10,000 alarm system. At the same time it is reasonable to ask computer managers to have a secure environment, it is not reasonable to ask them to spend a good part of their life tracking down idiots who persist on penetrating systems, particularly when the majority of these systems have no useful or interesting information online. --darren ------------------------------ End of RISKS-FORUM Digest ************************