precedence: bulk Subject: RISKS DIGEST 18.95 RISKS-LIST: Risks-Forum Digest Friday 28 March 1997 Volume 18 : Issue 95 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: DTI proposals on key escrow (Ross Anderson) RISKS of analogy: Elections Canada and the Net (Mich Kabay) SSL Browser Vulnerability Discovered (David Kennedy) JavaScript attack through MIME attachments (Ted Wong) Generating randomness (Paul C. Kocher) Computers in California Senate (Keith Price) DC traffic-light sychronization problem (David Pipes) Re: all-ways green lights (Robert Miller via J. DeBert, Sean Ercanbrack, Barak Pearlmutter) God, the sweepstakes winner (Kevin A. Hogan) Re: Crackers Obtained Gulf War Military Secrets (Fred Cohen) Re: Y2K: revenge of originality (Harlan Rosenthal) Y2K costs (Richard Schroeppel) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: 21 Mar 1997 10:11:57 GMT From: rja14@cl.cam.ac.uk (Ross Anderson) Subject: DTI proposals on key escrow The British government's Department of Trade and Industry has sneaked out proposals on licensing encryption services. Their effect will be to ban PGP and much more besides. I have put a copy on http://www.cl.cam.ac.uk/users/rja14/dti.html as their own web server appears to be conveniently down. Licensing will be mandatory: We intend that it will be a criminal offence for a body to offer or provide licensable encryption services to the UK public without a valid licence The scope of licensing is broad: Public will be defined to cover any natural or legal person in the UK. Encryption services is meant to encompass any service, whether provided free or not, which involves any or all of the following cryptographic functionality - key management, key recovery, key certification, key storage, message integrity (through the use of digital signatures) key generation, time stamping, or key revocation services (whether for integrity or confidentiality), which are offered in a manner which allows a client to determine a choice of cryptographic key or allows the client a choice of recipient/s. Total official discretion is retained: The legislation will provide that bodies wishing to offer or provide encryption services to the public in the UK will be required to obtain a licence. The legislation will give the Secretary of State discretion to determine appropriate licence conditions. The licence conditions imply that only large organisations will be able to get licences: small organisations will have to use large ones to manage their keys (this was the policy outlined last June by a DTI spokesman). The main licence condition is of course that keys must be escrowed, and delivered on demand to a central repository within one hour. The mere delivery of decrypted plaintext is not acceptable except perhaps from TTPs overseas under international agreements. The effect of all this appears to be: 1. PGP servers will be outlawed; it will be an offence for me to sign your pgp key, for you to sign mine, and for anybody to put my existing signed PGP key in a foreign (unlicensed) directory 2. Countries that won't escrow, such as Holland and Denmark, will be cut out of the Superhighway economy. You won't even be able to send signed medical records back and forth (let alone encrypted ones) 3. You can forget about building distributed secure systems, as even relatively primitive products such as Kerberos would need to have their keys managed by a licensed TTP. This is clearly impractical. (The paper does say that purely intra-company key management is OK but licensing is required whenever there is any interaction with the outside world, which presumably catches mail, web and so on.) There are let-outs for banks and Rupert Murdoch: Encryption services as an integral part of another service (such as in the scrambling of pay TV programmes or the authentication of credit cards) are also excluded from this legislation. However, there are no let-outs for services providing only authenticity and nonrepudiation (as opposed to confidentiality) services. This is a point that has been raised repeatedly by doctors, lawyers and others - giving a police officer the power to inspect my medical records might just conceivably help him build a case against me, but giving him the power to forge prescriptions and legal contracts appears a recipe for disaster. The scope for fraud and corruption will be immense. Yet the government continues to insist on control of, and access to, signing keys as well as decryption keys. This shows that the real concern is not really law enforcement at all, but national intelligence. Finally, there's an opportunity to write in and protest: The Government invites comments on this paper until 30 May 1997 Though if the recent `consultation' about the recent `government.direct' programme is anything to go by, negative comments will simply be ignored. Meanwhile, GCHQ is pressing ahead with the implementation of an escrow protocol (see http://www.cs.berkeley.edu/~daw/GCHQ/casm.htm) that is broken (see http://www.cl.cam.ac.uk/ftp/users/rja14/euroclipper.ps.gz). In Grey's words, ``All over Europe, the lights are going out'' Ross ------------------------------ Date: Thu, 27 Mar 1997 12:01:09 -0500 From: "Mich Kabay [NCSA]" Subject: RISKS of analogy: Elections Canada and the Net In the *Globe&Mail*, 27 Mar 1997, p. A6, their Applied Science Reporter tells another story of how governments are fearful of uncontrolled human communications. [MK: Some background: Canada, like the US and Russia, is so wide that many people in the Western areas must vote after vote-counting has begun in Eastern regions. Election officials have long been concerned about the effects of releasing late public-opinion polls and also preliminary vote-counts from the East; they claim (I have never seen any reference to evidence, but this is not my field of expertise) that knowing these data influences the vote by discouraging votes or by changing them. There are therefore strict rules in Canada on what the news media may say in the run-up to the actual vote.] > Elections Canada scrambling to plug cyberspace loophole: > Officials hope to bring election law to the wilds of the Internet. > by Mary Gooderham > Elections Canada is scrambling to jam its finger in the electronic dike. > > Officials have decided that the Internet will face the same rules as other > news media when it comes to disseminating public opinion polls within 48 > hours of election day and releasing vote results early on election night. The reporter makes the following key points: * The Canada Elections Act forbids premature "publishing" voting results by any means. * The 48-hour blackout on advertising by political parties does _not_ apply to the Net. * John Enright, a spokesperson for Elections Canada, said that the Office would investigate and prosecute any breach of the Act, but admitted that actually catching violators who use the Net is "virtually impossible." * Professor John Courtney (political science, University of Saskatchewan) raised the question of whether the Office would try to forbid electronic mail from residents of the east to residents of the west. [Comments by MK: So the bureaucrats are trying to push back the tide again. I expect this sort of nonsense from authoritarians in the PRC, Burma, and so on; it's distressing to see people in Canada uttering such rubbish. What's next, an attempt to stop people in Newfoundland from phoning their friends in British Columbia to safeguard the sacred innocence of Westerners? The problem here is that the Elections Canada officials are stuck in a primitive analogy. Change their view of the Net as a medium for "publishing" to a view that does not try to force the models of the past on the current reality and the problem disappears. The Net is _not_ merely like newspapers, nor merely like a bookstore, nor merely like a fax machine, nor merely like a billboard. These folks need a dose of general semantics: the symbol is not the thing. As Professor Courtney is quoted as saying in the article, "The question is: Does it affect how you vote or whether you vote?" The fundamental issue is not technological: it is whether a government has any business at all controlling what information individuals willingly seek out.] Mich M.E. Kabay, PhD, CISSP (Kirkland, QC), Director of Education National Computer Security Association (Carlisle, PA) http://www.ncsa.com ------------------------------ Date: Fri, 28 Mar 1997 00:41:42 -0500 From: David Kennedy <76702.3557@compuserve.com> Subject: SSL Browser Vulnerability Discovered http://www.zdnet.com:80/intweek/daily/970327x.html Inter@ctive Week March 27, 1997 New Browser Security Flaw Discovered By Will Rodger > Internet browsers set up to protect users' credit card numbers from theft > are unwittingly handing out those numbers to untold numbers of other Web > sites as visitors follow links from those sites to other, insecure ones, > officials from Netscape Communications Corp. and Microsoft Corp. confirmed > Wednesday. The hole, though thus far unexploited, now appears to be the > most serious flaw yet discovered in the way Internet browsers handle > confidential information over the Internet. > "The place people will crack it is not the places people worry about > security but the ones they don't," said Daniel Klein, a Pittsburgh-based > consultant who discovered the hole earlier this month. "This is a big > hole." :: Both MS and Netscape say patches may take weeks to release. > "This is a serious problem," said Eugene Spafford, director of the > Computer Operations, Audit, and Security Technology program at Purdue > University in Indiana. "This isn't a good response because it's not clear > how many other people are going to be impacted by it." > > But Steven Bellovin, a computer security researcher at AT&T Corp. labs, > warned Microsoft and Netscape could find the problem difficult to > surmount. "The reality of software engineering making a quick and dirty > fix to a large program is likely to cause more problems than it fixes," he > said. "First you have to decide what the fix is." [...] > > But if a visitor who has just filled out a secure form then clicks on a > highlighted link to another Web site, all bets may be off. The information > that Web user typed in securely suddenly gets transferred to the logs of > the next machine, credit card numbers and all. :: Server-side remedies include referring visitors to an in-house dummy page to "wipe the browser's feet," or use the POST command instead of GET. > Users finally, can protect themselves by typing in Internet addresses > manually instead of using links from "secure" pages. Dave Kennedy [CISSP] Research Team Chief, National Computer Security Assoc. [Starkly excerpted by Dave. PGN] ------------------------------ Date: Fri, 21 Mar 1997 12:36:03 -0500 From: Ted Wong Subject: JavaScript attack through MIME attachments Netscape's JavaScript includes a command, window.open(...), for spawning a new browser window from within a web page. This feature, when combined with the fact the Netscape (by default) will display text/html MIME attachments as regular web pages, can be used to create a denial-of-service attack. A particularly obnoxious individual (let's call him A. User), created an web page containing JavaScript code to spawn an infinite number of new browser windows. Someone visiting this page will immediately see windows popping up all over the screen, with no way to gracefully exit Netscape; it stops responding to keyboard or mouse input while tied up executing the spawn loop. Now, another user (B. User) posted a message to comp.misc, warning people not to visit the offending web page. The problem is that B. User included the document source for the page as a text/html MIME attachment. Anyone viewing the message with the Netscape news reader will immediately execute the spawner. The only way (for me, at least) to stop the errant JavaScript code was to (Unix) kill Netscape. This touches upon RISKs discussed here before, particularly those that involve shipping software with minimal security set as the default. One can imagine a scenario where some malcontent spams several mail addresses with this attachment, with a good chance that an unlucky recipient will be using the Netscape mail viewer in its default JavaScript-enabled mode. This attack mechanism goes some way towards achieving what the "Good Times" e-mail claimed to do in word, if not in deed. I'm now running with JavaScript disabled. The document source is off of A. User's home page at - remember to view it with JavaScript turned off! Ted Wong Information Technology Section, Mann Library, Cornell University ------------------------------ Date: Fri, 28 Mar 1997 01:04:13 -0800 From: pck@netcom.com (Paul C. Kocher) Subject: Generating randomness (re: Klosowski, RISKS-18.94) Was: Risks of random-number servers The notion that the random pool used in a cryptographically secure PRNG "runs out" of entropy is not one I agree with. With a properly-seeded cryptographic PRNG, there shouldn't be any limit to the amount of random material you can produce (unless the crypto function starts failing). A secure PRNG is simply a good stream cipher. Although it's possible to use a one time pad and use as much input entropy as output material, this would be very cumbersome and isn't at all needed for encryption or a PRNG. Instead, the design goal to to make sure that that someone who doesn't know the entire key or PRNG seed cannot distinguish the output from a truly random sequence of equal length with a probability significantly better than guessing randomly. In other words, a well-seeded ryptographic PRNG should be perfect. (In contrast, PRNGs based on physical phenomena often produce output with biases and other major imperfections and really should only be used for seeding cryptographic PRNGs) Not all of the high-speed stream ciphers in use today meet the requirements for being a good PRNG, so care has to be taken when designing or selecting PRNG algorithms. One aso has to make sure to use adequate key lengths (e.g., a single- DES PRNG shouldn't be used to generate triple-DES keys and the PRNG state needs to be big enough!), seed update functions must remix the state completely, the PRNG must not cycle, etc. Other things can also go wrong -- for example, several applications have had PRNG failures because one of the most widely-used PRNGs has the property that seeding with seed block "A" followed by "B" is the same as seeding with "B" then "A". Seeding with a large number of low-entropy seed blocks thus produces a PRNG state with much less entropy than would normally be expected. Methods for collecting initial seed data are generally platform- specific and sometimes cause problems in crypto products (though most companies seem to have learned from Netscape's lesson). There are various approaches which can be used for seeding, but I usually combine seed material from three sources: event timing data (keystroke, mouse, etc.), the user's private key (or, better, a hash/HMAC of the private key) combined with the date/time, and state saved from last time the PRNG was used. Any one of the three should be enough to thwart attacks. Throwing in additional data from a random number server wouldn't hurt, though it also doesn't help since the data isn't generated and delivered in a secure enough manner. (You also have to be careful that the random server can't be used to compromise the PRNG!) As I mentioned before, it's usually fine to leave a PRNG alone once it's seeded, though occasionally it's useful to update the PRNG state periodically to ensure that past compromises of the state will get fixed automatically. However, in practice someone who can compromise the PRNG state can often just as easily compromise the PRNG software itself, so this is often overkill and just leads to a false sense of security. Paul ------------------------------ Date: Thu, 27 Mar 1997 13:26:02 -0800 (PST) From: Keith Price Subject: Computers in California Senate Today's (Thursday, March 27, 1997) LA Times reports on the use of computers in the State Senate -- The story begins: >Computers Bring Down Load of Trouble > Money: After spending $1.2 million on laptops, Senate is still relying on > what was to have been made obsolete--paper. > By CARL INGRAM, Times Staff Writer > > SACRAMENTO--In one of his first acts as the new leader of the Senate two > years ago, Bill Lockyer ordered the tradition-bound chamber into the > high-tech age by outfitting all 40 senators with laptop computers at their > desks. But, after spending $1.2 million, the Senate finds itself relying > on what was to have been made obsolete--paper. And goes on to report that at most 10 senators actually use the laptops. The cost was in 2 waves -- the first system no one liked ($750K), and the second one ($508K) with "cartoonish" graphics and a touch screen buttons. Complaints include, too hard to read (especially text of bills), and too slow when really needed (everyone needs it at the same time). It also reports the Assembly members are far more accepting of the simpler system installed there. (Available at least today online: http://www.latimes.com/HOME/NEWS/STATE/t000027706.html) Keith Price price@usc.edu ------------------------------ Date: Fri, 28 Mar 1997 09:56:31 -0500 (EST) From: David Pipes - Sun Education Subject: DC traffic-light sychronization problem On 28 Mar 1997, a local Washington DC radio station (WTOP) reported that the traffic lights at a downtown intersection (17th and Constitution) were green in all directions at the same time. This was reported by drivers calling in on cell phones, and was apparently recurring over at least a half hour during the rush hour. This is a very dangerous situation given the number of reckless driving incidents in the region over the last few months. I have not yet heard whether any accidents occurred because of this flaw. From earlier reports on the system, DC uses a sychronization system that "rolls" green lights down the major streets at a rate designed to control traffic. This implies that there is an overall plan to the layout, as manual control of so many lights should be nearly impossible. I'm very curious, given this assumption, as to how this situation occurred in the first place. I can understand that the timings could go into the wrong synchronization if they were being adjusted, but I had always thought that the default behavior in such situations should be to change all the affected lights to flashing red, which means "stop before proceeding". Are traffic light control systems built without this kind of safeguard? David Pipes robear@access.digex.net ------------------------------ Date: Thu, 27 Mar 1997 17:27:42 -0800 From: "J. DeBert" Subject: Re: all-ways green lights (DeBert, RISKS-18.94) (I received this by e-mail in response to the item I posted to RISKS. It is posted here with the author's permission but edited slightly to improve readability.) Date: Thu, 27 Mar 97 16:33:19 >From: "Robt. Miller" Subject: Re: all-ways green lights (DeBert, RISKS-18.94) Last year my family and I were coming home from somewhere or other and at an intersection noticed cars going slowly, some were stopped with people looking at the lights - sure enough, they were all green. Fortunately, someone noticed it, possibly because a 7/11 type store sat catercorner[*] to the light, enabling a view of both lights at the same time. This particular intersection hosted a state road and another heavily travelled road which, needless to say, should have been more tragic than it was. talk robtmil@cable019054.cable.eph.ptd.net [* Robert had "caddycorner". Webster's gives "catercorner" (with "cater" from quatre), or alternatively "kitty-corner" (presumably because "Kater" auf deutsch = our english "cat" -- ergo, a francogerman pun in English). The design doctrine that traffic lights must never be four-way green is therefore presumably "caterchism". PGN] ------------------------------ Date: Tue, 25 Mar 1997 22:37:06 -0800 From: sercanbrack@juno.com (Sean Ercanbrack) Subject: Re: all-ways green lights (DeBert, RISKS-18.94) A couple of years ago, I had an accident where a woman pulled out in front of me. I was heading home from work. My light was green, and she claimed her light had turned green also. (Note: The lights in this intersection were new and had only been installed weeks before.) There were no witnesses, so the police officer was not yet able to issue a citation--Both of us claimed to have the green light. He said he would need to get back with us when the fault was determined, probably later in the week. Both of our cars were drivable, so we left the accident scene. The next day, I was driving home from work again along the same route and approached the intersection where the previous day's accident scene had taken place. There, in the intersection was an accident that looked exactly like the accident I had been in the day before. I decided to pull over and ask them a few questions. Both of these accident victims claimed their lights had been green. Coincidence? I don't think so. Two different and yet identical accidents that occur at the same intersection at around the same time during the day, with all involved individuals claiming their light was green. This was a little too much for me. I ended up calling the investigating officer and my insurance company and telling them about this. (All of us involved in the accidents exchanged phone numbers). The police said they would investigate this. The funny thing is that the police later denied that there was a problem with the lights, yet for the next few days, they had repairmen out working on the lights in that intersection. I have since watched those lights carefully, but have never seen this occurrence happen again. ------------------------------ Date: Thu, 27 Mar 97 20:36 MST From: "Barak Pearlmutter" Subject: Re: all-ways green lights (DeBert, RISKS-18.94) A few years ago I learning something about actual traffic-control devices. The engineers are acutely aware of the issue of safety in the face of failures of both hardware and software, and the certification process in most countries requires documentation of careful attention to these issues. These devices are subject to very rough treatment: lightning, power spikes, shrapnel from automobile accidents, salt water. They are designed to fail safe: sturdy low level hardware interlocks (like relays and steppers) should prevent any software fault, and any hardware fault outside the interlocks themselves, from causing an unsafe configuration like all-green. Most faults in the interlock subsystem itself should put the device into a failsafe mode like all-blink-red. I'd think that the most likely cause of the nightmare all-green fault would be incorrect maintenance of the device, in which maintenance workers crossed wires or disabled interlocks. Someone from the manufacturer should have a very thorough look at the traffic control device involved in that accident in San Francisco. Barak A. Pearlmutter , http://www.cs.unm.edu/~bap/ Assistant Professor, Computer Science Dept, Univ New Mexico [As RISKS readers have observed, there is a big difference between "should prevent" and "do prevent". PGN] ------------------------------ Date: Thu, 27 Mar 1997 10:21:44 -0800 (PST) From: "Kevin A. Hogan" Subject: God, the sweepstakes winner Yet another example of direct-mail marketers' software failing to divine the proper form of address for their intended recipient (from _National Review_, 24 Mar 1997, p. 5): American Family Publishers sends Assemblies of God church in Bushnell, Fla., a sweepstakes notice: "God, we've been searching for you." If He wins, "what an incredible fortune there would be for God! Could you imagine the looks you'd get from your neighbors? But don't just sit there, God." Kevin Hogan kahogan@EECS.Berkeley.EDU (510) 664-2533 http://www-ucsee.EECS.Berkeley.EDU/~kahogan/ ------------------------------ Date: Thu, 27 Mar 1997 13:22:59 -0800 (PST) From: fc@ca.sandia.gov (Fred Cohen) Subject: Re: Crackers Obtained Gulf War Military Secrets (RISKS-18.94) It's not factually accurate. Dr. Eugene Schultz was never head of computer security at the U.S. Department of Energy - he was one of the people who started up the CIAC team at LLNL. That means he was a UC Berkeley employee. Quite a stretch if you ask me. I don't know about the rest of the story, but normally when one completely false statement appears, you can expect that everything else is likely to be tainted. [Fred Cohen can be reached at tel:510-294-2087 fax:510-294-1225] [The alleged Schultz quote is apparently something like 18 months old, and Gene has maintained in the past that he was grossly misquoted -- as I recall, he has claimed he never said that SECRET-level *classified* information was obtained, although by inference you might suspect that there could have been sensitive information, and that the aggregation of the UNCLASSIFIED information could have been deemed SECRET. (Gene is unavailable this week, so I cannot get a first-hand comment from him.) Unfortunately, to the unwashed, all DoD computer information seems to be called "secret" unless it is posted to a newsgroup or available on the Web. On the other hand, if any SECRET information had been disclosed, that knowledge would itself most likely have been classified SECRET -- in which case it wouldn't appear in RISKS until declassified! PGN] ------------------------------ Date: Fri, 21 Mar 97 9:34:09 -0500 From: "Rosenthal, Harlan" Subject: re: Y2K: revenge of originality (RISKS-18.90,92) "undocumented assembler code"? The assembler is not the problem. Shoddy practices are. I try to write assembler routines for a high-performance realtime embedded system using meaningful data structures and commented flow of control; I review C programs with constants named "STATE_1" and "STATE_2" and variables with single-letter names (and I don't just mean "i" for a loop) or names like "data". At least names like "temp" are vaguely honest. I forgot who wrote in CACM many years ago, regarding then-new languages like Pascal and Ada which supposedly enforced better standards, "One can write Fortran in any language". -Harlan Rosenthal ------------------------------ Date: Thu, 27 Mar 1997 14:49:35 MST From: "Richard Schroeppel" Subject: Y2k costs Martin Minow passes along a Swedish article estimating Swedish Y2K costs at $4000 per capita. I find many of the estimated Y2K costs hard to believe: Is the total cost of all software ever written this large? In the US, a similar estimate would put our Y2K cost at a trillion dollars. There is a real problem, but some people have made a business of exaggeration. A serious discussion of the costs might be warranted. I haven't looked at the report that MMs message points to. [Life is short. I don't read reports of flying saucers either.] Rich Schroeppel rcs@cs.arizona.edu ------------------------------ 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.95 ************************