RISKS-LIST: Risks-Forum Digest Thursday 19 July 2001 Volume 21 : Issue 53 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/21.53.html> and by anonymous ftp at ftp.sri.com, cd risks . Contents: Dashboard can fire water at sleepy drivers (John Arundel) Polarized sunglasses and car LCD displays don't mix (Henry Baker) Missile defense test radar glitch (PGN) Historical Risk: KORD, and N-1 Engine Failures (Ami Abraham Silberman) Software gives erroneous air navigation reading (Bill Hopkins) Even a fatal error can't kill it (Jim Haynes) Gaffe gives away minister's secrets (Paul Cornish) SSL encryption that isn't (Ron) FBI arrests Russian hacker visiting U.S. for alleged DMCA breach (Declan McCullagh) Savings Bank software upgrade goes awry (Jonathan Kamens) Risk when using "Cut and Paste" (Enrique G. Sauer) Re: The computer is taking over the train (Mark Lomas) Re: Unexpected network congestion: remote consequences of Seti@Home (Eric J. Korpela) Re: "It's public data, so why not a public database"? (Geoff Kuenning) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Thu, 19 Jul 2001 16:35:48 +0100 From: John Arundel <johnat_private> Subject: Dashboard can fire water at sleepy drivers Annova notes an IBM system to stop drivers falling asleep at the wheel. It asks you questions and if you fail to respond promptly, it shoots a jet of cold water over you. http://www.ananova.com/news/story/sm_355015.html In the time-honoured phrase, "the RISKS are obvious". I wouldn't like to imagine the consequences if a driver was unexpectedly soaked with ice water during a high-speed overtaking manoeuvure on a motorway... [FORDing the flood? CHEVY to the levee? NOVAcaine mutiny? PGN] ------------------------------ Date: Wed, 18 Jul 2001 19:16:25 -0700 From: Henry Baker <hbaker1at_private> Subject: Polarized sunglasses and car LCD displays don't mix I just got some new (linearly polarized) sunglasses, and got an unpleasant surprise -- I can't read the LCD displays on either my car or my wife's car without cocking my head to one side! On my car, I have to cock my head to one side by about 15 degrees, while with my wife's car I have to cock my head to the other side by about 40 degrees. Luckily, the same angle of cocking seems to work for all of the LCD gauges at the same time. (I just tested my sunglasses on my laptop, and I have to cock my head left by 45 degrees to get the brightest image.) Considering the fact that polarized sunglasses are often better than unpolarized sunglasses, because they do a better job of filtering out glare (highly likely to be polarized), we actually have one safety item interfering with another. Why can't car manufacturers install LCD's in such a manner that the polarization is compatible with polarized sunglasses? Henry Baker <hbaker1at_private> [We all hope you do not go off half-cocked. This reminds us of the problem of pilots on Viagra seeing various colors (including green) as blue. Blue who? PGN] ------------------------------ Date: Tue, 17 Jul 2001 22:16:19 -0700 (PDT) From: "Peter G. Neumann" <neumannat_private> Subject: Missile defense test radar glitch The missile defense test on 14 Jul 2001 was declared a success. However, the Pentagon initially failed to note that the prototype radar had actually indicated that the interceptor had missed the dummy warhead. This omission was considered unimportant because the glitch was a minor computer programming error that could easily be fixed in time for the next test. Is that reassuring to RISKS readers? http://www.latimes.com/news/nationworld/nation/la-071801missile.story ------------------------------ Date: Tue, 17 Jul 2001 10:50:19 -0400 From: Ami Abraham Silberman <silberat_private> Subject: Historical Risk: KORD, and N-1 Engine Failures The following is forwarded with permission of the author, Patrick Flannery <flannerat_private>. It originally appeared in sci.space.history The N-1 was the Soviet equivalent to the U.S. Saturn V, it was to have launched the first Soviet manned lunar missions. It used a cluster of 32 rocket engines on the first stage. To handle automatic shutdown in case of emergency or failure, they used an automatic system named KORD. - Ami Silberman (silberat_private) What KORD was designed to do, and what KORD did, in detail: KORD was designed to shut down a maximum of four motors on the first stage- i.e. two malfunctioning motors, and the two motors 180 degrees opposite of them; and increase burn time of the affected stage to compensate; if more than four motors needed to be shut down, then KORD shuts all motors down.(On the second stage KORD would shut down a maximum of two motors of the eight, in the same way. On the third, four engined stage, only the defective motor was shut down, and the other three gimbaled to compensate.) This would have been good for an on-pad abort during motor startup, and could have saved the rocket.....But: Flight #1 Feb.21,1969- Within seconds of liftoff, two of the first stage motors (#12&24) were shut down erroneously by KORD; the flight continued, but at 66 seconds a Lox line ruptured, starting a fire, and KORD shut the stage down at 70 seconds, and fired the escape tower on the spacecraft successfully! Go KORD! KORD had begun to work it's "special" magic.... Flight #2 July 3rd, 1969- Day of The Big Fireworks- Almost immediately on ignition, motor #8 eats something-a bolt, welding slag, temperature sensor- stories vary; the result doesn't- turbopump blades come flying out of the housing like bullets, and sever electrical lines, and fuel and oxidizer lines on nearby engines, starting a large fire in the base of the first stage. At only a few hundred feet altitude, KORD attempts to shut down all motors...and is 29/30ths successful in this endeavor, leaving one motor running, to neatly tip the booster 90 degrees before impact on, and destruction of, it's launch pad. The escape tower is again fired successfully! Go KORD! Some stories state that another N-1, on the other pad, gets caught in the ensuing explosion's shock waves, and has to be scrapped. Flight #3 June 27,1971- With preternatural cunning, the Soviets have decided that it might be wise to PLAN for having the N-1 fail, and have programmed in a maneuver to get it clear of the launch pad immediately after liftoff- this maneuver is performed- and promptly overstresses the airframe, and control system, causing the rocket to fall apart in midair, and crash- but it does NOT crash on the launchpad- Success! KORD dutifully shuts down the first stage motors... a while after the third stage, and lunar spacecraft assembly, have already fallen off. The escape tower? Comrade, it was a mock-up. Boom. Flight #4 Nov.23, 1973-With an augmented control system to allow it to do the pad clearing maneuver before it explodes, the N-1 once again vaults skyward....and keeps on going! Fifty seconds- all systems go!! 70 seconds-still go!!! 90 seconds- shut down of the center six motors, as planned!!!! 95 seconds- the center six motors are now on fire!!!!! 110 seconds-Boom. But the escape system worked! Go KORD! Later it is discovered that if KORD had shut down the first stage motors when the trouble started, and fired the second stage at that time, then the mission would have reached orbit. Go KORD! This then, was the apex of Soviet 1960's electronic...or at least electric, design- a safety system that both causes, and worsens, disasters. Who says we can learn nothing from Soviet spacecraft design? The KGB wants to know, comrade...who specifically said that; and what's their address? The MITRE Corporation;W078 - C2 Systems Architecture and Integration 12 Christopher Way;Eatontown;New Jersey;07724 (732)578-6645 ------------------------------ Date: Mon, 16 Jul 2001 19:32:50 -0400 From: "Bill Hopkins" <whopkinsat_private> Subject: Software gives erroneous air navigation reading AVweb (www.avweb.com), a news service for general aviation, reported July 9 that the FAA has issued an Emergency Airworthiness Directive (AD) on one model of Apollo NAV/COM (a combined navigation and communication radio) with a specific DSP Software Version Number, because its bearing indication was found to be off by as much as 14 degrees. The Emergency AD prohibits any flight in an aircraft equipped with the radio until it is marked "Use ... for navigation prohibited." The navigation function relies on special ground stations that (simplifying a bunch) transmit a signal that varies the phase of the modulation with azimuth, allowing the radio to infer its bearing from a station within a degree or two. An aircraft flying a circle around a station sees the modulation change smoothly. For many aircraft, this is the primary navigation system when flying by instruments, in clouds. Fifty miles out and 14 degrees off could put you in conflict with FAA airspace rules (bad, takes explaining) or mountains (worse, takes a funeral). In comparison, suddenly not being able to fly by instruments doesn't look so bad. The AD text suggests that some stations do not adhere to the nominal 30 Hz modulation frequency, but the DSP software depends on the assumption that they do. I would guess that bench-testing was done only with nominal generated signals, and certification flight testing (if needed) only with stations that happened to be nominal. So, no problems showed up until a technician happened to test a new installation in the presence of a non-standard signal. Risks: assuming, testing within assumptions, having software in the gauges, etc. Bill Hopkins (whopkinsat_private) [We need a too-fazed commit with 14 degrees of separation. PGN] ------------------------------ Date: Mon, 16 Jul 2001 23:58:01 -0500 (CDT) From: <jhaynesat_private> Subject: Even a fatal error can't kill it or "night of the living dead" I just made an airline reservation using the web page. When I got all the way to the end, having put in the credit card information, it said "Fatal error in backend" and gave an error number and dumped me out. So I assumed (foolish assumption) that the thing had failed and started all over. The second time everything worked as it should. Then I read my email and found I had email confirmations for both of the reservations. So I called the airline and got connected to a tech support person and he said yep, I've got two reservations on the same flight and he would cancel one of them and they would issue a refund to my credit card for it. He said the software is supposed to catch cases of the same person making two reservations on the same flight but in this case that didn't work either. For me, this is a case of deja vu all over again. Some ten or more years ago I reported using an online banking money transfer system where I put in all the data and then the computer voice said "system error, session terminated" So I put the transaction in a few more times over the space of a few days, until I got the normal "data accepted, thank you" message. And soon after got a call from the bank about the account being way overdrawn, because in fact each of the transactions had gone through. No doubt there are other systems out there which have the possibility of completing a transaction and then telling the user that there has been a fatal error. Maybe a whole lot of them. ------------------------------ Date: Tue, 17 Jul 2001 10:03:53 +0000 From: Paul Cornish <paul.cornishat_private> Subject: Gaffe gives away minister's secrets A series of government initiatives have been accidentally made public after the "wrong" version of a speech by cabinet minister Stephen Byers was released. Civil servants unintentionally circulated an electronic copy to interested bodies which can be opened to reveal which passages have been removed or added during drafting. For more information see The Guardian Newspaper, Society Section, Thursday July 12, 2001. http://www.guardian.co.uk/Archive/Article/0,4273,4220335,00.htm Paul Cornish <Paul.cornishat_private> ------------------------------ Date: Tue, 19 Jun 2001 10:02:51 -0400 From: Ron <ron1at_private-abuse.org> Subject: SSL encryption that isn't If you submit your information to an SSL protected web page you're protected, right? Not always. Check the EAA (Experimental Aircraft Association) web page that lets you join online. You can find it at https://secure.eaa.org/EaaJoin/securejoin.html It looks good, and the browser indicates that it's 128-bit encryption. It inspires confidence until you look at the page source. Here's a couple of relevant lines [NOTE: I've modified the Email address to avoid spambots]: form METHOD="POST" ACTION="..\send_email.asp" input type="hidden" name="EMAILTO" value="joineaaat_private" It certainly appears that this 128-bit encrypted SSL form proceeds to send out your sensitive information via Email in cleartext. I verified this by modifying the form to send mail to me. I then tried it. Sure enough, the entire form is sent in clear, including credit card number. [ADDED NOTE, 17 Jul 2001: I notified the site owner at the same time I mailed RISKS. The site is still unchanged. Ron] ------------------------------ Date: Tue, 17 Jul 2001 10:57:48 -0400 From: Declan McCullagh <declanat_private> Subject: FBI arrests Russian hacker visiting U.S. for alleged DMCA breach Russian Adobe Hacker Busted By Declan McCullagh (declanat_private), 17 Jul 2001 http://www.wired.com/news/politics/0,1283,45298,00.html LAS VEGAS -- FBI agents have arrested a Russian programmer for giving away software that removes the restrictions on encrypted Adobe Acrobat files. Dmitry Sklyarov, a lead programmer for Russian software company ElcomSoft, was visiting the United States for the annual Defcon hacker convention, where he gave a talk on the often-flawed security of e-books. This would be the second known prosecution under the criminal sections of the controversial Digital Millennium Copyright Act, (DMCA) which took effect last year and makes it a crime to "manufacture" products that circumvent copy protection safeguards. [...] POLITECH -- Declan McCullagh's politics and technology mailing list You may redistribute this message freely if you include this notice. To subscribe, visit http://www.politechbot.com/info/subscribe.html This message is archived at http://www.politechbot.com/ ------------------------------ Date: Mon, 16 Jul 2001 23:05:46 -0400 From: Jonathan Kamens <jikat_private> Subject: Savings Bank software upgrade goes awry My bank, Peoples Federal Savings Bank in Brighton, Massachusetts, "upgraded" its computer software on the weekend of June 9. No explanation of the purpose of this upgrade or description of the changes customers might see as a result of it was distributed, either before or after the upgrade). The only notice given was a few signs posted at the bank, stating that the bank would be closed over the weekend for the upgrade. To say that the upgrade went poorly would, from my point of view, be a huge understatement. Here's some of what went wrong (but, alas, not all of it; I'm omitting some of the minor screw-ups): * All customers' telephone-banking (TB) PINs were reset as part of the upgrade. As I noted previously, customers were not informed about this in advance. * The new, default TB PIN chosen for all customers is the last four digits of the primary account holder's social security number. I'm sure I don't have to go into how monumentally stupid this is from a security point of view, especially considering that many Massachusetts residents have their social security numbers on their driver's licenses. * Since the upgrade, the TB system tells you to enter the last four digits of your SSN as your PIN if this is your first time using the system, or your the PIN you've selected otherwise. However: * It doesn't make it clear to previous customers of the bank that "the system" means the new TB system after the upgrade, i.e., that PINs set in the old TB system were no longer valid. You just had to figure that out by trial and error. * The system doesn't force you to change your PIN from the default to something else. So the "if this is your first time using the system" prompt is completely wrong, since the PIN will remain the default until you navigate about three levels deep in obscure menus to change it. And I'm sure I don't have to go into how monumentally stupid it is from a security point of view that the system doesn't make people change the default PIN. * When you requested a transfer in the old TB system and it read the information back to you for confirmation before performing the transfer, it read the amount of the transfer first, followed by the account numbers. This is logical, considering that (a) the amount of the transfer is the item most likely to have been entered incorrectly and (b) the account numbers have already been verified as valid by the system. The new system, on the other hand, reads both the "from" and "to" account numbers first, v-e-r-y s-l-o-w-l-y, before reading the amount of the transfer. * The old TB system's transfer confirmation numbers were eight digits long, which was already pushing it. The new system's confirmation numbers are ten digits long. There is no excuse for forcing people to write down random strings of ten digits which could just as easily have been half that length if the UI had been designed properly. * I can no longer access my money market account from SUM ATM machines (see www.sum-atm.com) run by banks other than Peoples. Before the upgrade, my money market account was accessible as my "savings" account from these ATMs. * Before the upgrade my money market account was also accessible as a "savings" account from Peoples ATMs. Now, however, People's ATMs think that my money market account is a "checking" account, which means that I have two checking accounts. Therefore, when I need to access my money market account, I select "checking" and get a menu to choose which checking account I want. The menu looks like this: 1. CHECKING 2. CHECKING That makes it intuitively obvious which one to select, eh? I had to figure out through trial and error that "1" is my old checking account and "2" is my money market account. * That same menu screen tells me to press Enter after using the keypad to indicate which account I want to access. But Enter doesn't work -- it gives the low "error beep." I had to figure out by trial and error that when they say "Enter", what they really mean is "the unlabeled button at the bottom of the column of buttons to the right of the screen." * When I made a deposit shortly after the conversion, the printed receipt for the deposit showed the same amount for both "balance" and "available balance," even though the deposit I had just made was supposed to show up immediately in "available balance" (that's how the system behaved before the upgrade). I complained to the bank about this through their Web site (well, actually, I complained to the bank about *all* the problems listed above, but this is the only one about which they responded), and I got back a pointless E-mail message from the bank's Operations Officer describing to me how the system was supposed to work (which is what I had just described to him in my complaint). I wrote back to him and emphasized again that the system was *not* working that way, and he never responded. However, two days later when I made another deposit, *no* balances showed up on the receipt. Shortly after that, when I made another deposit, the balances were back and the "available balance" correctly reflected the deposit I had just made. So it would seem that the bank is capable of correcting these problems, albeit not acknowledging and apologizing for them. * When my first statement after the upgrade arrived, I saw that I had been charged a $.75 ATM fee, even though I had only used Peoples and SUM ATMs all month, and those are supposed to be free. When I called the bank about this, I was informed that "everyone was charge 75 cents because the upgrade messed everything up," and that the 75 cents would be credited back to my account in my next statement. We'll see. * Before the upgrade, they sent out a final statement under the old system with a closing date of June 8. No interest was paid on that statement. After the upgrade, the next statement they sent out closed on June 30. The interest paid out in that statement correctly covered the period of the previous statement (i.e., they paid about 30 days of interest instead of 22). However, the average daily balance used to calculate the interest payment took into account only daily balances from June 9 through June 30. In other words, the bank underpaid interest to any customers whose average daily balance was higher June 1-8 than it was June 9-30. Of course, conversely, the bank paid extra interest to customers whose averages were lower before the upgrade, but that doesn't help the customers who were underpaid. As I'm sure you can imagine, after this debacle I'm not too keen on continuing to patronize Peoples. However, my fear is that when I look for alternatives, I'm going to discover that there isn't anybody better. Jonathan Kamens ------------------------------ Date: Wed, 18 Jul 2001 10:30:48 +0000 (GMT) From: enrique.g.sauerat_private (esauer) Subject: Risk when using "Cut and Paste" I just became aware of a serious security risk involving the combined use of WinWord and Excel in Office 2000. While writing a report in WinWord, I incorporated a graph generated via Excel via "cut and paste". Later on, using a different computer, I decided to edit the title of the graph by double clicking on it. To my dismay, the *entire* content of the Excel file which was not residing in the computer where I was doing the editing, became available to me. Say you have the unclassified "Graph 1" in sheet 1 of an Excel file and the classified "Graph 2" in sheet 2 of the same file. When you incorporate Graph 1 in the unclassified portion of your report you are inadvertently making Graph 2 available to the user. To avoid this problem use "paste special", you will not be able to edit your graphs by double clicking on it, but you will avoid potentially embarrassing situations. ------------------------------ Date: Tue, 17 Jul 2001 12:39:15 +0100 From: "Mark Lomas" <mark.lomasat_private> Subject: Re: The computer is taking over the train (Cohen, RISKS-21.51) I am reminded of a journey on Thameslink (for those outside the UK, this company runs trains between Bedford and Brighton via London). The driver decided to brake suddenly - I don't know why, however I remember his subsequent announcement to passengers: "You may be wondering why we have to wait here. This train is fitted with a safety system which prevents the driver from accelerating following sudden braking. The computer will give me back control of the train in another minute". This is probably a sensible (but not infallible) safety precaution. Mark Lomas <r21.51@absent-minded.com> ------------------------------ Date: Tue, 19 Jun 2001 18:39:47 -0700 (PDT) From: "Eric J. Korpela" <korpelaat_private> Subject: Re: Unexpected network congestion: remote consequences of Seti@Home > The article closes by saying the problem was "solved" by increasing the > number of available NAT addresses, although of course that didn't fix the > problem, merely caused it to 'go away'. A real solution would be to have the > screen-saver software implement incremental backoff and other mechanisms > designed to gracefully handle a complete loss of remote server access. > > One would hope that the authors of the next generation of distributed > computation applications take heed of the lessons of the current batch. One of the risks of developing any software is that problems experienced by users will be associated with the design of the software, not the failure of other components. The GUI version of SETI@home, upon connection failure, retries the connection twice at 45 second intervals. After the third failure the program waits 60 minutes before retrying. The UNIX version waits 60 minutes between connection failures. Apart from this report, I am unaware of any TCP/IP implementation that is unable to support 3 connection attempts per hour. That each computer involved ended up with 10 NAT translations meant that the router was maintaining NAT translation for failed connections for 120 minutes or more. The router apparently releases translations promptly when connections succeed, but maintains them when connections fail. I'm not sure that the SETI@home software could have anticipated that. There is another possibility. Many SETI@home users use "work unit" caching software to contact the server. We don't have much control over the coding standards used by developers of third party software that interacts with SETI@home. Eric Korpela <SETI@home> ------------------------------ Date: Tue, 17 Jul 2001 14:21:52 -0700 From: Geoff Kuenning <geoffat_private> Subject: Re: "It's public data, so why not a public database"? In the recent flap over 2600/1600 Pennsylvania Avenue, some readers have pointed out: > this kind of database provides publicly available information, so what are > the risks, and why are we running this in RISKS in the first place? PGN's relevance criteria did not slip up on this one. It has often been noted in RISKS that a difference in quality is a difference in kind. In the current example, accessing the information in the databases once required physical travel to a number of different locations, laborious removal of heavy books from shelves, and endless page-turning to locate the desired data. These physical barriers served to winnow out all but the most motivated people, mostly those who had a legitimate need. Placing the same information online, in an easily correlated fashion, has many advantages for legitimate users, not the least of which is the elimination of the necessity of breathing dust. But it also provides new opportunities to the illegitimate. It is suddenly easy to produce lists of property owned by the wealthy, the elderly, or the vulnerable. I am not a criminal, so my creativity in this area is limited. But I recognize that there are new RISKS caused simply by changing the method of access to the database. The foregoing is not intended to be an immovable argument against placing such databases online. We must weigh the advantages against the drawbacks. But it is incorrect to claim that there are no RISKS issues. -- Geoff Kuenning geoffat_private http://www.cs.hmc.edu/~geoff/ In any large population, there are some people who aren't very bright. That's not their fault, it's just in their genes. As an engineer, I have a responsibility to design things that won't kill off the slower ones, just as I have a responsibility to design things that won't harm my neighbor's dog. ------------------------------ Date: 12 Feb 2001 (LAST-MODIFIED) From: RISKS-requestat_private Subject: Abridged info on RISKS (comp.risks) The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Alternatively, via majordomo, SEND DIRECT E-MAIL REQUESTS to <risks-requestat_private> with one-line, SUBSCRIBE (or UNSUBSCRIBE) which now requires confirmation to majordomoat_private (not to risks-owner) [with option of E-mail address if not the same as FROM: on the same line, which requires PGN's intervention -- to block spamming subscriptions, etc.] or INFO [for unabridged version of RISKS information] .MIL users should contact <risks-requestat_private> (Dennis Rears). .UK users should contact <Lindsay.Marshallat_private>. => The INFO file (submissions, default disclaimers, archive sites, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risksat_private with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 20" for volume 20] http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. Lindsay Marshall has also added to the Newcastle catless site a palmtop version of the most recent RISKS issue and a WAP version that works for many but not all telephones: http://catless.ncl.ac.uk/w/r http://the.wiretapped.net/security/info/textfiles/risks-digest/ . http://www.planetmirror.com/pub/risks/ ftp://ftp.planetmirror.com/pub/risks/ ==> PGN's comprehensive historical Illustrative Risks summary of one liners: http://www.csl.sri.com/illustrative.html for browsing, http://www.csl.sri.com/illustrative.pdf or .ps for printing ------------------------------ End of RISKS-FORUM Digest 21.53 ************************
This archive was generated by hypermail 2b30 : Thu Jul 19 2001 - 16:13:27 PDT