Subject: RISKS DIGEST 16.95 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Weds 22 March 1995 Volume 16 : 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, etc. ***** Contents: UK National Lottery [scratch as scratch can?] (Pete) Re: Too high-tech... (Steven Tepper) Re: Internet: Threat or menace? (Dave Parnas) Risks of one-to-many communication (Vicki Rosenzweig) Latent risks of cost-benefit analysis (Ron Ragsdale) Re: Risks of doing date arithmetic early in the year... (Andrew Marc Greene) Re: Prodigy (Craig Dickson) Re: PGP Moose (Jerry Leichter) FBOI Apology (fwd) (FBOI via Willie Smith) Re: FBOI (Mike Perry, Jonathon Tidswell) Re: NCSA httpd security hole (Timothy Hunt) Citizen's Advice on the Internet (Phil Overy) Re: FBOI and *Security Reviews* (Ross Anderson) ABRIDGED Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Wed, 22 Mar 95 15:36:37 From: pete@minster.york.ac.uk Subject: UK National Lottery [scratch as scratch can?] Lottery cards are not up to scratch, By Ben Fenton From the Electronic Telegraph A computer fault forced the National Lottery to suspend its new Instants scratchcard game last night, a few hours after it was launched at a glittering party in Regent's Park, London. Mr Peter Davis, the director general of the lottery, said that Camelot, which runs it, was "making every effort" to find a solution as quickly as possible. He instructed Camelot to place advertisements in all daily national and key regional newspapers today to reassure customers and said it was vital that players were kept fully informed and their interests protected. He said: "Members of the public who have purchased Instants tickets can be assured that all valid prize claims will be met as soon as possible." Any player who had bought a winning ticket should keep it safe. The trouble began even before sports and show business personalities and the Red Devils parachute team officially launched the scratchcard scheme in the sunshine at Regent's Park. Thousands of newsagents, service stations and grocers trying to sell the cards found the discouraging message "Function Suppressed" when they attempted to validate them by computer. Apart from a handful bought around 7am, nobody was able to buy the #1 scratchcards and try for an immediate prize of between #1 and #50,000. The scratchcards are due to be on sale at 20,000 outlets. To use them, customers rub the card to reveal six cash figures and, if three of them match, they win that amount. Weekly lottery tickets are not affected by the fault. ------------------------------ Date: Tue, 21 Mar 95 17:13:14 PST From: greep@datatools.com (Steven Tepper) Subject: Re: Too high-tech... (Wilson, RISKS-16.94) And what if someone spoofs the farmer's IP address to take control of the tractor? Will the farmer be required to hire a security expert to install a firewall on both systems and make sure the tractor is running the most recent version of sendmail? Will the tractor shut off by mistake because its Pentium CPU had a floating-point error? Then what about the livestock? Will Bessie's cowbell be replaced with her own GPS system? Will she have to carry a satellite dish on her head? (Will the farmer?) Come to think of it, GPS would be a good way for Little Bo Peep to keep track of her sheep. This system has definite possibilities. ------------------------------ Date: Wed, 22 Mar 95 08:51:19 EST From: parnas@triose.crl.McMaster.CA (Dave Parnas) Subject: Re: Internet: Threat or menace? (Eric Raymond) Eric Raymond, suggests that the same mechanisms that let organisms evolve to be resistant to plagues, evolution, will allow us to evolve to a point where we can manage the changes brought about by technological change. I suggest that he consider the time-constants involved. Evolution in human beings is best measured on a scale of centuries. Evolution in our technology is best measured in terms of months or years. David Parnas ------------------------------ Date: Wed, 22 Mar 95 09:53:20 EST From: murphy!acmcr!vr@uunet.uu.net (Vicki Rosenzweig) Subject: Risks of one-to-many communication I think Eric Raymond (esr@netaxs.com) is being a bit too sanguine about the risks of memetic garbage, when he suggests that we think of it as evolution in action. First of all, if enough garbage is being transmitted--whether by computer nets or radio hardly matters, for this purpose--it may overwhelm the desired or needed information, for everyone. Second, it may be called "evolution in action" if someone listens to a fanatic preacher and decides to make a suicide attack on something they disapprove of: but to call that "evolution" from the point of view of the victims of that attack does little but allow us not to think too much about what has happened. Third, from a purely evolutionary standpoint, if we are to take one, I would far rather evolve or invent a defense mechanism against such garbage--ideally one that would protect me from other people who take it too seriously--than just dismiss it and hope that I get lucky. Vicki Rosenzweig vr%acmcr.uucp@murphy.com New York, NY ------------------------------ Date: Wed, 22 Mar 1995 10:39:54 -0500 (EST) From: Ron Ragsdale Subject: Latent risks of cost-benefit analysis (Brown, RISKS-16.93) Phil Brown writes: >.. was lobbying for a complete ban on advertising for alcoholic beverages, >.. citing health and economic benefits. but his discussion is on the costs and benefits of "alcohol consumption," not "advertising for alcoholic beverages." It is much harder to make a case for the benefits of the endless parade of beer commercials, though they do seem to present a consistently cheerful view of the world. Professor Emeritus Ron Ragsdale, The Ontario Institute for Studies in Education 252 Bloor Street West Toronto, Ontario, M5S 1V6 CANADA (416) 923-6641 X2252 ------------------------------ Date: Tue, 21 Mar 1995 10:29 -0500 From: Andrew_Marc_Greene@frankston.com Subject: Re: Risks of doing date arithmetic early in the year without FP In RISKS-16.93, Peter Ludemann writes: > But the error probably wouldn't have existed in the first place if the > conversion code had been written with floating point instead of integer > arithmetic. Um, aren't all floating point operations are performed using exclusively integer operations anyway (at least until continuous-voltage real-number ALUs become common)? As Donald Knuth pointed out in the implementation of TeX, if a program does its own floating-point emulation (assume that the programmer gets it right, which was not the case in the example Peter cited) it is more likely to give the same result when it's ported to another system (that may have greater or lesser precision, or may round differently...) - Andrew Greene ------------------------------ Date: Tue, 21 Mar 1995 18:51:56 -0800 (PST) From: Craig Dickson Subject: Re: Prodigy (Giles, RISKS-16.94) |I conten[d] that this behavior *is* a bug. The proof is in the public's |reaction to finding bits of "their" files in the Prodigy cache area. No, I don't think so. There is at least a nomenclatural difference between a "bug" -- software that fails to perform as designed -- and a "design flaw" -- software that doesn't do what it perhaps ought to, but does do what it was intended to do. If you want to argue that Prodigy's coders should have realized that not wiping their pre-allocated disk space was a Bad Thing, well, maybe. But it's not a bug, because they probably did it that way on purpose. You see, it is a perfectly normal thing in MS-DOS application coding to create a large file without initializing its contents when the program knows how big a file it needs before it knows exactly what it will put in it. Prodigy's MS-DOS client software is far from the only well-known program to use this technique. Because they are an on-line service, though, when someone noticed some "deleted" data in a Prodigy file, there was an immediate assumption on the part of ill-informed users that Prodigy's software was spying on them. One point that has never been quite clear to me about this case -- I've heard both positive and negative answers, and therefore remain confused -- is whether this uninitialized file was ever transmitted to Prodigy. If not, then this whole controversy is utterly nonsensical, since no "violation of privacy" can possibly occur. If it is transmitted, however, then I would definitely agree that Prodigy should have wiped the file when they created it. It is one thing to have "deleted" data that you ignore sitting in a sector that just happens to be allocated to your file; that's a perfectly normal thing to have happen, and it happens to nearly ALL files, since there is usually some slack space between the logical end of a file and the end of the final disk cluster allocated to that file. It is quite another thing, though, to transmit that data to another system without the user's knowledge and consent. | Prodigy [...] grabbed some disk space and saved a few seconds by not wiping | the existing |data... Depending on the size of the file and the year in which the software was originally written, we may be talking about much more than "a few seconds". PC hard disks are pretty fast these days, but they weren't always. ------------------------------ Date: Sun, 19 Mar 95 11:47:45 EDT From: Jerry Leichter Subject: Re: PGP Moose >Given the prevalence of Unix (aka broken) mail forwarders out there >that believe any occurrence of "From" at the beginning of a line can >be "wedged" as That's the way things are *supposed* to work. However, it's a fact that many messages have their From's wedged in transit. In fact, it happened with the sample "From" in my RISKS posting as it arrived here. One cause I have been able to track down is the use of final delivery agents as forwarding agents. It's apparently a fairly common trick to allow "final delivery" to go to an address that really feeds into a pipe to a program that forwards the message onward. Alternatively, some systems implement store-and- forward mailers by using a standard local delivery agent to place stuff into a file that is then later read and forwarded. In both of these cases, a properly written forwarding agent to unwedge the Froms (though since the convention says nothing about lines that start with ">From " to begin with, it could not do so with 100% reliability). It's a fact that many don't. To give one specific example: PSI, one of the largest commercial Internet providers in the US, wedges Froms on mail it forwards to a subscriber (me). By experimentation, I've determined that some of their nodes do wedge Froms, while others don't. At one time, I tried to get PSI to fix the problem. I got nowhere; they denied any problem existed. See the Unix Hater's Handbook for a copy of their final response to me. (The editors of the UHH decided to leave out PSI's name. I see no reason to do so.) >headers -- beware! Any "From:" lines you include are likely >Moosebait! Most Unix mail delivery agents escape "From ", but not "From:". You same "most". Have you counted? Besides, the issue is whether you can rely on the mail system not to do this. You can't. >Oh, yes, there are also some mail forwarders out there that will >change any line consisting only of a single "." to one containing >"..". There are no doubt some that will make the reverse >substitution. There also appear to be This is used by mail and news forwarders. In particular SMTP as used by me to submit this message and NNTP as used by me to receive it the first place. There is some broken SMTP and NNTP software, but all that that I have seen is MS-DOS and Windows. Unless you are on a UUCP site and only take news and mail from UUCP sites through pure UUCP paths, it is almost certain that the double dot encoding has been done on it. What's your point? Do you think that a message containing a line with a single dot on it can legally be delivered with two dots? The RFC's specify how to do dot-encoding, and if you implement it correctly, it's a transparent encoding that exists only while the message is in transit between two systems. The fact is, there are sites out there that implement it incorrectly. I'll again point to PSI. By experimentation, I was able to determine that some of their inter-machine links double dots and don't undouble them. >gateways around that will replace empty lines with lines containing a >single space, as well as gateways that do strange and wondrous things >with spaces at the end of lines. Finally, there appear to be an >increasing number of This does exist as a problem, although not generally with Unix, but with less common operating systems. Agreed; this seems mainly to be IBM gateways. >programs that, under certain unclear conditions, use MIME's BASE64 >encoding You mean quoted-printable. Yes. >in the midst of otherwise simple ASCII text - you'll see things like >=20 at the end of a line. One reason for doing this is to get round software which truncates trailing spaces - that's why trailing spaces get encoded, but the trigger for doing this is normally a single non-ASCII character, or a mail client which falsely declares everything to be 8 bit ISO 8859-1. Generally I would always suspect client software before transport software. I have no idea what software is doing this. All I can see is the messages as they arrive here. I know what software I'm running, and I know what it does to the bodies of messages (nothing at all). In some cases, I've tracked down who out there is damaging messages; in other cases, I haven't bothered to spend the time on a thankless task. >I suppose the underlying idea here is fine, but unfortunately an >attempt to build such a thing on top of the very chaotic and >unpredictable world of today's mail systems is to impose many >non-obvious risks on users. Read the MIME RFCs for discussion on transparency issues. Why should I care what the MIME RFC's have to say? I'm neither sending nor receiving MIME mail; most people on the net are neither sending nor receiving MIME mail; and the original posting proposed to cancel *all* messages that failed a signature test, not just those that were MIME-encoded. (A good thing, since MIME-encoded messages are a small minority.) The original RFC's are, in fact, decently written and provide for proper transparent transport of 7-bit ASCII (8-bit ASCII was a rarity at the time and wasn't considered). For that matter, the UUCP specs (such as they are) do, too. The fact of the matter is that there seem to be more incorrect implementations of the RFC's out there than correct ones. The Unix community has been particularly egregious in its attitude that if the specs disagree with widely-distributed Unix programs, then it's the specs that are wrong. In some cases - sendmail is the famous one - it's not even that the Unix programs are wrong, it's that they are so complex to configure that most complete *systems* using them are set up to violate the RFC's, even if in principle they could have been set up correctly. What programs could, in principle, do is of no importance: The mail system infrastructure is built of what the systems out there actually do, not what they could potentially do - and what they actually do is a mess. -- Jerry ------------------------------ Date: Wed, 22 Mar 1995 10:21:37 -0500 (EST) From: wpns@roadrunner.pictel.com (Willie Smith) Subject: FBOI Apology (fwd) I got this from the FBOI folk(s?): >We apologize for sending you our unsolicitated [sic] press release. We >carefully screened who received our information. Only members of >the press and a select group of moderators were to receive our >information. We could not, however, determine proper parties in all cases. > >Moderators selected from: > garbo.uwasa.fi:/pc/doc-net/newsgrps.zip > >NO unmoderated group or list was intended to see this information. >A moderator best knows the interests of the group. > >It was NOT intended for Risk. Please let the members know it was an >error. Just have them delete it. > >Please understand our desire to inform the users of the Internet of >our services. So it's a sorta-spam that got away from him. I think it's only too appropriate for Risks! The sad part is, that unless the investigation into his doings noted in the last Risks digest proceeds quickly enough, PT Barnum's motto will guarantee he gets at least some money from some clueless newbies. Not bad for a (guess) $30 investment in an Netcom account! Willie ------------------------------ Date: Wed, 22 Mar 1995 16:28:35 GMT From: mikep@trantor.europe.dg.com Subject: Re: FBOI We don't KNOW if FBOI has bad intentions, and we should be careful of assuming so, with no evidence, for there IS a legitimate need for services such as these, and, if they can get away with charges totalling 10%, then clearly there is legitimate money to be made. But we should be mindful of the risks. We shouldn't consider the use of netcom by a startup business to be any more suspect than we would consider a 'physical' startup not investing immediately in business premises with office furniture, equipment and secretaries - how many of us today work for, or with equipment made by, companies that started out in someones garage? But we should be mindful of the risks. We don't know to what extent FBOI have considered, and dealt with, the security issues. But we should be mindful of the risks. As RISKS readers we should all be aware of these risks, and should act accordingly. But what of the readers of rec.obscurehobby.keentospend? (I'm assuming here that their newsgroups were also posted by FBOI). They may not necessarily be so {skeptical|mistrusting|risk-aware}. Someone (our esteemed moderator maybe?) would be doing these folks a service by posting (at least to the moderated groups) a summary of the concerns expressed by the RISKS readership. Mike Perry Data General Ltd +44 (0)181 758 6000 fax: +44 (0)181 758 6758 ------------------------------ Date: Wed, 22 Mar 95 14:22:37 TZ From: Jonathon Tidswell Subject: Re: FBOI Steve Holzworth and Rob Slade pointed out the disproportionately high security for FBOI in relation to the security they offered their clients. Rob Slade also raised questions about the cryptographic software, although freely available outside the US, it had (has ?) a non-commercial use clause. The FBOI operation appears to be opportunistic, but I expect other more serious Internet banking operations will emerge in the very near future. Indeed I have thought (dreamed :-) about it, but I haven't the time/money to make a serious attempt. I think the more interesting risks are long term. Steve Holzworth wrote: | 1) According to the NC Banking Commission, use of the term "bank", with a | very few limited exceptions, is illegal for anyone but an organization | that is a federally (FDIC) or state chartered, regulated entity. The NC | Banking Commission has taken an interest in this announcement, and is | forwarding the info to the FDIC... [ from the original FBOI posting. ] | 8) "...since U.S. Postal Service and Federal Trade Commission mail order laws | do not apply to the Internet." | | The laws may not apply to the Internet per se, but credit card transactions | are still subject to all of the controls of typical "mail order" as is | normally practiced via telephone. This is fine since the posting came from a US email address, it does not necessarily follow that FBOI is US based. Consider the case of a real bank in some small tax haven coming on line. What are the implications for local banking laws and taxing systems ? Consider further the advent of a money changing operation, which buys and sells its own currency the "NetCredit", according to some published pricing which puts 1 NetCredit at about 50c US, and the appropriate prices for other currencies. With the advent of untraceable electronic cash this becomes a perfect money laundering operation. E.g., Buy 1 million NetCredits in New York and sell them for swiss francs in Geneva. When this becomes available to the ordinary public, no single transaction ever needs fo through a local bank, which is a basic requirement for a black market. What happens to national tax systems ? - Jon Tidswell ------------------------------ Date: Wed, 22 Mar 95 10:04:20 +0000 From: "Timothy Hunt [Assistant Unix Systems Manager]" Subject: re: NCSA httpd security hole (RISKS 16:82) The following is an update to the information published in RISKS 16:82 that I received in response to a query on the ----- Forwarded message CA-95:04.README Issue date: February 17, 1995 Date of last revision: March 15, 1995 This file is a supplement to the CERT advisory CA-95:04, "NCSA HTTP Daemon for UNIX Vulnerability," distributed on February 17, 1995. We update the file when additional information becomes available. ///////////////////// Added: March 15, 1995 Since the advisory was issued, NCSA has provided updated information (please see below) that supersedes information provided in Step 1 of the Solution section of this advisory. This information can be obtained from: http://hoohoo.ncsa.uiuc.edu/docs/patch_desc.html If you have any questions about this vulnerability, please contact NCSA (Elizabeth Frank, efrank@ncsa.uiuc.edu). Beginning of Text Provided by NCSA ============================================================================== NCSA httpd Patch for Buffer Overflow A vulnerability was recently discovered in the NCSA httpd. A program which will break into an HP system running the precompiled httpd has been published, along with step by step instructions. The program overflows a buffer into program space which then gets executed. If you are running a precompiled NCSA httpd, please ftp a new copy of the binary. If you have compiled your own source code, we recommend applying the following Patch to fix the vulnerability in the NCSA HTTP Daemon V.1.3 for UNIX. It modifies the strsubfirst subroutine in util.c. We believe that earlier versions of the server are vulnerable to a similar attack, and strsubfirst should be modified for all releases of the server. Cert Advisory CA-95:04 describes the problem and includes two suggested steps. We do not recommend taking step 1, which increases MAX_STRING_LEN to 8192. There are 154 occurrences of variables using MAX_STRING_LEN and changing them from 256 to 8192 bytes is going to expand the memory needed to run httpd tremendously! On top of that, httpd forks a new process (a complete copy of the parent) for each connection, which if your site gets hit a lot will use unnecessarily large amounts of memory. We have already had reports from admins who have made the change saying they are experiencing performance degradation due to swapping. Step 2, applying the patch to util.c, should be sufficient to fix the problem. There is significantly less forking in Release 1.4 of the NCSA HTTP Daemon which will be released soon. Detecting a Break-in If the access log contains control characters, there is a chance that someone has tried to break into your system. If your server has died recently, they failed at least one attempt. And, if your server has not crashed and there are control characters in the access log you should assume your system has been compromised. In this case, servers which currently use the User Directive to run the server as "nobody", have limited the potential damage of an intruder to those commands which "nobody" may execute. Control Characters in the Access Log You've discovered control characters in your access log. How do you tell if was an intruder? If the beginning of the line containing the control characters begins sensibly (eg. machine name, and date (the GET periodically gets clobbered)) and ends with a series of control characters, it is a break-in attempt. If the beginning of the line starts with control characters (often nulls), this is a symptom of a collision problem that occurs when two children try to write to the access log simultaneously. This problem has only been seen with moderately to heavily loaded servers. (We are working to fix this in Release 1.4.) Other ways to Make Your Server More Secure A tutorial about running a secure server is available. We also recommend that the User Directive be used to run the server as "nobody". Patched Source and Binaries The patched source and precompiled binaries are available. We will also be correcting the source for previous releases, but we will NOT be generating binaries for previous releases. Elizabeth Frank efrank@ncsa.uiuc.edu [End of Text Provided by NCSA] ------------------------------ Date: Wed, 22 Mar 95 09:21:19 GMT From: phil overy Subject: Citizen's Advice on the Internet The critique of the First Bank of the Internet is the germ of a good idea - why not review new businesses? (more or less as people referee scientific journal articles - then potential investors can weed out the con-merchants BEFORE they create another notorious scam). I think the Internet will need such a service soon, to cancel out all the gee-whizz proposals flying around which intend to make money out of doing exactly the reverse - keeping people UNinformed. I suppose you could describe it as a CERT at the application rather than the network layer. The RISK? - you only need to see how the previous Internet authorities were lambasted as they became more bureaucratic to realise that anyone employed in refereeing will be attacked as More Fascist Than Adolf Hitler and of course in breach of The Spirit Of The Free Market and The American Way Of Life. I have already used information from a Usenet news group on Multi-Level Marketing (which is NOT pyramid selling.. honest) to inform someone who was being pushed into representing AmWay - I don't know how much use it was, but he couldn't pretend he was not informed of the cost of doing it. Phil Overy Rutherford-Appleton lab ------------------------------ Date: Wed, 22 Mar 1995 12:32:12 GMT From: Ross.Anderson@cl.cam.ac.uk Subject: Re: FBOI (RISKS-16.93) and *Security Reviews* Can't let the FBOI advert go unchallenged! Also, we have made a lot of `Security Reviews' back numbers available, >Date: Wed 22 Mar 1995 >From: rja14@cl.cam.ac.uk >Subject: First Bank of Internet In RISKS-16.93, an advert for the `First Bank of Internet' said, of its VISA ATM card: > The card is prepaid, PIN protected, replaceable, disposable, and good > at over 200,000 Visa/PLUS (tm) ATMs in 83 countries. > > The safety of FBOI is ensured because access to ATM funds without > possession of both the ATM card and the Personal Identification Number > (PIN) is not possible. ATM security breaks down in many ways - see for example `Why Cryptosystems Fail' at ftp.cl.cam.ac.uk:/users/rja14/wcf.ps.Z, which documents a number of incidents. Many of these have been reported in comp.risks over the last few years. A bank which shows itself to be unaware of risks which are well known to readers of this column does not serve itself well by advertising here, Ross * * * * * * * * >Date: Wed 22 Mar 1995 >From: rja14@cl.cam.ac.uk >Subject: Computer and Communications Security Reviews Risks readers might be interested to know that the first six issues of `Computer and Communications Security Reviews' can be downloaded for free from ftp.cl.cam.ac.uk:/users/rja14 (see the ReadMe file there for details). `Computer and Communications Security Reviews' provides abstracts of current research in computer security, cryptography and related topics. ------------------------------ Date: 21 March 1995 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: ABRIDGED Info on RISKS (comp.risks) [See other issues for full info] The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. [...] REQUESTS to (which is not yet automated). [...] CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. [...] RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html [...] RISKS ARCHIVES: "ftp unix.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. [...] ------------------------------ End of RISKS-FORUM Digest 16.95 ************************