precedence: bulk Subject: Risks Digest 20.82 RISKS-LIST: Risks-Forum Digest Monday 28 February 2000 Volume 20 : Issue 82 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at and by anonymous ftp at ftp.sri.com, cd risks . Contents: U.S. government abandons Bernstein restrictions (Jeremy Epstein) How to make friends, influence hackers, and build bugfree code Paris style (Peter Wayner) Someone making sense about e-commerce (Paul Robinson) The Millennium Bug Revisited (R A Downes) It was just a network board... (Debora Weber-Wulff) Risks of National Weather Service tests (John O Long) Re: Microsoft responds (R A Downes) Re: Great West gives out too much personal info (Taylor Hutt, Bob Hofkin) Imbalanced parentheses or angle brackets (W.T. Shymanski) "Unstable" postal addresses (Joseph A. Dellinger) REVIEW: "Security Technologies for the World Wide Web", Rolf Oppliger (Rob Slade) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Thu, 24 Feb 2000 17:04:37 -0500 (EST) From: Jeremy Epstein Subject: U.S. government abandons Bernstein restrictions In light of the new export restrictions, the Commerce Department has abandoned all claims that Prof. Daniel Bernstein is restricted in posting his Snuffle encryption source code to his web site, according to a Reuters article at http://www.wired.com/news/politics/0,1283,34550,00.html . However, the article says "'We are still considering our options,' said Cindy Cohn, Bernstein's lawyer. Cohn said the Commerce Department letter failed to clear up some questions about the new rules." [See PGN note below.] --Jeremy [The *Wall Street Journal* 25 Feb 2000 noted that the residual questions are on areas of ambiguity such as mirror sites and a restriction on access in countries suspected of supporting terrorism. PGN http://interactive.wsj.com/articles/SB951422940442620073.htm] ------------------------------ Date: Sat, 26 Feb 2000 10:36:22 -0500 From: Peter Wayner Subject: How to make friends, influence hackers, and build bugfree code Paris style The *Times* (London) reported on 26 Feb 2000 that Serge Humpich, a hacker, was convicted of fraud and given a suspended sentence. The young man discovered how to trick the Carte Bleue system and claimed he could have gone on an unlimited spending spree. Instead he hired lawyers and negotiated with the company that runs the system for payment in return for detailing the problems. The company turned around and prosecuted him for fraud after they arranged for him to demonstrate the system. What a brilliant way to discourage folks from rooting around in a system _and_ reporting security flaws! I wouldn't be surprised if their system proves to be so impervious that the number of bug reports drop to zero. What a wonderful solution for creating bugfree code! ------------------------------ Date: Wed, 23 Feb 2000 08:45:03 EST From: Rfc1394a@aol.com (Paul Robinson) Subject: Someone making sense about e-commerce When we think about the risks of technology, we often think about the risks to life and property. But the risks of technology are caused because people don't think about the possible consequences of relying on technology. Sometimes it does good but if you don't know when technology isn't the solution you're taking a big risk. In the following link, the CEO of Liz Claiborne, Paul Charron, explains why he's not jumping whole hog into Internet sales. It's a breath of fresh air in the otherwise rarefied atmosphere of the e-commerce market to hear from someone who has seriously thought about what he's doing: http://www.computerworld.com/home/print.nsf/CWFlash/000221EDB2 It shows that he understands the risks of trying to spend several million dollars on setting up a web site to sell something when it might not create profitable returns for 20 years or might merely cannibalize brick-and-mortar sales. If a few more people had thought about this, maybe we wouldn't have an Amazon.Com and 200,000,000,000,000,000 other on-line commerce sites losing tens of millions of dollars every year. Okay, so I'm exaggerating (but not by much). Has anyone ever thought about the fact that in general, the only web sites that are consistently making money are the ones dealing in pornography? This brings new meaning to the term, "obscene profits". :) Paul Robinson http://paul.washington.dc.us ------------------------------ Date: Wed, 23 Feb 2000 20:46:11 +0000 From: main@radsoft.net Subject: The Millennium Bug Revisited Y2K is here and on a roll: things went better than expected; Clinton's administration is declaring a total victory. The real Millennium Bug - Windows 2000 - has had much worse luck. Further, it is now apparent that there are two such bugs: the operating system itself, and the hype campaign now introduced to get us all to once again jump on the merry bandwagon of planned obsolescence and upgrade to it. None other than Paul Thurrott of Windows NT Magazine has declared, after admitting that a lot of Win2K, such as tooltips that not only "display" as before, but now "roll in" and "roll out", is "fluff" and no more, that these supposed enhancements are "good for the end user". It remains a mystery, however, to both the undersigned and many more, how a rolling tooltip can be regarded as a substantial end user improvement. Sanity. Keeping a level mind. Let's remember that the shortest distance between two points in this case, the distance between what a user wants and what the operating system does to the hardware, has not increased by one iota. File operations are still file operations (encryption on disk an option and not a requirement); video RAM updates are identical; everything in fact is the same. There is no reason whatsoever for any of these basic operating system functions to require more hardware - CPU speed, disk space, RAM - to work. There is no reason for the operating system to exhibit the extreme sluggishness it does. "When things get too slow, we just throw more hardware at it." This, the "Rule of Redmond", obvious everywhere in Redmond code, is especially prevalent in the code of Windows 2000. And while it is an affront to our collective human intelligence to expect to be able to sell us on the assumption that the same operations which ran so fast on previous versions can suddenly run so agonizingly slow with even twice or four times the processing power on this one, it is not without our collective human imagination to understand - or even predict - why and how this "fluff" - this _junk_ - can have that effect. When things deteriorate to the point where a major Internet authority slips into saying that rolling tooltips make matters better for an end user, then we know we have been hit - by the second of the lethal Millennium bugs. Windows 2000 has not at all received the welcome Redmond would want. Long before its release the Microsoft Windows 2000 Redeployment Program fell completely apart. ISVs and OEMs and major corporations everywhere, after seeing the frightening wave of the future with the betas, decided to jump ship. Polls conducted as recently as days before the official release of Windows 2000 indicate most of these same corporations naturally have no inclination whatsoever to upgrade to Win2K and even less inclination to take it into consideration when writing new software. So Microsoft has been hard put. And, to make matters worse for them, a Finn has entered their arena, becoming a nemesis that they fear more than we can ever really appreciate. Microsoft is not making inroads in the net server market, and this must hit them hard too, as do relations with the DOJ in Washington. So under the circumstances, watching Microsoft do its little propaganda dance, and now do it a bit more openly and a bit more brazenly than in the past, makes an interesting study indeed. Maybe we didn't really notice last time around - if you reckon the inception of Windows 95 as "last time" - the kind of hype we do today. Maybe it was there and we just didn't notice it. But today, most likely because of the circumstances, it seems to stand out more: - We're told that this is the best product Microsoft has ever released (there's a noticeable echo on this one: we've heard it before, and been gravely disappointed before too - what else can we expect them to say). - We hear things like "we really love this product". Over and over again. The power of suggestion, of repeating the "big lie", has become a weapon in the Redmond camp. - We're told Win2K runs faster than both 95 and NT 4 on the kind of hardware running 95 and NT 4 today, when we've all seen that the contrary is true. - Supposedly independent computer science authorities are heard to mumble incredible things such as those mentioned above. (Another gem came about in the wake of the rumour that Win2K has over 60,000 bugs: suddenly these "authorities" are claiming that none of these bugs will ever be noticeable by end users). We know that not all these dupes are on the Microsoft payroll. We don't assume, to paraphrase Lyndon B. Johnson, that Microsoft has everyone's CPU in their pocket. But we do see that the cult of mania begun by Microsoft with the release of Windows 2000 is spreading, and that many individuals who normally consider themselves sane and level headed are unwittingly acting as dupes of the International Microsoft Conspiracy of planned obsolescence. This seems somewhat borne out by the fact that Microsoft even attempted to keep good old NT 4 away from ISVs involved in their development network (MSDN). It is borne out by the fact that several key NT applications (such as File Manager) have been deliberately sabotaged by the Win2K team. And further evidence of Microsoft's desperation might be upon us before this letter is even sent. Let's get this absolutely straight: no one "needs" Win2K. There is nothing inherent in Win2K that we have been desperately longing for. No advocate of Win2K can come with a long and impressive list of enhancements that have been conspicuous in their absence from Windows NT. All we really know is that Microsoft has decided, as so often in the past, that it is time again for their "out with the old and in with the new" marketing coup. Even Intel's claims that Win2K is horrendously slow, so slow that they themselves need to invest in new hardware for $50 million, must be taken with a grain of salt. There is no way Microsoft will ever tell us the truth: they were not going to admit that Windows 95 was a RAM hog and needed four times the CPU speed and RAM as its predecessor, and they are not going to admit that Windows 2000 doubles even that multiplication figure. No, they are going to let us figure this all out by ourselves: the more processors they can help Intel and others sell the better. Look at Michael Dell: in one breath he fells a comment about Windows 2000 which sends Microsoft stock plummeting; in the next he tells of his decision to run his web site with it. So there's a second bug here all right, almost more dangerous than the first and a lot more contagious. And there are no known vaccination serums available. RA Downes Radsoft Laboratories http://www.radsoft.net ------------------------------ Date: Mon, 28 Feb 2000 13:15:52 +0100 From: Debora Weber-Wulff Subject: It was just a network board... (Re: RISKS-20.75) The Berlin Fire Department has found the culprit! RISKS readers recall the problems the Berlin Fire Department had starting 4 minutes after midnight on 1 Jan 2000: The dispatching system went awry, believing that fire trucks were in places they weren't, dropping emergency calls on the floor, confirming dispatches that never were forwarded, etc, etc. In anticipation of Leap Day they have been busy testing and testing the system. Lo and behold, they can repeat the behavior for 29 Feb 2000. It turns out that a handful of network cards, costing about $50 a piece, were not able to handle either date, and were generating erratic packets. Replacing the boards has fixed the problem, according to *Der Tagesspiegel*. [http://www.tagesspiegel.de/archiv/2000/02/24/ak-be-st-32899.html] The police union criticizes that this system behavior had been observed before, but no one ever bothered to find the source of the problem. The police ended up fighting fires with water cannons instead of the fire department using all those shiny new fire engines they bought from a German automotive company after the fire chief was lent a nice car from the same company. Prof. Dr. Debora Weber-Wulff, Technische Fachhochschule Berlin weberwu@tfh-berlin.de, http://www.tfh-berlin.de/~weberwu/ ------------------------------ Date: Mon, 28 Feb 2000 13:12:33 -0500 From: j1long@us.ibm.com Subject: Risks of National Weather Service tests Today, I was checking the weather on the MyYahoo web page I have created. I noticed that there was a red asterisk by the listing for the city I live in. The red asterisk is denoted as meaning "severe weather alert". This was strange, since the forecast summary showed a sun, indicating a clear, sunny day. I clicked to get the full weather report, which indicated a normal sunny day, but a clickable line that said "severe weather alert". I clicked on the severe weather alert to find the following: ALAMANCE, ANSON, CHATHAM, CUMBERLAND, DAVIDSON, DURHAM, EDGECOMBE, FORSYTH, FRANKLIN, GRANVILLE, GUILFORD, HALIFAX, HARNETT, HOKE, JOHNSTON, LEE, MONTGOMERY, MOORE, NASH, ORANGE, PERSON, RANDOLPH, RICHMOND, SAMPSON, SCOTLAND, STANLEY, VANCE, WAKE, WARREN, WAYNE, WILSON, INCLUDING THE CITIES OF BURLINGTON, CHAPEL HILL, DURHAM, FAYETTEVILLE, GOLDSBORO, GREENSBORO, RALEIGH, ROCKY MOUNT, 925 AM EST MON FEB 28 2000 ...FROM THE NATIONAL WEATHER SERVICE...THIS IS A TEST HIGH WIND WARNING ONLY... THIS IS ONLY A TEST. It would appear that the text scanner that looks for severe weather announcements is unable to determine when it's only a test. The risk is probably very small. However, as more and more people rely on automated reporting data from various sources, we will find that many of these sources were not really created for direct pass-through of information. Direct, live testing of systems such as the National Weather Service is important, but unless this is carefully handled by vendors on the web, we could have a lot more miscues sent to the general public. John O Long/Raleigh/IBM@IBMUS, j1long@us.ibm.com Programming Consultant, Solution Architecture and Reuse 919.993.4208 ------------------------------ Date: Tue, 22 Feb 2000 01:20:08 +0000 From: main@radsoft.net Subject: Re: Microsoft responds (Allchin, RISKS-20.80) Tom Sheppard writes of a possible 63,000 bugs in Win2K. Tom is still the Titanic in search for the tip of an iceberg. The internal rule in Redmond is "4 bugs per KLoC". Ok. A KLoC is 1000 (or 1,024) lines of code. Windows NT was only 16 million lines of code. Piece of cake. But Windows 2000 - without the likes of Cutler, without being a direct copy of VMS and Prism - is four times that size. Written by people with a fraction of the talent. We're talking about 50,000 or 60,000 KLoCS. Microsoft themselves say 4 bugs per KLoC. Go figure. ...and I think we must remember that we can never have a debate on the merits or shortcomings of Windows 2000. On the one side we have inquisitive minds authentically attempting to arrive at the truth, on the other we have the clever minds of those like Alchin who are simply trying to sell a product by any means. Windows 2000 will always be the best and most stable and fastest and most loved product ever. It will run faster on a Z80 than CP/M. We will always really love this product. RA Downes Radsoft Laboratories http://www.radsoft.net ------------------------------ Date: Fri, 25 Feb 2000 06:24:52 GMT From: Taylor Hutt Subject: Re: Great West gives out too much personal info (Hutt, RISKS-20.80) Last week I submitted a message about Great West giving away too much information (Name, birthdate, SSN, account number) in a confirmation letter regarding a change-of-address. I spoke to the person in charge of the account (Nancy Lynch) and she indicated that a meeting with management was to be held this week; she would raise the issues and get back to me. Well, I'm here to report that she did get back to me and has informed me that Great West will not be putting the SSN of a person on any correspondence effective immediately. Further, they will be doing a systematic review of all correspondence to determine which information is actually pertinent to that correspondence. (She even offered to keep me up-to-date with their progress on that, but I told her I didn't think that would be necessary) I am pleased at the speed which Great West has addressed this situation and am once again invigorated to believe that it is possible to change the system. Hats off to Nancy for carrying through so well on this one. Taylor Hutt ------------------------------ Date: Sun, 27 Feb 2000 14:46:40 -0500 From: Bob Hofkin Subject: Re: Great West gives out too much personal info (Hutt, RISKS-20.80) Taylor Hutt wrote about his 401(k) company mailing out all of his account identifying information in one letter. I had a similar problem with Cigna a couple of years ago. They convinced our HR Person to have them send out letters with lots of personal identifying information, and a pitch to sign up for their on-line service, Neither the HR Person nor any of the Cigna reps I spoke with seemed to understand that anyone who intercepted the letter could commandeer my account. Cigna claimed the system met their internal security guidelines(!!) and besides, even if something did go wrong, I would see it on my quarterly statement and they would be happy to fix any problems. I can just imagine the phone rep: "Sure thing, we'll be happy to move that $100,000 right out of the fund that lost 2% and back into the one that made 24%, and of course we'll make that retroactive. So sorry to inconvenience you in the least." Perhaps this is standard procedure in the industry. I was surprised at the lack of security awareness and the lack of concern. One comment that was no surprise: "You're the first person who ever complained about this." ------------------------------ Date: Mon, 21 Feb 2000 19:29:27 -0500 From: "W. T. Shymanski" <"nski\" Subject: Imbalanced parentheses or angle brackets I had the misfortune last week to photocopy a customer request for proposal document that I needed to work with. While frantically trying to put the proposal out before the deadline, I noticed the requirements seemed a little sketchy in parts; examination of two pages showed that the set of points was numbered 1,2...big white space at bottom of the page...5,6 on the next page. It turned out that our digital Pitney-Bowes photocopier had developed a problem where it would not print the bottom half of a page. For spreadsheet pages printed in landscape format the error was quite prominent, since the left-hand-side of the page was blank. But for regular portrait-mode text, it was only because the following page had paragraphs numbered out of sequence that I even noticed the problem. The risks are pretty obvious: potentially the difference between profit and loss on any given contract might hinge on a paragraph at the bottom of a page, which the digital photocopier might softly and silently eat without trace. Normal analog-type photocopiers in my experience don't make *this* type of foul-up. Bill Shymanski ------------------------------ Date: Mon, 21 Feb 2000 20:46:49 -0600 (CST) From: "Joseph A. Dellinger" Subject: "Unstable" postal addresses My street address has a letter on the end to make it unique: "123D Memorial Street". This works fine for mail delivery, it's what is engraved on the mail boxes, and is more concise than "123 Memorial Street Apartment D", so when I moved in "123D" is what I handed out as my new address. Big mistake! While that address will work for a while (months), eventually the businesses whose job it is to mail out magazines, notices, offers, etc, will run clever software over their databases to "correct mangled addresses". When that happens, the "D" on the end gets deleted as an "error", or (worse) changed into a "0". While mail addressed to "1230" usually arrives, when presented with an address of "123" and a row of letter boxes marked "123A", "123B", "123C", "123D", ... the mail carrier will often just pick a random box to deliver the mail to. This took a while to figure out. All I knew was that the amount of mail I was getting seemed to be exponentially decaying. Calling up the magazines to ask "are you sure you still have my address correct?" didn't work: in their databases the "D" is invariably still there. Eventually some of my own mail without the "D" ended up arriving in my box, so I was able to figure out what was happening. So now I have to call up everyone sending me mail and change my address to put the "Apartment D" on a separate line, where it is apparently stable. Even so I bet my neighbors will be getting all sorts of junk mail meant for me for months to come. The risks? Software that is overly aggressive in "fixing" addresses. The address the subscription services people see in their computer is not the same as the one that is actually used (and they don't even realize it's not the same). No error message being returned by the post office saying that the address without the letter _can_ be delivered, but not _reliably_. Purging all the "123 no D" addresses now existing in hundreds of databases out there will be just about impossible. ------------------------------ Date: Tue, 22 Feb 2000 10:49:32 -0800 From: Rob Slade Subject: REVIEW: "Security Technologies for the World Wide Web", Rolf Oppliger BKSCTCWW.RVW 20000113 "Security Technologies for the World Wide Web", Rolf Oppliger, 2000, 1-58053-045-1 %A Rolf Oppliger rolf.oppliger@acm.org,oppliger@computer.org %C 685 Canton St., Norwood, MA 02062 %D 2000 %G 1-58053-045-1 %I Artech House/Horizon %O 800-225-9977 fax: 617-769-6334 artech@artech-house.com %P 419 p. %T "Security Technologies for the World Wide Web" In the preface, the author states that the book is first intended for Webmasters, who need practical configuration information, then for users who have security concerns, and finally for Web and electronic commerce developers. He also says that the book can be used as an introduction, for self-study, as a course text, and as a reference. A pretty tall order, but, by and large, Oppliger does a reasonable job of fulfilling the entire mandate. Chapter one, as an introduction, is possibly more than most people want to know. However, the extra information (such as the explanation of HTTP [HyperText Transfer Protocol] requests and responses) does help provide an understanding of the underlying actions and concepts which are needed for a thorough view of security operations and requirements. There is a detailed presentation of HTTP access control methods in chapter two. The introduction to firewalls, in chapter three, is complete and helpful, with a wealth of user level information that is all too often omitted. Chapter four is a solid introduction to the basics of cryptography. Channel security at the data link, transfer, and application layers is the theme of chapter five, touching on tunneling, VPNs (Virtual Private Networks), IPsec, and various application protocols. Chapter six expands two of these with details on the Secure Sockets Layer (SSL) and Transport Layer Security (TLS). Chapter seven gives an overview of electronic payment systems, with brief descriptions of the most common electronic cash, debit, and credit schemes. The management of certificates, in chapter eight, mostly covers ongoing work in key infrastructure, with a good discussion of the important and difficult question of certificate revocation. A fair and realistic review of active content is provided in chapter nine. For slightly less active content, chapter ten discusses and shows examples of more secure practices for CGI (Common Gateway Interface) and API (Application Programming Interface) work. Mobile code and agents are still really future technology, and so are the proposed security functions in Chapter eleven. The copyright discussion in chapter twelve is a little disappointing, since it seems primarily concerned with watermarking. Chapter thirteen looks at privacy, being dealt with by amateurs as usual, and, as usual, providing glimpses of fascinating work that is not widely known. There is a brief overview of censorship systems and problems in chapter fourteen. Chapter fifteen concludes with a somewhat pessimistic review of the situation. The bibliographies at the end of every chapter contain solid works, and can be useful to those wanting further information. They do, however, have a very definite academic flavour, in that most of the entries are articles or conference presentations, with books and online references making up a smaller portion of the whole. Oppliger's writing is rather dry and academic in tone, but the material presented is realistic, useful, and conceptually complete. Despite the disparate audience range, the author has managed to provide something of value for all. For the Web workers who are the primary audience, this book provides, if not a cookbook for security, a complete picture of the various aspects that must be addressed. copyright Robert M. Slade, 2000 BKSCTCWW.RVW 20000113 rslade@vcn.bc.ca rslade@sprint.ca slade@victoria.tc.ca p1@canada.com http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade ------------------------------ Date: 13 Dec 1999 (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. Alternatively, via majordomo, SEND DIRECT E-MAIL REQUESTS to with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] .MIL users should contact (Dennis Rears). .UK users should contact . => The INFO file (submissions, default disclaimers, archive sites, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to 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 [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 19" for volume 19] or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. Also, new AUSTRALIAN archives at http://mirror.aarnet.edu.au/risks/ and http://the.wiretapped.net/security/textfiles/risks-digest/ . PostScript copy of PGN's comprehensive historical summary of one liners: illustrative.PS at ftp.sri.com/risks . ------------------------------ End of RISKS-FORUM Digest 20.82 ************************