23-Dec-86 23:11:33-PST,18232;000000000000 Mail-From: NEUMANN created at 23-Dec-86 23:10:05 Date: Tue 23 Dec 86 23:10:05-PST From: RISKS FORUM (Peter G. Neumann -- Coordinator) Subject: RISKS DIGEST 4.34 Sender: NEUMANN@CSL.SRI.COM To: RISKS-LIST@CSL.SRI.COM RISKS-LIST: RISKS-FORUM Digest, Tuesday, 23 December 1986 Volume 4 : Issue 34 FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: [HAPPY HOLIDAYS!] Debit cards that don't (Edward M. Embick, PGN) Re: security of magnetic-stripe cards (Henry Spencer) Plug-compatible plugs (Henry Spencer) Runaway Audi 5000 (Mark Brader) Ozone layer (Mark Brader) Another heisenbug (Zhahai Stewart) More "bugs" (Tom Parmenter via Richard Lamson) Computer Malpractice (Dave Platt) Financial Servomechanisms (Brian Randell) 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) (Back issues Vol i Issue j available in CSL.SRI.COM:RISKS-i.j. MAXj: Summary Contents Vol 1: RISKS-1.46; Vol 2: RISKS-2.57; Vol 3: RISKS-3.92.) ---------------------------------------------------------------------- Date: Mon, 22 Dec 86 14:05:59 PST From: Edward M. Embick To: RISKS@CSL.SRI.COM Subject: Debit cards that don't (RISKS-4.32) I, like others, can only guess at the mechanism used to "debit" the card in question. However, it would seem to me that a mechanism so designed would also reread the card to ascertain the debiting action was taken. If not, disconnect! I suspect that the design of the system was made simple and cheap, and the design reviewers committed one of the fundamental analysis flaws that introduces risks to a system. They reviewed the basic design, and assumed that since the device is designed to work that way, that unless it breaks, which will be apparent, it will only fail by misreading the card, which will only happen in an acceptably small number of cases where the call costs more than is on the card. This mindset is the same that most peer groups and outside analysts get after analysing a system for possible fraud or abuse. They tend to profile a community of potential system users and a range of views of the system, and overlook the obvious vulnerability of a new, but in their minds, trusted part of the system, because the card has passed the test and is out of the user's physical control. Ed Embick (the more paths I make, the more paths they break! waaaaaaa....) Computer Sciences Corp. embick@noscvax.UUCP or 4045 Hancock St. {decvax,ihnp4,ucbvax}!sdcsvax!noscvax!embick San Diego, CA 92110 (619) 225-8401 x516 MILNET: EMBICK@NOSC ------------------------------ Date: Tue 23 Dec 86 11:28:58-PST From: Peter G. Neumann Subject: British Telecom Phone Cards (RISKS-4.32) To: RISKS@CSL.SRI.COM I had a call from British Telecom about their Phone Card, but I was not around to receive it. Despite the newspaper story to the contrary, they apparently insist that their Phone Card was not compromised, and that the British Post reporter must have misunderstood what he was told when he described the free-call scam and when he perpetrated his allegedly free calls. Stay tuned, and maybe we'll have more later. Edward Embick points out an intrinsic security vulnerability that results if such a system assumes that WRITES always succeed, so that they don't bother to READ after an attempted (DESTRUCTIVE) WRITE to see if the write worked. This leaves them open to monster vulnerabilities that sooner or later might be exploited. The speculative list of possible attacks is most interesting, and keeps growing. ------------------------------ From: hplabs!pyramid!utzoo!henry@ucbvax.Berkeley.EDU Date: Mon, 22 Dec 86 18:44:47 pst To: pyramid!CSL.SRI.COM!RISKS Subject: Re: security of magnetic-stripe cards > ... The technology to make mag-stripe credit cards secure against > two of them has existed for almost 15 years... > ... The checksum function is secret... Around this point the alarm bells start ringing. How long will it *stay* secret? Not forever! The safest approach would probably be to burn it into custom hardware at central sites (*not* in each reader, because it's impossible to maintain physical security on thousands of readers) so that programmers don't have routine access to it. Even then it will probably get out eventually, unless you shoot the people who lay out the chips after they finish. The technique *would* be a major short-term obstacle to magstripe fraud. But it would not make magstripe cards permanently secure against fraud; it would stop fraud only for a while, and merely make it harder thereafter. Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry ------------------------------ From: hplabs!pyramid!utzoo!henry@ucbvax.Berkeley.EDU Date: Mon, 22 Dec 86 18:45:20 pst To: pyramid!CSL.SRI.COM!RISKS Subject: Plug-compatible plugs > Someone discovered by accident that the IBM monochrome display adapter will > accept a Token Ring connector cable... > - Why couldn't they have made the token ring connector a different kind than > the monochrome display connector? Did (or should) the hardware design process > include any analysis of its consequences in such conjunctions, given known > human tendencies? It does in other areas. In avionics design, it is normally mandatory that no two functionally-different plugs be physically identical. This is usually achieved by keying systems rather than by a vast inventory of slightly-different connectors, although there are quite a variety used. The crucial difference is that avionics systems are, to some degree, designed around the assumption of imperfect maintenance. The military in particular has to contend with complex systems maintained by ill-trained technicians subject to many distractions (e.g. gas masks, bombs falling nearby, etc.). Unfortunately, the healthy paranoia that this induces in designers doesn't seem to be present in the computer business. Computer systems have been designed around the assumption of perfect maintenance for quite a while, actually. The cables used to connect most disks and tapes to their controllers are physically but not logically symmetrical, with no keying. At least a 180-degree rotation from one end to the other isn't generally destructive, the stuff just doesn't work! Still worse are symmetrical female connectors which plug onto rows of pins protruding from boards: not only is it possible to get the connector on the wrong way, but it is also possible to get it misaligned with the pins, so that some pins stick past, rather than into, the connector. The grid of pins is regular and symmetrical -- they are normally on the 0.1-inch square grid that is standard for all manner of electronic components -- and there often is no housing around them to constrain the plug to fit in only one place. Slightly fattening the plug to prevent pins sticking past it would solve this, but nobody seems to bother. Even some prefabricated sockets which *do* have outer plastic shells are roomy enough that a narrow plug can go in misaligned by one row of pins. (I speak from experience.) The D connectors used since time immemorial for RS232 lines, and increasingly common for all manner of things on personal computers, at least lack these flaws. There is no great mystery about why this stupidity occurs: it's cheap, and nobody can be bothered improving it. The offending connectors are available from a wide variety of competitive sources, and are available in "mass- terminated" forms that can simply be clamped onto flat cable without the expensive and largely manual operation of soldering individual wires into the connector. A grid of pins sticking up from the board is cheaper than a prefabricated connector. It's cheaper to put the pins on the standard grid than on a special one that would interfere with improper connections, and cheaper to buy female connectors that have all holes present rather than having one blocked off for keying. And so forth. Often it's possible to get at least some degree of protection if one tries -- keyed mass- terminated connectors do exist, for example -- but all too often suppliers don't bother. Even something as simple as making one socket male and the other female offers at least slight protection against wrong hookups. Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry ------------------------------ Date: Tue, 23 Dec 86 14:19:42 EST From: mnetor!msb@sq.arpa (Mark Brader) To: RISKS@csl.sri.com Subject: Runaway Audi 5000 The Washington Post article posted by John O. Rutemiller is indeed an interesting response to the original 60 Minutes story, but it does not cover two points mentioned -- though not stressed -- in that original story. 1. One of the drivers who was interviewed after the runaway-accident said that he had *both* feet on the brake. From the pedal sizes as seen on 60 Minutes, it isn't possible to fit both feet on the accelerator. 2. The common description of the accident was that the transmission was shifted out of Park and then the engine ran away. Now, when I shift a car out of Park, I normally step on the brake first or not at all. How come the drivers of runaways are shifting out of Park and *then* stepping on the pedal? Mark Brader utzoo!sq!msb [* New Address! *] ------------------------------ Date: Tue, 23 Dec 86 18:11:28 EST From: mnetor!msb@sq.arpa (Mark Brader) To: risks@csl.sri.com Subject: Ozone layer The delayed discovery of the recent reduction in the atmospheric ozone layer was discussed earlier in RISKS. Readers interested in a 1-page summary of what is now known, and the competing theories, can find this in the January 1987 Scientific American at pages 67-68. Mark Brader ------------------------------ From: gaia!zhahai%ncar.csnet@RELAY.CS.NET (Zhahai Stewart) Date: 23 Dec 86 08:25:06 GMT To: mod-risks%ncar.csnet@RELAY.CS.NET Subject: Another heisenbug If we haven't driven the heisenbugs (bugs that change or disappear under examination) into the ground yet, I will contribute yet another. I once had a simple program which ran (or didn't run) under CP/M on an early microcomputer. Under the debugger, it ran fine, of course. I traced the problem to the following. I had reversed a conditional jump instruction, causing the program to take an early quick exit. Under normal conditions CP/M put the regular return-to-system address on the stack before calling a program, so one could just return for a shortcut exit. Under the debugger, the stack was relocated to just below the program, with nothing in it. Thus the program popped the first two bytes of code as the return address. This turned out to be exactly the address after the misdirected conditional jump - continuing the execution normally and terminating with a more robust method. I was more than usually bemused by this coincidence; it also served as the inspiration for some tricky schemes to thwart disassemblers. Zhahai Stewart {hao | nbires}!gaia!zhahai ------------------------------ Date: Tue, 23 Dec 86 12:23 PST From: Richard Lamson Reply-To: rsl@ELEPHANT-BUTTE.SCRC.Symbolics.COM Subject: More "bugs" To: Risks@SRI-CSL.ARPA Date: Tue, 23 Dec 86 10:06 EST From: Tom Parmenter Here are some alternate attempts. If we just take the -ug words that already exist in American, we get dug - documentation bug fug - bug that causes you to give up (fug it) hug - deadly embrace bug jug - bug that can get you jailed, such as penetrating security or spelling Ada lowercase lug - big, lovable bug (e.g., Unix) mug - bug that drives you to drink pug - bug that makes you want to go in the boxing ring with its author plug - bug that keeps a system going rug - bug that knocks the system flat slug - bug that slows everything down, leaves a trail of slime, and eats up your lettuce smug - bug you can't find snug - bug that you put in for job security tug - bug that you can't forget, no matter how many years ago it was [OK, OK. I think I have to pull the rug out from further contributions, unless they are outstanding. This one gets through because it's Christmas. PGN] ------------------------------ Date: Mon, 22 Dec 86 18:05:41 PST From: dplatt@teknowledge-vaxc.ARPA (Dave Platt) To: risks@csl.sri.com Subject: Computer Malpractice The 1/87 issue of High Technology magazine has a one-page article (p.61) entitled "Safeguarding against computer malpractice". It doesn't go into great detail but is probably worth reading. One point the article's author makes is that the concept of "software malpractice" has evolved fairly recently, and is tied to the transition of SE from a "skilled tradesman" discipline to a "professional" one. ------------------------------ From: Brian Randell Date: Tue, 23 Dec 86 15:43:35 gmt To: RISKS@csl.sri.com Subject: Financial Servomechanisms [We have had various fragments on this before. This one seems to add a little more, but I have not tried to axe out the duplication... PGN] SOFTWARE STRIKES IT RICH (From The Observer, London, 21 December 1986) Computers have produced at least two major crashes on the New York Stock exchange this year, and are set to repeat the process on exchanges around the world, causing wild oscillations in exchange rates. Computer programs in the US are set up to look for discrepancies between the price of a futures contract on a stock index and the price of the stock that makes up the index. When the price falls, the stock price tends to fall more slowly than the futures contract. The programs spot the discrepancy, sell the stocks and buy the futures to make a risk free 'arbitrage' profit. The process is called program trading. It caused a shudder in the Dow Jones Index in March, when a number of futures contracts 'unwound' at once, and again in September, when the index fell 86 points one day and 34 the next. Software company Data Logic has come up with a program which will spot these discrepancies on any index with a futures contract anywhere in the world. The program will also spot discrepancies between the futures contract on the currency the stocks are traded in and the spot and forward rates of that currency. For example, a program on a computer in Chicago - which is the world capital of futures and program trading - could spot discrepancies between UK stock prices and the contract on the Financial Times/Stock Exchange 100 Index. It would sell stock and buy the futures contract, amplifying any fall in the index. This would precipitate a run on sterling, the program would then spot the discrepancy, sell sterling, buy the futures contract and drag the sterling rate further down. The fortunes freed by US banks to play these markets are phenomenal. Wells Fargo Investment Advisors, which ISN'T one of the major players, has $3 billion ([pounds]2 billion) available for arbitrage trading. Morgan Stanley in New York are rumoured to have made more than $1 million on one program during the first half of this year. 'On an average day, around 25-33 per cent of the trading on the big board (at the New York Stock Exchange) is done through programs,' says John Blin, former chief executive of the NYSE. 'But when there is a severe mispricing the volume can exceed 50 per cent, or around 75 million shares.' Regulators at the US Securities and Exchange Commission are trying to cut down the level of program trading by bringing forward the time futures contracts mature to an hour before the exchange closes. The next step for Data Logic is to tie in a market predictor program to the arbirage spotting program. Data Logic's market predictor, ISFX, has been operating in one London bank for most of the year. It uses a database built up from various sources - economists, regression analysis, charts - and weighs these against actuality to predict future movements in the sterling/ dollar spot market. The company has a deal with the bank so it gets a percentage of the profits made from using the program. In the three months since this arrangement was concluded, Data Logic's development costs have been more than covered. The plan is to 'sell' to eight or nine banks in The City, but to tailor it to the individual bank's ethos. But, however much Data Logic tries to deny it, eight or nine ISFX programs built by the same programmers might well simultaneously come to the same conclusion quite often, so precipitating major movements in the exchange rates. If all these programs act simultaneously, and enough cash is freed by the banks for them, then ISFX's prophesies will be self fulfilling, making effective control of exchange rates impossible. The program is now being extended to cover the Deutschmark/dollar markets then to sterling/Deutschmark forward rates and so on. A similar system predicting movements on the gilts and money markets is being developed by software house Dealing Systems. JASON NISSE Brian Randell - Computing Laboratory, University of Newcastle upon Tyne UUCP : !ukc!cheviot!brian JANET : brian@uk.ac.newcastle.cheviot ------------------------------ End of RISKS-FORUM Digest ************************ -------