precedence: bulk Subject: Risks Digest 21.25 RISKS-LIST: Risks-Forum Digest Weds 21 February 2001 Volume 21 : Issue 25 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: Millennium bug in travel agent system (Debora Weber-Wulff) Again: German government plans extensive surveillance (Stefan Kelm) Are free ISPs free? Juno says users must donate processor time (Lenny Foner) The old ones are the best ones: Hidden info in MS Word documents (Paul Henry) Modem misdialing seemingly at random (Chiaki Ishikawa) On paper-size standards (Andrew Klossner) More on the Friendly Skies of United (Steve Bellovin) Re: Risks inside my Jan 2001 American Express Bill (Paul Green) Re: SiteGuest unauthorized address capture (Jean-Jacques Quisquater) Re: Organiser Bugs (Dennis Parslow, Peter B. Ladkin) Re: It's the wolf! It's the wolf! (Martin Jost, Andrew Jackson) When will they EVER learn? (Geoff Kuenning) REVIEW: "Building Internet Firewalls", Zwicky/Cooper (Rob Slade) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Wed, 21 Feb 2001 08:18:04 +0100 From: Debora Weber-Wulff Subject: Millennium Bug in Travel Agent System A friend with a travel agency sent me an article about the German Travel Reservation System Merlin. It seems that all the reservations made through the system were not credited to the January 2001 account, but to the January 2000 account. The problem was that Merlin was sending data to a back office system from Bewotec. Merlin, however, had not managed to change the year from 00 to 01. A speaker remarked: We didn't know that someone else was using the data too [for statistical purposes], but it is not a real problem, as no other cooperating systems have reported problems [!!!] "Only" 200 travel agencies are affected, the ones that use Bewotecs Jack and Merlin from DCS. Gee, that makes me feel better, then, if no one else has complained ... Prof.Dr. Debora Weber-Wulff, Techn. Fachhochschule Berlin, Luxemburger Str. 10 13353 Berlin, Germany weberwu@tfh-berlin.de http://www.tfh-berlin.de/~weberwu/ ------------------------------ Date: Wed, 21 Feb 2001 09:47:49 +0100 From: "Stefan Kelm" Subject: Again: German government plans extensive surveillance Once again, plans by the German government to force ISPs to install surveillance interfaces for LEA access became known earlier this week. This is the third draft already, and a few things have changed. Interestingly, the government itself (i.e., the Federal Ministry of Economics and Technology) has published the new drafts, which up to now are only available in German: http://www.bmwi.de/Homepage/Politikfelder/Telekommunikation %20%26%20Post/Telekommunikationspolitik/Sicherheit.jsp#TKÜV [broken URL, and may not work anyway... PGN] Stefan Kelm, Secorvo Security Consulting GmbH, Albert-Nestler-Strasse 9, D-76131 Karlsruhe +49 721 6105-461 kelm@secorvo.de, http://www.secorvo.de ------------------------------ Date: Fri, 2 Feb 2001 12:01:36 -0500 (EST) From: Lenny Foner Subject: Are free ISPs free? Juno says users must donate processor time See section 2.5 of http://help.juno.com/privacy/agreement.html There are obvious privacy implications of being "volunteered" in this manner (hey, whaddya want for nothin'?). There are also obvious security implications, since Juno says absolutely nothing about what this distributed computation might be. ("Hi, we're Microsoft and we'd like to run a distributed computation that looks for duplicate copies of serial numbers in our products, and your user agreement says that we can format the disks of any machines that might possibly be infringing. Actually, we'd also like to format any disks that seem to have non-Microsoft operating systems installed.") I'm also rather intrigued by their "we will run screensavers with ads and you're not allowed to turn off your machine." Seems to me that this will cost users -lots- of extra electricity if they're used to a screen saver that blanks the monitor and puts it in a low-power mode---and obviously the -computation- doesn't require the -screen- to be displaying anything; that's only the advertising function... And I'll bet there's some reasonable subset of users who don't know that they can turn off just the monitor, or don't realize that they're saving power when their screen blanks... With a "free" base of 14.5 million subscribers, and 100W/monitor (probably an underestimate), this is an entire nuke plant of extra load just to keep those monitors from screensaving. I'll bet that's just -exactly- what California wants to be happening right now... - - - Begin forwarded message - - - Date: Fri, 02 Feb 2001 10:17:25 -0500 >From: Declan McCullagh Subject: FC: Are free ISPs free? Juno says users must donate processor time [As one science fiction writer would say, TANSTAAFL. This is merely the natural evolution of the market for "free" services, and is hardly objectionable. True, it raises some privacy and security questions, but nobody's forcing you to use Juno, and pay ISPs are hardly expensive. --Declan] http://www.cluebot.com/article.pl?sid=01/02/01/2249220&mode=thread How Free Are Free ISPs? posted by vergil on Thursday February 01, @05:06PM from the check-that-clickwrap dept. Free ISPs have been especially hard hit by the current dot-com downturn. Juno Online Services (recently smacked by a Temporary Restraining Order involving a patent infringement scuffle with rival NetZero) has developed a novel way of extracting megahertz -- and potential megabucks -- from its subscriber base. According to a 2/1/2001 InternetNews article, Juno's "Virtual Supercomputer Network" aims to replicate the success of SETI@home by pooling the processing potential of its new subscribers and selling the combined computational power. According to Juno's new service agreement, Juno's subscribers "agree" to let Juno download, upload and run software from their PCs, and may be required "to leave" their computers "on at all times." [...] [Lenny later added the following note. PGN] Actually, given that it -could- be the case that such a distributed computation might be set to initialize every machine at a particular time, I can just see it now when all those zillions of monitors come out of screen-save simultaneously: "California power grid destabilized by Juno, news at 11..." (Even an earthquake doesn't move mice all over the state...) ------------------------------ Date: Fri, 16 Feb 2001 16:03:49 -0000 From: "Paul Henry" Subject: The old ones are the best ones: Hidden info in MS Word documents OK, this is an old one (dating back to 1994 according to the RISKS archive), but it was new to me when I came across it recently, and thought people might be interested in a couple of real life scenarios: I received an MS Word document from a software start-up regarding one of their clients. Throughout the document the client was referred to as "X", so as not to disclose the name. However I do not own a copy of Word, and was reading it using Notepad of all things, and discovered at the end the name of the directory in which the document was stored -- and also the real name of the client! I checked on a number of other word documents I had for hidden info, especially ones from Agencies who are looking to fill positions -- and yes, again I was able to tell who the client was from the hidden information in the documents. Finally, I had a look at the Lockerbie Judgment document: http://www.scotcourts.gov.uk/html/lockerbie.htm Hoping to find something that would cause international uproar -- alas, no, just an ironic hidden message: "Are you surprised?". Yes, I was, actually -- I thought Ahmed Jibril did it. Risks: What potentially damaging information is hidden in published documents in Word, PDF and other complex formats? Mitigation: Use RTF when you can -- no hidden info, no viruses. Paul Henry, emmo@hotmail.com ------------------------------ Date: Tue, 6 Feb 2001 20:28:13 +0900 (JST) From: Chiaki Ishikawa Subject: Modem misdialing seemingly at random Modem misdialing seemingly at random RISKS has seen its share of mis-configured modem setup forced PCs calling somebody's house (in some cases police station?) unintentionally at random. Here is a new twist from Japan. Modem chips used in about 6 million PC units of 24 million PCs shipped in Japan after the summer of 1998 has shown a peculiar problem. When the modem is asked to dial telephone line using so called "Pulse Dial" mode, it fails to properly dial the requested number, and instead calls wrong number (!) seeming at random under high load of the OS (Windows 98), Pulse dialing (as opposed to tone dialing) is used in many Japanese telephone subscriber lines. How many users of the affected 6 million units use pulse dialing is anyone's guess: one educated guess puts the number at about 2 million users. This high concentration of the pulse dial telephone subscriber lines in Japan has caused quite a problem with the modem. I noticed that a large Japanse ISP, @nifty, (URL: www.nifty.com) has been warning the user for quite some time by sending periodic warning and mentioning various manufacturers comments, whose PCs may or may not dial incorrectly sometimes. This happened since early last summer if I recall correctly. *Mainichi Shimbun* newspaper Web site lately announced the problem in its IT-related Web page and it mentions the following PC manufacturers whose products are affected: Fujitsu, NEC, Toshiba, Sony, Japan IBM, Hitachi, and Epson. http://www.mainichi.co.jp/digital/index.html (in Japanese) Gateway Japan was quoted as investigating the situation, and it seems that Apple didn't answer the inquiry from the newspaper yet. The problematic symptoms occur under windows 98. It seems that the modem tries to use the software timing to produce proper number of pulses per seconds to generate correct dialing signals. However, obviously, Windows 98 can't let the software driver have enough CPU time under high load, and the software timing becomes bogus, thus the wrong dial number. Some people have receive these bogus calls many times and it seems that their tenacity uncovered the problem. The modem chip in question is build by Conexant. Their Web site mentions that the drivers ought to be provided by their OEM customers, which makes sense. (Warning: before trying to access Conexant Web site, you might want to check out your browser's cookie setting. The Web site tries to set many cookies as if there would be no tomorrow. I had enabled "Warning before accepting cookies", and I had to kill my browser! I had to disable the warning to access the URL. My browser is Netscape. YMMV. ) Affected PC manufacturers have begun offering modified drivers that add "dial number verification step"(?) according to Mainichi Web page. (From what I gathered by reading an attached file from IBM Web site, the driver checks the system load before dialing and if it expects that the load is too high to perform pulse dialing reliably, it aborts the dialing and hangs up. Various PC vendor sites mention that the cause of the high load is mentioned: CD drive, FDD, HDD, etc..) Although the mis-dialing is reported to occur very rarely per modem, the problem seems grave enough and the affected PC vendors and one industry association obviously sends a joint press release to let the users become aware of the new modified drivers. If you have 2 million users trying to dial the access points of the ISPs, my guess is that the incorrectly dialed numbers tend to fall in a select few ranges and thus irate complaints. Tone dialing users are not affected at all. (I wonder if the same problem may be observed elsewhere where pulse dialing is used by a large user base and the same Conexant chips are widely used. The Mainich page left the impression that pulse dialing is not used widely anymore.) Chiaki Ishikawa Personal Media Corp. Shinagawa, Tokyo, Japan 142-0051 ishikawa@personal-media.co.jp.NoSpam ------------------------------ Date: Fri, 26 Jan 2001 10:58:37 -0800 From: Andrew Klossner Subject: On paper-size standards (Re: Kuhn, RISKS-21.21) Markus Kuhn, in writing about ISO standards for numbering weeks, also makes mention of a reference to ISO paper sizes, which includes this statement: "Conversion to A4 as the common business letter and document format in North America would not cause any significant cost." This pronouncement considers only the cost of computing equipment such as printers. It ignores the substantial amount of non-computer infrastructure. As one example, my neighborhood elementary school has hundreds of three-ring binders and clipboards as well as non-metric paper trimmers, book binders, hole punchers, and ancient duplicating equipment. Anyone familiar with the state of U.S. public education understands that money to convert all this to metric paper sizes will not be available in the foreseeable future. The RISK here concerns enthusiasm for elegant technical solutions which overlook the cost of abandoning current practice. Other disparaging remarks, such as the "bizarre" way that we norteamericanos measure paper density, would perhaps be more compelling if they did not come from an island where everyone drives on the wrong side of the road. Andrew Klossner (andrew@teleport.com) ------------------------------ Date: Mon, 19 Feb 2001 22:38:23 -0500 From: Steve Bellovin Subject: More on the Friendly Skies of United (RISKS-21.24) I just saw an update on CNN that says United Airlines has decided to honor the tickets [purchased on their Web site, e.g., for less than $30 -- instead of $300... PGN]. Steve Bellovin, http://www.research.att.com/~smb ------------------------------ Date: Tue, 20 Feb 2001 10:00:33 -0500 From: Paul Green Subject: Re: Risks inside my Jan 2001 American Express Bill I can provide the likely answer to Thomas Maufer's question as to how the dates became corrupted on his American Express bill. First, I have no connection with American Express (other than as a long-time holder of several of their cards), so this is an educated guess. But I have been the Y2K coordinator for one of the Stratus Computer operating systems. We warned our customers in December 1999 that if they continued to use 2-digit years after January 1st, 2001, they might into the precise interpretation problem described in Thomas's letter. The details are specified at ftp://ftp.stratus.com/pub/vos/doc/y2k/sray2k21.htm. I have no idea whether this error arose on one of our products, or on a different vendor's product. When a date in the format MM DD YY is converted using a rule in the format YY MM DD you will get exactly the conversion noted in this report. 01-02-01 is interpreted as 2001-Feb-01 rather than Jan-02-2001. 01-04-01 is interpreted as 2001-Apr-01 rather than Jan-04-2001. and so on. Things will get interesting after January 12th; I wonder what Thomas's bill looks like for items charged on the 13th and beyond? Who would have thought that computers would be susceptible to triskaidekaphobia! Paul Green, Stratus Computer, 111 Powdermill Road, Maynard, MA 01754-3409 Senior Technical Consultant TEL +1 (978) 461-7557 FAX +1 (978) 461-3610 ------------------------------ Date: Fri, 16 Feb 2001 10:56:27 +0100 From: Quisquater Subject: Re: SiteGuest unauthorized address capture (Russell, RISKS-21.24) http://www.privacyfoundation.org/advisories/advEmailWiretap.html gives an exploit that allows the spying ("wiretap") of written messages and used addresses when forwarding privately a received message with embedded code ... Jean-Jacques Quisquater ------------------------------ Date: Wed, 21 Feb 2001 06:46:49 -0500 From: "Parslow, Dennis" Subject: Re: Organiser Bugs (Ladkin, RISKS-21.21) Peter Ladkin points out the difficulty in discovering and recovering from slow corruption of data. In fact, in some sense, the most dangerous computer viruses are the ones (thankfully relatively few) that simply flip characters, slowly and at random. One of the first of these did so in Excel Spreadsheets...where two characters being flipped can clearly have a huge impact further along in calculations. This also calls into light the backup strategies being used. Many keep their regular backups for approximately a month, and may or may not keep a full backup for longer. But if the problem was two months ago, give or take, many places that even do keep monthly backups may not have the information available to them from the incrementals in between, and a lot changes in a month. But management of more tapes may not be practicable in a large environment either... ------------------------------ Date: Wed, 31 Jan 2001 08:26:21 +0100 From: "Peter B. Ladkin" Subject: Organiser Failures (RISKS-21.18,19,21.23) Unfortunately, it seems as if the good points about backup housekeeping made by Tyler Rosolowski and Mike Cepek (RISKS-21.23) miss the main point that I tried to convey. My experience showed that devices can fail "live", with what I called a disgraceful degradation. I have no evidence of any misbehavior from the backup software (although this is not ruled out). The measures suggested by Rosolowski and Cepek are appropriate as protection against one-time catastrophic events. It is unclear to me how they would protect against my type of failure. Although Rosolowski's point about making regular comparisons between new data and old data is well taken, he doesn't suggest any time interval at which the differences might have overcome my perceptual threshold for noticing problems. Indeed, it is hard to see how he could, for the general case. Mike Cepek suggested there were two main differences between his case and mine, but omitted what I suggested is the crucial feature. As measures against failure, the suggestions from both contributors fall into the category of "good housekeeping" (GH). There is a general problem with such methods. Car drivers know that, for each accident, there is at least one prophylactic measure that would have avoided that individual accident; the problem is to devise one single measure that would avoid every accident. For backups, this is a solved problem. Backups are an example of a dependable database. There are algorithms well-analysed in the literature to ensure such dependability (either perfectly, or to a known very high degree of reliability). The solution to all backup problems is to use such a procedure (implemented through humans, software, whatever). In contrast, the dependability of most GH procedures is anecdotal only. Provided that one assures conformance of the backup machine itself (which may well be administratively out of control of the PDA user, therefore of higher backup software), one could use verified backup software which implements the appropriate part of a demonstrably dependable algorithm. Except there isn't any for PDAs. One has to wonder why not. Peter Ladkin ------------------------------ Date: Fri, 16 Feb 2001 15:45:23 +0100 From: Martin Jost Subject: Re: It's the wolf! It's the wolf! (Bell, RISKS-21.24) > [...] I know of other sites with multiple names, and secure connections, > and this is the first time I've ever seen the wrong certificate presented. Why should they get it right, if (even (?)) HP fails at it ? Try https://www.itrc.hp.com (this is HPs IT Resource Center) You start with a warning from Netscape: --------------------------- Warning! You have requested an insecure document that was originally designated a secure document (the location has been redirected from a secure to an insecure document). The document and any information you send back could be observed by a third party while in transit. --------------------------- (_I_ had to read this slowly to get it the first time; now I routinely click the 'Ok'-Button (Risk !)) Clicking 'Ok' carried me to http://home1.itrc.hp.com Clicking "Maintenance and Support" on this page got me on to https://europe-support.external.hp.com (Note: To get there, you will need an account) I usually check this URL and the 'lock' icon in netscape. This time no warning. (Certificate belongs to europe-support.external.hp.com; 40 Bit) And I remember having seen problems in the past of the sort: Something like https://europe-support.external2.hp.com in Netscape, but https://europe-support.external.hp.com in certificate (Looks like load balancing to me) Martin Jost ------------------------------ Date: Sat, 17 Feb 2001 18:17:23 -0000 From: "Andrew Jackson" Subject: Re: It's the wolf! It's the wolf! I agree that there are ways to present a certificate so that it matches the Web site name used, which would reduce the chance of receiving less than helpful warning messages. However, the site in question _is_ capable of using 128 bit SSL encryption - I would guess that the 40 bit problem (and therefore a risk) results from having an out of date browser as all the current ones are capable of 128 bit encryption - even on this side of the Atlantic. On a related tack, what gets me annoyed is Webservers that won't let me submit a PKCS#10 certificate request without putting something in the "State" field :-( ("Frustrated" is never accepted, either.) Andy amj@trustis.com ------------------------------ Date: Thu, 15 Feb 2001 23:00:40 -0800 From: Geoff Kuenning Subject: When will they EVER learn? I just signed up with netflix.com, which among other things allows you to purchase DVD movies. Within two days, I received an e-mail that helpfully told me -- in cleartext -- the password that I had just set up for the account. Since movies are moderately expensive, there are literally tens of thousands of titles available, and it's not unreasonable to order 2-3 copies of one title, this seems to put my account at a rather high risk of being abused by anyone with a sniffer. I immediately changed the password, and so far I haven't been told *it* in cleartext. But when will people figure out that there's not a lot of point in using SSL if you fling sensitive information around in unencrypted e-mail? Geoff Kuenning geoff@cs.hmc.edu http://www.cs.hmc.edu/~geoff/ ------------------------------ Date: Mon, 19 Feb 2001 08:30:48 -0800 From: "Rob Slade, doting grandpa of Ryan and Trevor" Subject: REVIEW: "Building Internet Firewalls", Zwicky/Cooper BKBUINFI.RVW 20010105 "Building Internet Firewalls", Elizabeth D. Zwicky/Simon Cooper/D. Brent Chapman, 2000, 1-56592-871-7, U$44.95/C$65.95 %A Elizabeth Zwicky %A Simon Cooper %A D. Brent Chapman %C 103 Morris Street, Suite A, Sebastopol, CA 95472 %D 2000 %G 1-56592-871-7 %I O'Reilly & Associates, Inc. %O U$44.95/C$65.95 707-829-0515 fax: 707-829-0104 nuts@ora.com %P 869 p. %T "Building Internet Firewalls, Second Edition" Cheswick and Bellovin's "Firewalls and Internet Security" (cf. BKFRINSC.RVW) has been, and probably will continue to be, seen as the classic reference with the seriously technical crowd. Chapman and Zwicky, however, created the first reference for the more normal run of system administrators: those whose lives do not revolve around hacking the UNIX kernel. This expanded edition fulfills the same task, and maintains the same reasonable stance. It is refreshing, for example, to find a work that, even if it doesn't know much about viruses, admits that firewalls can do very little to protect against them. There is now a more general and introductory part one, discussing the basic concepts before getting deeply into technical details. Three chapters look at a rationale for firewall usage, Internet services and requirements, and universal security strategies. Part two (part one in the original edition) is an introduction to firewall technology and structure. It could easily stand as a separate book, itself, clearly explaining the operation of, and reasoning behind, functions that other firewall books merely mention. More, it is a very down-to-earth and practical guide to evaluating security needs and planning for security systems and practices. The writing is completely clear, and the explanations first-rate. Two chapters look at the packet structures of Internet protocols and basic firewall technologies. Chapter six, on firewall architectures, is a perfect introduction for the manager who, while not having a technical background, must lead or administer a security project, and is followed by a short but useful outline for a design process. The detailed chapter on packet filtering is the longest in the book, but there is also solid coverage of proxy systems and bastion hosts. The section concludes with valuable particulars of tools for securing UNIX (and Linux) and Windows (NT and 2000) systems. Part three reviews various Internet services, the reasons for having them, risks associated with them, and details that can be used to secure them. There is an introduction to the subject, and then coverage of intermediary protocols, the World Wide Web, e-mail and news, file and print transfer and sharing, remote access, and real time conferencing systems. Each chapter also deals with related issues and technologies, such as the various specific mail protocols and active content for Web pages. As well, the topics of naming and directory services, authentication, administrative services, and databases and games are examined. Two sample firewall configurations, using the previous material, close off the division. Part four provides quick but decent guidance on general security issues. There is a look at security policies, firewall maintenance, and responding to security incidents. The appendices are useful, outlining resources for further information, tools, and a brief but reliable explanation of cryptography. The resource list, unlike the usual table of titles and URLs, contains quality works, and is annotated. This was the first book to truly explain, to the non-specialist, the various factors and functions involved in firewall choice and construction. I still have not found another of similar quality. This new edition is not just an update, but a valuable extension and expansion. For those building their own and for those evaluating vendor proposals, this book is a must. copyright Robert M. Slade, 1995, 2001 BKBUINFI.RVW 20010105 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: 12 Feb 2001 (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 option of E-mail address if not the same as FROM: on the same line, which requires PGN's intervention -- to block spamming subscriptions, etc.] 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 20" for volume 20] http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. http://the.wiretapped.net/security/info/textfiles/risks-digest/ . ==> PGN's comprehensive historical Illustrative Risks summary of one liners: http://www.csl.sri.com/illustrative.html for browsing, http://www.csl.sri.com/illustrative.pdf or .ps for printing ------------------------------ End of RISKS-FORUM Digest 21.25 ************************