Subject: RISKS DIGEST 18.58 RISKS-LIST: Risks-Forum Digest Weds 6 November 1996 Volume 18 : Issue 58 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. ***** Contents: 1996 Melbourne Cup off-course betting fiasco (Harley Mackenzie) Fidelity Brokerage computer problems (George C. Kaplan) Bug in the network: a real spider (Nick Brown) Announcement - Warning to Crypto and Banking Communities (Ross Anderson via Bruce Schneider and Monty Solomon) Differential Fault Analysis: a possible defence? (David R Brooks) Ping o'Death from Windows 95 (Nick Brown) Re: Office 97, VBA 5.0, and macro viruses (Otto Stolz) Web search engines find connected components (David Skillicorn) Re: Tote Board Crash at Breeder's Cup (Larry Kilgallen, Ian Rogers, Henry G. Baker) Re: -32768 (Paul Eggert, Dik Winter) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Wed, 6 Nov 1996 14:10:15 +1100 (EST) From: hjm@world.net Subject: 1996 Melbourne Cup off-course betting fiasco The Melbourne cup is Australia's premier horse race (handicap over 3200 metres with over $AUS 2 million prize money), that even has its own public holiday in metropolitan Melbourne. The whole nation stops to listen or watch the race and lots of once a year punters have a dabble on the cup. The TAB (used to stand for Totaliser Agency Board when government owned and run, but now a public company) is the ONLY (legal) provider of off-course racing betting in Victoria. However, when the punters turned up at their local TAB (or pub TAB located in hotels) to place their bets on yesterday's race (5 November 1996) there were queues that stretched out the door for hundreds of meters. The 15 year old computer system had failed again on Melbourne Cup day and most small agencies were off-line from about 10:45 am (AESST) to just before or after the running of the cup at 3:20pm (AESST), whilst the larger agencies were off and on with reduced numbers of active windows throughout this period. Irate punters and TAB agency owners were, of course, furious and a lot of money that would have been wagered was lost as punters gave up waiting to try to get a bet placed. The TAB chief executive, Ross Wilson (already controversial due to his seemingly excessive salary package) was quoted as saying that the system breakdown "could have been worse"; it is hard to imagine how. The total loss of money wagered has not yet been calculated, but it will be huge. Ross Wilson also stated that "of course" there will be a full investigation of the problems and these will be rectified so that it doesn't happen again. Breakdowns of the TAB system on Melbourne Cup day have occurred before with the last major shutdown 4 years ago. Yesterday's problem was described as being the result of software modifications made to the TAB software 10 months prior to the Cup, and the excessive demand due to the huge increase in the number of bets activated a software bug in these modifications that lead to a shutdown of the system. It is difficult to understand how the TAB system could not be designed and tested to accommodate the peak betting activity as the Melbourne Cup ALWAYS results in this level of high activity, and is therefore predictable and, you would imagine, able to be simulated. Agency owners, who are still trying to recover from the loss of income due to a protracted dispute with Sky Channel who supply direct TV coverage of horse racing, are now investigating legal action against the TAB. Dr. Harley Mackenzie, Principal Operations Research Analyst, Yallourn Energy 114 William Street Melbourne 3000, Australia +61 3 9207 7719 hjm@world.net ------------------------------ Date: Tue, 5 Nov 1996 17:00:49 -0800 From: "George C. Kaplan" Subject: Fidelity Brokerage computer problems An article in the *Wall Street Journal* 4 Nov 1996 describes a major problem for Fidelity Brokerage Services (a discount stock brokerage) in London. Very few details are given beyond "late bookings of dividends and other problems", but it's serious enough that more than 50 people are working 14-hour days to sort through and correct three months of records *manually*. British authorities have forced FBS to stop taking new customers until the problems are solved. It appears to be a familiar story to RISKS readers: A new system was rushed into operation in April without adequate testing. FBS seems to be in denial, claiming that the system wasn't rushed, but that they simply "ran into some unanticipated glitches." George C. Kaplan gckaplan@cea.berkeley.edu 510-643-5651 ------------------------------ Date: 18 Oct 1996 16:14:03 +0200 From: "Nick BROWN " (Tel (+33)388412674 ) Subject: Bug in the network: a real spider About five years ago we were the first on our block to have an Ethernet segment implemented by a pair of 20 mW infra-red lasers. We had been promised that it was pretty reliable; as long as we could see the other building, so could the laser. And so it turned out; even though we spanned a canal in the foggiest town in France, we managed 98% uptime during the first few months (in the winter). Only on the foggiest days did we lose the connection, until about 10 each morning and from 4 each evening, for about 5 days total. Came the spring, and we started to get breaks in the connection at what seemed to be random times. Eventually we worked out that it was happening half an hour after sunrise and half an hour after sunset. We thought it might be the sun in line with the laser, but the layout wasn't right for that. We changed every component in the network. Until... One day, I noticed a spider's web connecting the laser box to the wall. Something must have flipped to On in my brain's background processing section, because about three days later (I run background processing on a very low priority), it dawned on me. I went up to the roof at the appropriate time and watched the laser carefully. Sure enough... a spider appeared, walked across the web, climbed into the transmission lens, and sat there (upside down), apparently eating its dinner, while a voice in my ear called "the link's down again !". We got a cloth, a box of Q-tips, and an aerosol of insecticide, put them in a box marked "Network Hardware Maintenance Kit", and set up a weekly rota for cleaning the laser, and had no more problems. I dined out on the story for several months afterwards. Nick Brown, Strasbourg, France (Nick.Brown@dct.coe.fr) ------------------------------ Date: Wed, 6 Nov 1996 03:51:28 -0500 From: Monty Solomon Subject: Announcement - Warning to Crypto and Banking Communities Begin forwarded message: Date: Sun, 3 Nov 1996 18:16:37 -0500 To: coderpunks@toad.com From: Ross Anderson (by way of Bruce Schneier) Subject: Announcement - Warning to Crypto and Banking Communities A serious weakness of DES Draft - 2nd November 1996 Abstract Eli Biham and Adi Shamir [RISKS-18.56] recently pointed out that if an attacker can induce unidirectional faults in key memory of cryptographic devices, then keys could be extracted quickly. Although their attack is very elegant, it is not practical against many fielded systems. For example, inducing a single-bit change in a DES key will cause a proper implementation to return a key parity error. However, when combined with Peter Gutman's recent work on memory remanence, there are two very practical attacks. One of them allows smartcard electronic wallet keys to be extracted with much less expensive equipment than that currently used by pay-TV pirates; the other yields an effective attack against fielded banking security modules. These attacks show that a feature of DES that had long been thought innocuous is actually a serious design error. Introduction In a research announcement of 30th October, Biham and Shamir [RISKS-18.54] point out that if a cryptographic hardware module employs EEPROM for key memory only, an opponent who can turn EEPROM values from `1' to `0' with a small controlled probability (e.g., by applying UV light) might cause a test input to be encrypted with a series of keys, each of Hamming distance one from the next in the series, and ending with the all zero key [1]. There are a number of reasons why their attack is not likely to work against real systems. For example, the typical smartcard system has several kilobytes of program code in EEPROM as well as typically two to five DES keys. An undirected stress applied to such a card is more likely to cause a program crash or an uninformative error than to yield a ciphertext encrypted under a key at Hamming distance one from a genuine key. Even if we only had to cause a hundred cards to fail to get a single input for the Biham-Shamir attack, if we needed on average 28 inputs to recover a DES key, then the number of cards required could be O(100^28). The situation is made still worse by the fact that DES keys have odd parity, and a proper implementation will reject a key if any of its bytes has even parity. So one would be reduced to looking for keys at a Hamming distance of two rather than one. It is this objection that inspired the following work. A Modified Attack My idea is to turn the DES key parity problem on its head and enable parity to help rather than hinder the attack. Let us first consider an opponent who can perform directed attacks on the chip. Reading the contents of an EEPROM cell directly is difficult, and people who do it for a living use focused ion beam workstations to modify the chip [2]. However, it is trivial to set an EEPROM cell to the value of your choice if you do not have to read it first; you only need two microprobes. A 10mS 18V pulse from the cell's source to its control gate will do the trick [3]. My modified attack therefore proceeds as follows. Set the first bit of the EEPROM containing the target DES key to 1 (or 0, the choice doesn't matter) and operate the device. If it still works, the keybit was a 1. If you get a `key parity error' message, then the bit was zero. Move on to the next bit; set it to 1 and see if this changes the device's response (from encryption to error or vice versa). This is a practical attack even on chips whose software we do not know in detail, as many smartcard software writers seem to have adopted a convention that the keys are located at the bottom end of the EEPROM memory. It will also work with protocols that use redundancy which we do not understand: we just change each key bit back to its original value. The use of predictable memory addresses for keys is not restricted to smartcards; many banking security modules also keep keys at low memory. I will now describe a related attack that extracts master keys from these modules. An Attack on Fielded Systems In a brilliant Usenix paper [4], Peter Gutman described the mechanisms that cause both static and dynamic RAM to `remember' values that they have stored for a long period of time. A prudent security engineer will ask what the effect of this is in the real world. I looked at an instance of a security module used in banking. This security module has 12 pairs of DES master keys stored in low memory. The device is tamper resistant in that power to the key memory is cut when the box is opened for servicing (this is needed every few years to change the battery). Keys are loaded into the device afterwards in multiple components by trusted bank staff. In this device, which dated from the late 1980's, the key values were substantially intact on power-up. The number of bits in error was of the order of 5-10%. I cannot give more accurate figures as I was not permitted to copy down either the correct master key values, nor the almost-correct values that had been `burned in' to the static RAM chips. I am also not permitted to name the bank at which these modules are installed, and it may not be prudent to name their manufacturer. Nonetheless the crypto community should consider the consequences. If each DES key is wrong by five bits, then the effort involved in searching for the 10 wrong bits in a double DES key might be thought to be 112-choose-10 operations. Each operation would involve (a) doing a 2-key 3DES decryption of a 64 bit PIN key whose enciphered value is widely known to the bank's programmers (b) in the 2^{-8} of cases where this result has odd parity, enciphering an account number with this as a DES key to see if the (decimalised) result is the corresponding PIN. The effort is 4 times 112-choose-10 DES operations - about 2^50. But it would probably be cheaper to do a hardware keysearch on the PIN key directly than to try to implement this more complex 2^50 search in either hardware or software. However, the bytewise nature of the DES key redundancy reduces the effort by orders of magnitude. If no key byte has a double error, then the effort is seven tries for each even parity byte observed, or 7^10 - about 2^28, which is easy. If there is one key byte with a double error, the effort is 2^38, giving a search of 2^40 DES operations - which is still feasible for an individual. Conclusions I have shown that the key parity in DES enables us to slash the cost of real attacks on both old systems (banking security modules) and new ones (electronic wallet smartcards). I had already mentioned in [5] that a common fault in the driver software for banking security modules was that `key parity error' messages were often ignored rather than copied to the bank's security manager to give warning of an attempted attack. This note shows that key parity is even more serious than that. The nature of DES key redundancy now appears to be a design error; it would have been much better to calculate the redundancy on the whole key. The 16 bit MAC used in the Clipper and Capstone chips is preferable (although as shown in [6], 16 bits may not be enough to prevent some protocol attacks). The lesson for bankers is that existing security modules (and other cryptographic devices) should be destroyed carefully at the end of their working life. The lesson for security engineers is that we should add key redundancy, and the question of whether we can rely on a device's eventual destruction, to the growing list of system parameters that must be (a) explicitly considered during design and (b) examined carefully when the product is being evaluated. Bibliography [1] ``The Next Stage of Differential Fault Analysis: How to break completely unknown cryptosystems'', Eli Biham, Adi Shamir, October 30th, 1996 [2] ``Tamper Resistance - A Cautionary Note'', Ross Anderson, Markus Kuhn, to appear at Usenix Electronic Commerce 96 (19th November) [3] ``Hardwaresicherheit von Mikrochips in Chipkarten'', Osman Kocar, Datenschutz und Datensicherheit v 20 no 7 (July 96) pp 421--424 [4] ``Secure Deletion of Data from Magnetic and Solid-State Memory'', Peter Gutmann, Usenix Security 96 pp 77--89 [5] ``Why Cryptosystems Fail'', Ross Anderson, in Communications of the ACM v 7 no 11 (Nov 94) pp 32--40 [6] ``Protocol Failure in the Escrowed Encryption Standard'', Matt Blaze, in Proceedings of the 2nd ACM Conference on Computer and Communications Security (2-4 November 1994), ACM Press, pp 59--67 ------------------------------ Date: Wed, 06 Nov 1996 07:03:54 +0800 From: David R Brooks Subject: Differential Fault Analysis: a possible defence? There has been much discussion lately, of the DFA attack on various cryptosystems. Defence strategies appear to be based on replication, either in space (dual-redundant crypto units, which check each other), or in time (do the crypto twice, and compare the results). Both techniques suffer from the same drawback: cost. It occurs to me that a defence could be based on the use of RAM, rather than ROM or hardwired logic, to embody the crypto algorithm. In practical terms, this would mean a hardware embodiment using (say) a RAM-based FPGA, or a software system which would copy the code to RAM before execution. The point here is that there would be typically far more RAM bits used to specify the algorithm than are used to hold data-in-process. The odds are that an induced error will corrupt the operating code, rather than a data bit. The result will be either total garbage output, or the result of a "different" algorithm (the original, plus errors). Does this idea have any merit? Dave Brooks ------------------------------ Date: 6 Nov 1996 17:18:18 +0000 From: "Nick BROWN" (Tel (+33)388412674) Subject: Ping o'Death from Windows 95 Anybody with an Internet site, especially those without firewalls, should check out http://www.sophist.demon.co.uk/ping/. It details how anybody with Windows 95 and an IP address (hmmm, there might be one or two out there...) can crash a large range of network equipment (HP 3000, DEC Alpha, IBM RS/6000, LaserJet printers, Netware servers, Windows PCs, routers, etc), apparently across the entire Internet. Nick Brown, Strasbourg, France ------------------------------ Date: Wed, 6 Nov 1996 17:26:40 +0000 From: Otto Stolz Subject: Re: Office 97, VBA 5.0, and macro viruses (Slade, RISKS-18.57) Re: Slade in RISKS-18.57 and VIRUS-L 9#208 Visual Basic is not the sole reason for these viruses to spread. A virus needs three preconditions to spread: - a platform that will execute its instructions, - a vehicle in which it will be passed between users, - a mechanism by which it will be executed unnoticed by the user. For the Word macro viruses, the platform is the Word macro language. VBA 5 will indeed make an upwards-compatible platform more widely available. However, Visual Basic is only sort of a syntactical framework: most standard functions and statements are only valid for a particular application. (I do not know VBA 5.0 yet, but I have coded a few macros both for Word 6.0 and Excel 5.0 and found that the major part of the language were application-specific, in both cases.) Hence, most VBA programs probably will only work with a particular application. So I think, we will not see a much more widely available platform for viruses to spread on, but rather a couple of similar, yet mutually almost incompatible platforms. A platform in itself is no particular thread, virus-wise. Platforms are useful (after all, they are the sole purpose computers are built for). We should not worry about the proliferation of platforms, but rather on the other two preconditions for viruses to spread. The vehicle for the Word macro viruses is Word templates disguised as documents. It was Microsofts greatest sin to allow Word templates (which contain the macros) to come disguised as documents. Word documents are widely, and frequently, exchanged amongst users. Now, if any document (according to the user's perception - even if it is, technically speaking, some other beast) can contain macros, this will constitute an ideal vector for macro viruses. This is one of the two main reasons for Word macros to spread so rapidly. If the macros would be confined to separate files (as with most other applications), users would most probably leave the macros behind when giving away documents. Word has two clandestine-execution mechanisms: macros with particular names (such as AutoOpen) are executed without explicit user action (e.g. when a document is opened) -- before the user even sees the document to be opened; macros with other particular names are bound to explicit user actions, such as hitting a button, or selecting a menu item. (If you think this is only one mechanism, you are probably right. No discussion on this triviality, please.) In particular, the AutoOpen macro mechanism is the other main reason for Word macros to spread so rapidly: with this mechanism in place, a user needs only to *view* a Word document (e.g. an attachment of an e-mail message, of a news item, or of a WWW page) to contract a virus! Conclusion: VBA 5.0 is not a particular threat, as long as the applications using it do not repeat Word's mistakes. Most important is to keep macros apart from application data (such as documents or spread-sheets); second most important is to avoid executing macros without the user's consent. Otto Stolz ------------------------------ Date: Wed, 6 Nov 96 12:32:35 EST From: skill@qucis.queensu.ca (David Skillicorn) Subject: Web search engines find connected components The altavista search engine at least finds files that do not have URLs pointing to them, as long as they are in directories that it visits for other reasons. I discovered this when a search of a well-known CS repository turned up files containing all sorts of administrative information, not intended for public consumption. It seems sensible to keep only things you want seen in directories that web servers can access. Having permissions set properly will prevent web servers seeing other files, but fouling up permissions is an easy error. ------------------------------ Date: Tue, 05 Nov 1996 19:20:34 -0500 (EST) From: "Larry Kilgallen, LJK Software" Subject: Re: Tote Board Crash at Breeder's Cup (Morphett, RISKS-18.57) I think there is a Risk in attempting to add the more robust features at the more shaky end of the language spectrum. Ada syntax (but not necessarily every implementation) supports unlimited programmer-specified ranges. That would seem a better starting place for programmer-unspecified ranges. Anyone for zero-terminated integers ? :-) Larry Kilgallen ------------------------------ Date: Wed, 6 Nov 96 14:32 GMT From: ianr@cogs.susx.ac.uk (Ian Rogers) Subject: Re: Tote Board Crash at Breeder's Cup (Morphett, RISKS-18.57) Perhaps you should check out Poplog Pop11. It is used mostly at research institutes, but also at some major process control sites where its garbage collection and wide range of number formats is highly valued. Among its number formats are: fixed int, small float, double float, ratio (i.e. 10/3 is *not* approximated), imaginary (sqrt(-1) returns a sensible answer), and big ints (integers as big as the size of your VM -- one of the standard pop11 benchmarks is to calculate factorial(1000) :-) Conversion between number formats is automatic in all the arithmetic functions. Contact isl@isl.co.uk or comp.lang.pop Ian Rogers, Sussex University ------------------------------ Date: Wed, 6 Nov 1996 08:07:34 -0800 (PST) From: hbaker@netcom.com (Henry G. Baker) Subject: Re: Tote Board Crash at Breeder's Cup (Morphett, RISKS-18.57) The Symbolics Lisp machine defaulted to 'infinite' (indefinite) precision integers. In fact, this property was inherited by other languages which ran on this machine, e.g., Fortran-77. 'Integers' in Symbolics Fortran would happily take on values like 378475974398573485743579875987495734987539759837594359749857398753475 Quoting from "User's Guide to FORTRAN 77 Tool Kit", August 1986: "The Tool Kit supports arbitrary-precision integers, called _bignums_; as a result, all integers are immune from overflow..." "The only operation for which arbitrary-precision integers are _not_ valid is _unformatted_ input/output. In this case, integers must be between -2^31 and 2^31-1." "The Tool Kit detects uninitialized data (other than character data), so that an error condition results if a variable is used before it is assigned a value." "The Symbolics Lisp Machine provides strong hardware data-type checking among logical, integer, and real data. Thus, the hardware prevents a program error due to equivalencing of the data, for example, in the case where the exponent and mantissa of a real number might be interpreted as an integer." (I might point out that many of the standard Internet attacks which depend upon poor type or array bounds checking are worthless against such machines; I understand that they remained up and happily running, after many of their Unix brethren had been hopelessly compromised by Internet worms and other attacks.) These significant advances in the quality of Fortran software was _not_ appreciated by Fortran programmers, and the porting of existing Fortran programs -- which use such equivalencing very heavily -- became a nightmare. However, the market was not kind to Symbolics, proving that software quality is not a particularly important feature in a computer system, as judged by paying customers. ------------------------------ Date: Wed, 6 Nov 1996 11:32:37 -0800 From: Paul Eggert Subject: Re: -32768 (Brader, RISKS-18.55) Mark Brader's discussion of -32768 is correct as far as it goes, but it omits some of the more entertaining aspects of C expression evaluation. Here's a table that may help RISKS readers appreciate some of the finer points. This table uses the usual C notation: an `0x' prefix means hexadecimal; an `L' suffix means the type is `long'; `U' means `unsigned'. 2's complement arithmetic is assumed, so none of the expressions overflow. [SEE NOTE BELOW.] `*' marks disagreements with the usual mathematical meanings of expressions. C expression value of C expression, assuming: 16-bit `int' 32-bit `int' 32768 32768L 32768 0x8000 32768U 32768 -32767 - 1 -32768 -32768 -32768 -32768L -32768 -0x8000 32768U * -32768 -0x8000 == -32768 0 * 1 0U < -32767 - 1 1 * 1 * 0U < -32768 0 1 * 0 < -0x8000 1 * 0 Is everything clear now? [NOTE added, at Mark Brader's suggestion: Paul's assumption is one that is assumed for this posting only; it is not guaranteed by the language. In particular, C can be legally implemented on 1's complement hardware, where the value -32,768 is not permissible in a 16-bit int (or short) at all. MB via PGN] ------------------------------ Date: Wed, 6 Nov 1996 14:39:35 GMT From: Dik.Winter@cwi.nl Subject: Re: -32768 (Fredriksson, RISKS-18.57) What you are missing is that "-32768" in C is not a constant but an expression. The type of a C expression depends on the type of the operands and the operator. In this case the operand is "32768", the operator is "-". The type of 32768 is "long" if the type "int" is only 16 bits, and so the type of "-32768" is "long" in that case. But in the context of the definition of INT_MAX the type should be "int". On the other hand, when we write "-32767 - 1" the type is "int" because all constituent parts are of that type. [This item is included to close the discussion off. Bear Giles had it exactly right in his followup in RISKS-18.49, and it might have been better for me to have pointed that out privately to Kurt Fredriksson. But the error is a common one, so perhaps it was worth flogging it once more. Strong typing is the answer to a lot of questions, but it also helps to understand the questions. PGN] ------------------------------ Date: 15 Aug 1996 (LAST-MODIFIED) From: RISKS-request@csl.sri.com 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. Or use Bitnet LISTSERV. Alternatively, (via majordomo) DIRECT REQUESTS to with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] => The INFO file (submissions, default disclaimers, archive sites, .mil/.uk subscribers, 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 risks@CSL.sri.com with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.comlogin anonymous[YourNetAddress]cd risks or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. The ftp.sri.com site risks directory also contains the most recent PostScript copy of PGN's comprehensive historical summary of one liners: get illustrative.PS ------------------------------ End of RISKS-FORUM Digest 18.58 ************************