From: SMTP%"risks@csl.sri.com" 20-NOV-1996 19:06:19.77 To: EVERHART CC: Subj: RISKS DIGEST 18.62 Date: Wed, 20 Nov 1996 12:03:34 -0800 (PST) From: risks@csl.sri.com Message-Id: <199611202003.MAA22877@chiron.csl.sri.com> X-Authentication-Warning: chiron.csl.sri.com: risko set sender to risks@csl.sri.com using -f To: risks@csl.sri.com Subject: RISKS DIGEST 18.62 Sender: owner-risks@csl.sri.com Reply-To: risks@csl.sri.com RISKS-LIST: Risks-Forum Digest Weds 20 November 1996 Volume 18 : Issue 62 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: Effects of the next cycle of solar interference (David L. Oppenheimer) Lock those electronic doors (Dave Farber) Risks of ActiveX (Simson L. Garfinkel) New tampering attacks on smartcards and security processors (Ross Anderson) Digital cash - just say no! Mondex/MasterCard (Nick Brown) Computer Theft, Low-Tech Style: Visa credit information (Edupage) The current score is: Y2K 1, Visa 0 (Ry Jones) Forwarded to X, remailed to Y, redirected to Z ... (Rob Slade) NT password is not much protection (comments on sci.crypt item) Large app stumbles JDK/JVM (Michael O'Donnell) Data correct, conclusion wrong (Flint Pellett) Cellular One locating cell calls (Sam Lepore) Re: Sometimes junk e-mail is already a fax, legally speaking (Phaedrus) Re: AOL Bans All Mail from 53 "Junk Mail" Domains (Chris Eason) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Tue, 19 Nov 1996 11:03:33 -0500 From: "David L. Oppenheimer" Subject: Effects of the next cycle of solar interference [Source: Coming solar cycle may pose problems, AP item, 19 Nov 1996, PGN Stark Abstracting and Excerpting Service.] Cycle 23 of solar interference activities is building up, and is expected to have considerable effects on our planet around the year 2000, according to a panel of government researchers. (Cycle 22 was at its peak in July 1989 [see RISKS-8.38, 39 on electric currents induced in power lines, blacking out Quebec, and RISKS-8.72 for a more detailed retrospective article]; the strongest cycle to date was in November 1957.) In particular, many new industries have emerged that were not subjected to previous solar effects -- and they have not anticipated the risks to their systems and their businesses. Navigation and communications are considered to be particularly vulnerable. For information on the report, you might try contacting Air Force Col. Jud Stailey, assistant director of the Office of Federal Coordinator for Meteorological Services, a 13-agency panel housed in the offices of the National Weather Service, or Ernie Hildner, director of the National Oceanic and Atmospheric Administration's Space Environment Center in Boulder, Colo. Potential problems to anticipate include damage to computers and other electrical systems in satellites; expansion of the Earth's atmosphere, slowing down satellites and pieces of space debris, making them harder to track; induced currents in pipelines and other large arrays of metal; disruption of signals for the inexpensive single-frequency global positioning system satellites; interference with the newly developed satellite cell-phone system; changes in the Earth's magnetic field, interfering with signals used to direct oil drilling bits deep underground. [An obvious question for RISKS readers is which will have a more dramatic effect, Y2K or Cycle 23? Perhaps we will have Murphy-slaw and each will reinforce the other on the same day! PGN] ------------------------------ Date: Sun, 17 Nov 1996 20:30:15 -0500 From: Dave Farber Subject: Lock those electronic doors U2-INTERNET LONDON (AP) - The Irish rock band U2 may have become the world's first music group to be burglarized on the Internet, according to reports. Two songs lifted from the band's yet-to-be released album have been removed from computers at U2's Dublin studio and distributed on the Internet, according to the Sunday Times of London. Island Records, which manages the multi-million selling artists, says the appearance of the songs represents copyright infringement. Island is reportedly trying to close down the Internet sites on which the songs, "Discotheque" and "Wake Up Dead Man," appear. ------------------------------ Date: Sat, 16 Nov 1996 13:28:40 -0500 From: "Simson L. Garfinkel" Subject: Risks of ActiveX Although people who care about computer security are concerned about ActiveX, the problems are likely to grow in the coming months and years. That's because ActiveX is key to Microsoft's long-term strategy of eliminating the distinction between information stored on desktop computers and information stored on the network. I have had numerous conversations with Microsoft employees about ActiveX over the past six months. In summer 1996, I was told that the security problems would be solved by code-signing. This fall, I was told that code-signing doesn't solve the security problem, but does provide accountability. Now I'm told that it doesn't really give you accountability either, but it does give you integrity for the downloaded applets and, anyway, code signing is import for its own right. Besides, says Microsoft folks, the dangers in ActiveX controls are no different than the dangers that are found in downloading any program from the Internet. The real reason that code signing does not promote authentication, of course, is that truly malicious ActiveX components won't tell you that they are maliciously modifying your operating system. In fact, they'll try to make the modifications as quietly as possible. Or they might engage in a two-pronged attack. For example, one ActiveX control could change Internet Explorer's ActiveX security level so that you would run unsigned applets; later, a second control could do the real damage. On Wednesday, November 20th, my column on HotWired's "Packet" channel will go into the ActiveX security problem in some detail. If you wish to read it, just check out http://www.packet.com/garfinkel. It's free. Simson Garfinkel ------------------------------ Date: Sat, 16 Nov 1996 18:46:41 +0000 From: Ross Anderson Subject: New tampering attacks on smartcards and security processors A number of posts on breaking tamper resistant processors have appeared recently; most of them have been theoretical. However, in a paper to be published on Tuesday, we describe a number of very practical attacks on smart cards and other security processors. We have implemented some of them successfully against fielded systems. The URLS are: html: www.cl.cam.ac.uk/users/rja14/tamper.html postscript ftp.cl.cam.ac.uk/users/rja14/tamper.ps.gz This work will appear at the Usenix Electronic Commerce workshop in Oakland, California, where it has won the `Best paper' award. It was written some time ago, but we held back the results in order to give banking systems developers the chance to implement countermeasures. One of the attacks we describe breaks completely a security processor that is widely used in the banking industry; it is embedded in about a million point-of-sale terminals, automatic-teller machines, and banking key management systems. Our attack enables all the code and key material to be read out from this chip in minutes. Other techniques we describe enable attackers to extract all or part of the code and keys from various makes of smartcard and `secure' microcontroller. They have profound implications for bankers, pay-TV stations, operators of prepayment electricity meters and of course for the smartcard industry itself. We also include a survey of attacks developed by others, many of which have not appeared in the literature before. We found that once we had some results to show, everyone from chipmakers through intelligence agencies to TV pirates wanted to swap hints and compare notes. Even some top scientists at smartcard companies would tell us about vulnerabilities - in their competitors' cards! So our article describes a number of the attacks actually used by spooks and TV pirates. We also describe techniques developed by the chip testing industry, many of which can easily be adapted to read out secrets from smartcards; although they are in the open literature, the security community has just not been aware of them. Until quite recently, many system developers relied blindly on the tamper resistance claims made by the manufacturers of smartcards and other security processors. Over the last two or three years, it has become increasingly clear that organised gangs had acquired the capability to clone the smartcards used in pay-TV access control. This raises the obvious risk that banking systems could be next. Since writing this paper, we have devised a number of additional attacks. For example, Biham and Shamir announced an attack on DES based on 200 ciphertexts in which one-bit errors have been induced by ionising radiation; we can break DES with less than ten ciphertexts, using the kind of faults introduced by power and clock glitches. Boneh, DeMillo and Lipton announced an attack on RSA using one-bit errors; we can break RSA with a one-round glitch attack. This could be implemented in a Mafia-owned point of sale device, and factor RSA moduli in real time without the attack being noticed by either the customer or her bank. Our techniques not only make Differential Fault Analysis much more efficient; the fault model that we use is completely realistic. No-one has to our knowledge implemented an attack using radiation to generate one-bit data errors, but using high frequency transients in the power and clock inputs to a smartcard is an established way of causing it to decode instructions incorrectly. This technique has actually been used by TV pirates - though they attacked the card protocols rather than the cryptographic algorithms. Once we can cause instructions to be wrongly decoded, a range of quite novel attacks becomes available. In addition to differential fault analysis, we can look for glitches that reduce the number of rounds in the encryption algorithm. If DES is reduced to one or two rounds, for example, then extracting the key becomes trivial. This attack can also be implemented using our most recent innovation - the ROM overwrite attack. This is inspired by the observation that many smartcards have a DES implementation in ROM, which we can usually see under a microscope and which we can damage using a laser cutter. This is often a lot cheaper and simpler than using an ion beam workstation to read keys directly out of EEPROM. If we are familiar with the ROM implementation (or can disassemble it), we typically find a small number of bits with the property that changing them reduces the number of rounds to one or two. Where this is not possible, we may still be able to identify the S-boxes, and by setting all their bits to the same value we can turn DES into a linear transformation. Again, the key can be trivially recovered. This is a new and exciting field of research, and one that secure system designers would be prudent to follow closely. Ross J. Anderson Computer Laboratory University of Cambridge Pembroke Street, Cambridge CB2 3QG E-mail: ross.anderson@cl.cam.ac.uk Markus G. Kuhn Department of Computer Sciences Purdue University West Lafayette, IN 47907 E-mail: kuhn@cs.purdue.edu ------------------------------ Date: 19 Nov 1996 15:42:01 +0000 From: "Nick Brown" (Tel (+33)388412674) Subject: Digital cash - just say no! Mondex/MasterCard Apparently MasterCard has bought a 51% share in Mondex, a British company which produces electronic cash smart cards. Mondex has been on pilot tests in Swindon, England, for the past year or so, and MasterCard claims to want to make it available across Britain. Am I the only person who thinks this is suicidal, either for MasterCard and its associated banks, or in the worst case for the whole currency? The arrogance of the people behind this and other forms of virtual money, in thinking that their codes can't be defeated by either brute-force or backdoor mechanisms, is quite breathtaking. RISKS-18.15 has an example of how this kind of thing has already been done. And when the Mondex trial system was launched, BBC Television showed how easy it is to retrieve all kinds of smart card technical data over the Internet. Once those smart cards, readers, and ATM card-point-loaders get widely distributed, they will be sitting targets for anyone who fancies a shot at reverse-engineering them. Possible reward: a machine that effectively prints money, but far, far more attractive than forging bills. I think the bad guys might have a few 200 MHz Pentium Pro systems to spare for this; although in any case, stealing just one card-loading machine would seem to be simpler. For one thing, a fake bill is still a fake bill after it's been passed on ten or a hundred times, and the person introducing it into the system knows that, for the first few times each bill is used, there's at least some possibility of tracing it back. For fake electronic cash, however, there's no way to distinguish between the real virtual stuff and the fake virtual stuff. As a result, nobody will care whether what they're being given is real or not, like they currently do with those fancy U-V lights, because they won't have it rejected by the bank. Having any ATM able to load up your smart card with points, is equivalent to having current ATMs print the bills fresh 'n' crisp when you ask for them, and just making a mental note to settle up with the central bank later. For a number of very good reasons, central banks don't like the idea of this. (Does anyone imagine that the directors of BCCI would have bother ripping off their customers, had it been easier just to print a few bills and forget to notify the Federal Reserve or Bank of England ?) Even worse, the only way we'll know that there are a lot of fake Mondex cash in circulation is when inflation starts rising for no obvious reason; at which time, the crisis in confidence in the banking system doesn't bear thinking about. One other point that I am reluctant to make, since I don't usually subscribe to the "drug dealers/paedophiles/foreign agents use technology item X, so we have to make it illegal, to protect our streets/kids/national security" argument, but: has anyone considered just what a great tool this will be for laundering money ? Nick Brown, Strasbourg, France ------------------------------ Date: Tue, 19 Nov 1996 23:06:40 -0500 (EST) From: Edupage Editors Subject: Computer Theft, Low-Tech Style: Visa credit information A thief broke into a Visa International data processing center in California a couple of weeks ago and stole a personal computer containing information on about 314,000 credit card accounts, including Visa, MasterCard, American Express, Discover and Diners Club, says a Visa spokesman. Some issuers, including Citibank, began calling customers last week and have issued new cards. Others are keeping quiet about the event and monitoring accounts for unusual activity. Authorities speculate that the perpetrator was stolen for the resale value of the hardware, rather than the information it contained. (*St. Petersburg Times*, 19 Nov 1996 E2) ------------------------------ Date: Mon, 18 Nov 1996 11:49:08 -0800 (PST) From: Ry Jones Subject: The current score is: Y2K 1, Visa 0 http://www.msnbc.com/news/42003.asp discusses the ramifications of the embedded technology in card swipe readers not being Y2K compliant. The article states that 10% of the Visa swipe readers cannot deal with Y2K expiration dates, marking the cards as invalid because 1900 < the current day/time. Visa cards are issued with 3 year expiry periods, meaning the first batch of reader-breaking cards is probably already in consumer hands. The article also states that Visa will levy fines on member banks from 1000 USD to 100000 USD for non-compliance with a directive to fix all merchant systems by March 1997. In the interim, Visa is asking member banks not to issue cards that expire in Y2K, instead, issuing cards that expire in 1999. My favorite quote from the web page: "(It seems that using two-digits rather than four to represent a year was once a common programming technique)". ------------------------------ Date: Mon, 18 Nov 1996 14:21:08 EST From: "Rob Slade" Subject: Forwarded to X, remailed to Y, redirected to Z ... I suppose there is nothing much new in mailstorms, or in the problems of forwarders and remailers, but ... As some RISKS readers may be aware, I occasionally submit reviews of books to the list. In fact, this is only a small selection from the book reviews that I "publish" daily over the net. I do not run an automated mailing list myself, submitting the reviews for the general public via the Usenet *.books.* groups. I do manually maintain a select mailing list for newsletter publishers, bookstores, and Web site archivists. A little over a week ago I started to get a flurry of bounce messages from one site. In fact, I was getting around a hundred messages per day. In addition, for some reason the messages were of extraordinary size, and were regularly causing my account (on a VMS system) to exceed disk quota. Often this type of thing is caused by the remailing of one of my messages through another mailing list. NETTRAIN (for perhaps obvious reasons) seems to have a very high proportion of people who simply abandon their accounts without unsubscribing, and these accounts frequently bounce errors to the originator, rather than the list-owner. Examination of the header, however, showed no indication that this had happened in this instance. My own list had no entry that remotely resembled the site I was getting the bounces from. This has gone on for the past week. All the bounces relate to the one, single message: none to any subsequent reviews sent out. Messages to every "postmaster" account I could generate from the header info turned up nothing. The bounces haven't stopped, but I've finally got some information on whose account it is. One of the requests to be put on the list was for a small, local distribution list. One of the people on that list does not work directly for the people running the local list. She was provided with an account on their system, but never learned to use it. Her lack of use of the local account created a problem with mail buildup on their local system, so that account was forwarded to her work. Her work system seems to be the one generating the problem. Apparently they have had unresolved network connection problems for some time now. It seems reasonable to assume that something tried on that one day has now created an unresolved loop, which is still sending out the error messages. *My* problem still isn't resolved. Of course I have now taken the system with the local distribution off *my* list, thus ensuring that no more mail goes to them, her, or her employers. In the meantime, the bug has taken on a life of its own, plugging my e-mail account (and exceeding my quota) on a daily basis. Isn't automation wonderful? :-) roberts@decus.ca rslade@vcn.bc.ca slade@freenet.victoria.bc.ca link to virus, book info at http://www.freenet.victoria.bc.ca/techrev/rms.html ------------------------------ Date: Tue, 19 Nov 96 9:59:55 PST From: RISKS List Owner Subject: NT password is not much protection (comments on sci.crypt item) [Identity of contributor withheld by request.] Recently, sci.crypt, Bernd Lehle wrote: > On http://www.omna.com/Yes/MWC/PRS-index.htm a company called MWC offers > the following service: > > "recover" an NT (any version) Administrator password at any level of > complexity within 4 hours. > > They claim to use 4 PPro-200s and guarantee the result for a fee of > US$4500. > > NT uses up to 14 characters in a password. In order to recover a UNIX > password at any level of complexity with 14 characters, 4 PPro-200s will > crunch for approx. 1e16 years (assuming 10,000 crypts per CPU per second). > Does anybody know, where the difference comes from ? Jeremy Allison replied: > Yes, this is very interesting. I believe I know > how they are doing this. They have discovered a > nasty little 'secret' in NT that I have been pursuing > for a couple of years now (on and off, without really > dedicating months of time to it though :-). > > My guess would be, if you sent them a drive and > told them you had lost your password, it would come > back with a different Administrator password than > the one you sent it in with :-). > > It works like this. The NT password database in the > registry is only as secure as UNIX shadow passwords > (actually, a little less secure as they don't use > salt in their hash technique, it's pure DES for the > Lanman password, and MD4 for the NT password). > The 'nasty little secret' is that the hashed password > values are double encrypted (for 'obfuscation purposes' > it says in the NT knowledgebase) in the SAM. I believe this > company has worked out how that double encryption is done, > and just overwrite the hashed password. My explorations in > this area lead me to believe that MS use DES in ecb mode > to just encrypt the hash, and that the key is some > function of the last RID component of the users SID value. > > I believe this to be the case after doing various > experiments on an NT SAM database, changing users > names whilst keeping password the same (no change > in double-encrypted hash), assigning the same password > to users with the same name but different SID's (different > double encrypted hash), assigning the same password to > users with different names, in different domains, but > with the same last RID component of the SID (identical > double-encrypted hash). ... [With minor spelling corrections. PGN] ------------------------------ Date: Wed, 13 Nov 1996 12:33:32 -0500 From: Donkey Hotay Subject: Large app stumbles JDK/JVM The article at http://www.techweb.com/wire/news/1109bug.html describes how "A prominent Web development shop found two substantial performance flaws in Sun Microsystems' Java Developers Kit when it attempted to deploy it in a large-scale environment." The developers' introduction to various RISKS will be familiar to readers here. Excerpted comments: "In a complex, multiserver, multiprocess environment, that's to be expected," Presence's McFall said. "We had to tune several things before we could get it stable." Once the AtHand design was stable, the problems in the Virtual Machine emerged. As the load increased between the Web server and an Oracle database on the AtHand site, the Virtual Machine locked up. "Some of the operations, as far as managing memory, worked under normal load, low-stress conditions, but when you start pounding on it--like what is going to happen on a big Web site--there are a few bugs in there," said Xeno Derer, the software engineer at Presence charged with fixing the Java bugs. "It either died thinking it was out of memory or the Virtual Machine itself would start crashing." The article mentions that PacBell was the client and that the app was to handle, among other things, their online directory service. Michael O'Donnell mod@std.com ------------------------------ Date: Fri, 15 Nov 1996 17:19:57 CST From: flint@kai.com (Flint Pellett) Subject: Data correct, conclusion wrong (Re: Baker, RISKS-18.58) > "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." Mr. Baker's conclusion does not seem warranted based on the evidence he presents. Paying customers make their buying decisions based upon a lot of different factors such as cost, performance and features. Quality is certainly one of them. Mr. Baker is welcome to release a really low-quality software product out into the marketplace to prove me wrong. If he is right, he'll be rich a year from now. ------------------------------ Date: Tue, 12 Nov 1996 06:05 -0800 (PST) From: Sam.Lepore@ncal.kaiperm.org Subject: Cellular One locating cell calls (Re: Glassman, RISKS-18.40) In early September, Bernard Glassman wrote about FedEx using a service provided by Cellular One in North Carolina to locate the point from which he originated a cell call. I pursued the question about that service availability with my local (San Francisco Bay Area) Cellular One office. They responded in writing: "Cellular One Bay Area does not offer the service described in the e-mail. It is important to remember that Cellular One is a franchise and each service area is individually owned and operated. I will of course contact you if I hear of any such services being offered by our company." It seems there is a risk of assumption in dealing with a company that appears to be a national entity but is in fact a series of franchises. We should not assume all locations will deliver (or not deliver) the same services. I can't recall ever having heard that different locations of any company might offer different services _because_ the company is a franchise ... unless it is the ubiquitous phrase on hamburger advertisements "at participating locations only" ? Sam Lepore Kaiser Permanente Walnut Creek, California ------------------------------ Date: Sat, 14 Sep 1996 09:46:27 -0700 From: Phaedrus Subject: Re: Sometimes junk e-mail is already a fax, legally speaking If you accept that 47 USC 227 does apply to e-mail, let me point out that Mr. Franklin has violated that same federal law by sending his message to comp.risks, and our esteemed moderator has also violated the law by distributing RISKS. This is because that law also contains the following clause: "It shall be unlawful for any person within the United States [...] to use a computer or other electronic device to send any message via a telephone facsimile machine unless such person clearly marks, in a margin at the top or bottom of each transmitted page of the message or on the first page of the transmission, the date and time it is sent and an identification of the business, other entity, or individual sending the message and the telephone number of the sending machine or of such business, other entity, or individual." In other words, if you believe that 47 USC 227 applies to e-mail, and you have ever sent an e-mail message that did not include your telephone number, then you are a federal criminal. (And there's still the thorny issue of deciding exactly what constitutes a "page" of an e-mail message.) Furthermore, the manufacturer of your computer has violated the law, because the law also requires the manufacturers of telephone facsimile machines after 1992 to make sure that the machine clearly marks this information on each page. There are several other aspects of 47 USC 227 that make no sense in this context. I would certainly agree that a law against unsolicited bulk e-mail is called for. But the way to solve that problem is to create such a law, not to try to creatively misconstrue an existing law to cover a situation it wasn't designed or intended for. ------------------------------ Date: Fri, 8 Nov 1996 21:57:33 -0500 From: ChrisEason@aol.com Subject: Re: AOL Bans All Mail from 53 "Junk Mail" Domains As an AOL subscriber, I would like to clarify this situation. AOL did not ban these domains, they simply provided their users with the tools to block mail from them. Any AOL subscriber can receive mail from any or all of the domains by setting the appropriate flags. The risk here is that AOL's member accounts are automatically set to block these domains, and it's up to the individual members to know that they need to unblock them if they want to receive the mail. AOL did advertise this option conspicuously on the service. Chris Eason ------------------------------ 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.62 ************************