precedence: bulk Subject: Risks Digest 21.78 RISKS-LIST: Risks-Forum Digest Thursday 22 November 2001 Volume 21 : Issue 78 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: Playboy says hacker stole customer info (Monty Solomon) Euro changeover risk (Carl Fink) The cure is only slightly worse than the disease... (Russell Stewart) My daughter is failing high school! (Jeremy Epstein) Network Solutions ad inadvertently names my domain (Fredric L. Rice) Another date risk (Leonard Erickson) Re: Researchers probe Net's 'dark address space' (Arthur Smith) Glitch in iTunes Deletes Drives (Dave Katz) Re: FBI targets suspects' PCs with spy virus (R.S. Heuman, Rob Slade) RISKS-21.77 was rejected by some filters (PGN) Re: Porn spam being sent in my name (Andrew Klossner) Re: Programming error ... (David Gillett) Re: Toaster failures (Marcus Didius Falco) The more things change (Mike Albaugh) Re: IP: 800 directory "assistance" redirecting calls (Rob Bailey, Clay Jackson) Re: National ID cards (Henry Baker) Re: Windows XP accounts by default are administrator with no password (Mark Wilkins) Let's get really paranoid about e-mail and spam... (Allan Hurst) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Tue, 20 Nov 2001 23:01:48 -0500 From: Monty Solomon Subject: Playboy says hacker stole customer info By Greg Sandoval and Robert Lemos, CNET News.com, 20 Nov 2001 Playboy.com has alerted customers that an intruder broke into its Web site and obtained some customer information, including credit card numbers. The online unit of the nearly 50-year-old men's magazine said in an e-mail to customers that it believed a hacker accessed "a portion" of Playboy.com's computer systems. In the e-mail, a copy of which was reviewed by CNET News.com, Playboy.com President Larry Lux did not disclose how many customers might have been affected. Playboy.com encouraged customers to contact their credit card companies to check for unauthorized charges. New York-based Playboy.com also said it reported the incident to law enforcement officials and hired a security expert to audit its computer systems and analyze the incident. [...] http://news.cnet.com/news/0-1007-200-7932825.html ------------------------------ Date: Wed, 21 Nov 2001 13:03:46 -0500 From: Carl Fink Subject: Euro changeover risk An Irish emigrant to Spain had an unexpected windfall when his Dublin bank accidentally credited more than 300,000 euros ($264,800) -- instead of 300,000 pesetas -- to his new account, newspapers reported on Wednesday. (Reuters, http://news.excite.com/news/r/011121/07/odd-ireland-dc) Surely European banking software has always had to handle currency conversions? Carl Fink, Manager, Dueling Modems Computer Forum carlf@dm.net http://dm.net/ ------------------------------ Date: Wed, 21 Nov 2001 12:56:57 -0700 From: "Stewart, Russell" Subject: The cure is only slightly worse than the disease... This story taken off of the newswire today: http://dailynews.yahoo.com/h/nm/20011121/od/tech_hongkong_champion_dc_1.html Concerns a signal-jamming technology being developed by a Hong Kong company to block cellphone calls in areas where they are not wanted. Not a bad idea, but the following excerpt caught my attention: "A Hong Kong company hopes to sell signal-jamming technology previously used by the military to thwart lethal missiles to block annoying cellphone calls in places such as hospitals, places of worship and restaurants." Hospitals? Now, I admit I know very little about jamming technology, but I know that, at the very least, it requires transmitting radio energy on the same frequency as the signal you are trying to jam. Presumably, it involves transmitting at a considerably higher power than that of the target signal. Now, as I understand it, hospitals' no-cellphone policy is based on the fear that the phones' radio transmissions might interfere with hospital equipment. Are we to understand, then, that they intend to combat the problem by installing a device that, by definition, must transmit on the same frequencies at the same or considerably greater power? I hope this was simply an error on the writer's part... Russell Stewart, Sandia National Laboratories russtew@sandia.gov ------------------------------ Date: Wed, 21 Nov 2001 08:38:53 -0500 From: "Jeremy Epstein" Subject: My daughter is failing high school! OK, you ask, what does that have to do with RISKS? Hold on a second! Fairfax County Virginia has one school system (unlike other counties around the US where each municipality or region has their own system). My daughter goes to a magnet high school program within the county, but not the one that would ordinarily be our "home" school (i.e., the one closest to our house). Last week she got her report card for the first quarter from the magnet school. Yesterday she got a second report card from the home school, which doesn't show any courses or grades. Luckily, it doesn't show a GPA either (I guess the programmer was smart enough not to try to average zero credit hours :-). But it does show she attended school for 40 days and was absent two days... the same number as in the magnet school. So the county obviously has one database to record absences, but the software isn't smart enough to realize she's not taking any courses at the home school and therefore shouldn't get a report card. Or maybe that's a safeguard in case the child drops all classes without telling the parents? I *hope* that when she goes to apply for college that they'll report her actual GPA, and not something silly like 0.0 since the school system obviously doesn't understand where she is! The risks of poorly designed database applications... ------------------------------ Date: Tue, 20 Nov 2001 14:12:52 From: "Fredric L. Rice" Subject: Network Solutions ad inadvertently names my domain Back some months ago -- 11 Apr 2001, in fact -- a promotional mailer in the form of a folded post card (11 inches by 15 inches) was mailed out to who knows how many residences in Virginia (U.S.) by Network Solutions, a VeriSign Company, advertising Web site services. Amusingly, the advertisement listed www.squirreling.org as a sample domain name, describing a "matching e-mail address like this" with yourname@squirreling.com as their "matching e-mail address." Aside from the fact that Network Solutions mixed .ORG with .COM, apparently they didn't bother to check first to see whether Squirreling.ORG was an existing web site before they advertised it as an example. In fact I had registered the domain name on February 2'nd, 2000 and had acquired hosting shortly after that. The name "Squirreling" was doubtlessly picked because it sounds amusing and Network Solutions probably assumed that nobody would have such a domain. The risks? What if my web site had been something sinister? Network Solutions could have suffered massive embarrassment and revenue losses had my web site contained "Bonsai Kittens" or something equally stupid on it. http://groups.google.com/groups?q=+%22squirreling.org%22&hl=en&rnum=2&selm=3 ad4add5.231072131%40news.bellatlantic.net ------------------------------ Date: Tue, 20 Nov 2001 16:49:44 PST From: shadow@krypton.rain.com (Leonard Erickson) Subject: Another date risk (Re: Brown, RISKS-21.76) Lotus and most other spreadsheets have another date risk, caused by trying to maintain compatibility with Visicalc in the original Lotus and carried over from there. Dates are stored as the number of days since the start of 1900. That is Jan 1, 1900 is stored as 1, etc. The problem is the original programmers thought that 1900 was a leap year. Enter 60 into a date-formatted cell. Many spreadsheets will display it as Feb 29, 1900! Microsoft Multiplan handles this by making Jan 1, 1900 store as 2 rather than 1. But that means dates in it won't match dates in other spreadsheets if they are before March 1, 1900. There's no good solution anymore due to the spread of this "misfeature" thru spreadsheets across the world. All you can do is double check *any* date info from before 1900-03-01 that has passed thru (or may have passed thru) a spreadsheet. Leonard Erickson (aka shadow{G}) shadow@krypton.rain.com ------------------------------ Date: Wed, 21 Nov 2001 09:49:31 -0500 From: Arthur Smith Subject: Re: Researchers probe Net's 'dark address space' We have fallen into the accidental misconfiguration trap a few times for some of these cases -- the primary reason it happened to us is that routes advertised using "classless" IP address ranges do not get treated properly by a router that doesn't have 'ip classless' set (in Cisco-speak). This is the Classless-InterDomain Routing (CIDR) system that replaced the old Class-A, class-B, class-C hierarchy. The cable modem and military people tend to populate parts of old class-A blocks - this is any IP address that starts with a number less than 128. In our case what happened was we had a "specialty" internet provider that only provided access to certain networks which they advertised to us via the BGP protocol, and they filtered out any traffic coming from us that didn't match that list of networks. But it turned out that some of the networks they advertised were small portions of these old class-A networks, and we naively did not have "classless" routing turned on, so our router thought the ENTIRE class-A had to be routed through them. So traffic between us and any address in that class-A block not passed through by our provider was blocked. One reason we didn't have classless routing turned on was some previous bad experience where one of our partners' router's memory had been filled with spurious /32 routes (routes with only a single address) due to the use of classless routing, the fact that we did not have all possible routes to our own address space properly advertised to one another, and the malicious actions of some printer software that tried to scan every single address in our (class-B) address space, looking for printers. In short, it's very easy, if you do not have much background in IP networking, to misconfigure your routers to have this sort of thing happen - and it's a little hard to spot since the network connections are generally working fine otherwise - nobody may ever complain! ------------------------------ Date: Wed, 21 Nov 2001 16:27:38 -0800 (PST) From: Dave Katz Subject: Glitch in iTunes Deletes Drives (RISKS-21.74) According to a well-placed friend within Apple, the failure was a bit more complex than described. He says that the bug in the script was actually discovered prior to the software being posted, but that the corrected version somehow did not end up being posted (classic version management issue.) Furthermore, the fact that broken script had been posted was discovered in the middle of the night, but the folks responsible for the server did not pull it down until hours later, thus increasing the collateral damage (classic people management issue.) ------------------------------ Date: Wed, 21 Nov 2001 18:32:27 -0500 From: "R.S. Heuman" Subject: Re: FBI targets suspects' PCs with spy virus (NewsScan, RISKS-21.77) And of course no self-respecting non-US anti-virus firm is going to put a signature into their product that will detect and report on this trojan? Somehow the first time it is detected by anyone it will get into F-Prot, F-Secure, AVP and a number of other non-US products that are widely used even in the US, and then what? If the AV product vendors ignore this software, they are in for attack from their customers, and if they detect it they are in for attack from the FBI? Which would you choose were it your corporation? This type of program and its detection is too much of a risk for the FBI for them to widely disseminate it, and ignoring such a program is too much of a risk for the AV product vendors to accept, since alienating their clients will unfortunately result in a major downturn in their corporate viability, once it becomes known, which will be almost immediately. ------------------------------ Date: Wed, 21 Nov 2001 15:41:40 -0800 From: Rob Slade Subject: Re: FBI targets suspects' PCs with spy virus (NewsScan, RISKS-21.77) > The FBI is working on software that could insert a computer virus ... First off, nothing about this program indicates that it is a virus. There is nothing about reproduction in the description. In any case, a virus would be a fairly imprecise way of delivering a security breaking package (although steps could be taken in that regard). > suspect's computer capable of reading encrypted data. As the later material shows, the program is not capable of reading encrypted data, it simply steals passwords. Fairly common activity for trojans in past years. > The software, known as "Magic Lantern," installs "keylogging" software > that can capture keystrokes typed on a computer. The virus can be sent > via e-mail. As Peter notes, Microsoft Outlook is somewhat susceptible to this type of thing, but in pretty much every other case you'd have to convince the target to run an attachment. That might be a little trickier. "The attached Microsoft Word document contains an application form for our special Kali cartel `frequent pusher' discount, good for an extra 10% off on shipments of 100 kilos or more." "Run this hilarious screensaver with inspirational (secret) messages from our beloved leader Osama, along with detailed instructions on the construction of truck bombs." [But this seemed to happen all the time with IL*V*Y**, etc. PGN] The targeting of PGP is interesting. Does this mean that the US government is still ticked over its creation, or that they are finally (tacitly) admitting that open-source software really *is* more secure? > ... possible to observe every keystroke typed by the suspect, even if a > court order specified only encryption keys. It would certainly be easier to collect information, particularly for ephemeral data, such as e-mail. On the other hand, how are the authorities supposed to get at the data? I suppose sending out only the passphrase would be less suspicious if someone was keeping track of traffic. (On the other hand, if anyone was logging port activity it would be fairly easy to scan for Magic Lantern in the same way that people scan for Back Orifice, SubSeven, Bionet, and other RATs.) > [Insertion by e-mail probably works well for Microsoft software, which is > prone to that kind of attack. Various reports suggest that Magic Lantern > can also plant itself by penetrating systems. Penetrating how? I would hope that the RISKS audience is somewhat less suggestible, along these lines, than the general public. [You must be kidding! PGN] > Penetrability of supposedly secure systems has long been noted here ... True, but the penetration is still probably going to happen on a case by case basis. Viruses would be a good way to break confidentiality (just look at Sircam), but are rather a blunt instrument, tending to drown signal with noise (look at Noped). 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: Wed, 21 Nov 2001 19:07:42 PST From: PGN Subject: RISKS-21.77 was rejected by some filters RISKS-21.77 contained a string naming a recent virus "IL*V*Y**". Some of you apparently have filters that are so lame they cannot tell the difference between that spelled out in text and the actual virus. Overzealous filtering is rapidly becoming a bad joke. ------------------------------ Date: Wed, 21 Nov 2001 07:17:02 -0800 From: Andrew Klossner Subject: Re: Porn spam being sent in my name (Sanders, RISKS-21.76) > Imagine my surprise to find that the original (bounced) message had > been spam, apparently sent from me! That "original message" was never sent. The "bounce notification message" was forged by the spammer. And it worked -- you paid close attention to it. ------------------------------ Date: Wed, 21 Nov 2001 15:08:06 -0800 From: dgillett@deepforest.org Subject: Re: Programming error ... (Stein, RISKS-21.77) > The best folks prefer product engineering (aka 'development'). I don't believe this is true at all. I believe that the vast majority of employees, and many managers, in the computer field regard product engineering as the "senior" department, the superior order amongst technical professionals. [That upper management often considers sales to outrank all technical groups takes a while to discover....] The result is that other technical departments, such as QA and IT, are often staffed largely with junior engineers biding their time and acquiring years of experience to try to get into product engineering. Naturally, they're not very good at what they're currently being paid to do -- they'd much prefer to be in product engineering -- but they're not necessarily any better at *it*. On the counter side, there *are* a few excellent, committed QA and IT and Tech Support folks around -- "the best" in these realms -- and often that is intimately tied to their discovery of a personal preference for one of these "ancillary" roles. I would say that the *majority* prefer product engineering -- and that this is linked, chicken-and-egg fashion, to other branches being under-appreciated and staffed largely by inexperienced, uninterested, and (as a consequence) ineffective personnel. The consequences? We read about them on the RISKS Digest every week. David Gillett ------------------------------ Date: Tue, 20 Nov 2001 14:20:15 -0500 From: Marcus Didius Falco Subject: Re: Toaster failures (Re: Hackett, RISKS-21.76) According to the Dec 2001 issue of *Consumer Reports*, your problems with toasters are not unique, and they were able to get better toast from some simpler toasters (that is, without all the sensors). However, the risk of toasters not turning off until they have popped has been addressed in the US. There is now a Consumer Product Safety Commission standard requiring toasters to turn off when the cycle is over, whether or not the "pop" has occurred. It takes effect for toasters manufactured after November 2001, but many toasters are now compliant (and some actually give some indication of this compliance on the box). ------------------------------ Date: Tue, 20 Nov 2001 14:49:17 -0800 (PST) From: albaugh@spies.com Subject: The more things change In RISKS-21.76, we read about (800)555-1212 re-directing information calls. Those familiar with the history of the telephone system may recall that Almon P. Strowger, generally regarded as the inventor of automatic telephone switching apparatus (at least in the U.S.A. :-) was an undertaker, who produced his invention because he was tired of the telephone operator in his town "accidentally connecting" his calls to his competitor, said operator's husband. Of course, all those helpful Web "directory" sites have been doing this for years, and "Smart-Links" threatens to move the betrayal right to your PC. (Yes, I know, not _right_ now, yet...) We also read about: > Subject: Re: Another SRI-wide power outage (Rowland, RISKS-21.74) > > [...] The Xerox tech would decide that the the pair of side by side tops of > the controllers made an excellent surface for him to flop his huge folder of > tech charts onto, toggling the power switches on both modems off. Which reminded me of the result of using the oh-so-convenient top of the IBM 1401's Core-memory extension to set down 7-track mag-tapes temporarily, until we figured out why we where getting so many errors... (We put a two-drawer steel card-file on top, and added a notice _under_ that file explaining the issue and saying "Put it back") ------------------------------ Date: Tue, 20 Nov 2001 11:30:29 -0800 (PST) From: Rob Bailey Subject: Re: IP: 800 directory "assistance" redirecting calls (Glass, R 21 77) Brett Glass's story on operator-assisted dialing that resulted in customer hijacking would probably have shocked Almon Strowger, the funeral parlor manager who, as the story is told, invented the Strowger switch, which as we all know would become the backbone for the electromechanical direct-dial apparatus in place for many decades. (As the story is told, Strowger [STRO-jer] suspected the local telephone exchanges of routing potential customers [well, I suspose the families of potential customers!] for his funeral parlor to his competitors' parlors. Paranoia was the mother of Strowger's invention.) As long as callers leave the recipient-to-number translation in the hands of others, for convenience of any other reason, this problem will likely persist. Rob Bailey, wm8s@pobox.com ------------------------------ Date: Wed, 21 Nov 2001 09:12:43 -0800 From: Clay Jackson Subject: Re: 800 directory "assistance" redirecting calls (Glass, RISKS-21.76) The risk was not properly identified. While this is certainly an issue; IMHO Bret has the risk all wrong. This is a classic case of 'Never attribute to malice what can be explained by stupidity'. I'm sure AT&T (I'm assuming here, since they're the biggest user of TellMe) made NO deliberate attempt to 'hijack' the hotel's number (what possible benefit would ANYONE receive from rerouting a caller looking for a hotel to a furniture store). What's much more likely is that the TellMe VR software made a mistake; or, that it doesn't handle duplicate names very well. ------------------------------ Date: Tue, 20 Nov 2001 19:47:17 -0800 From: Henry Baker Subject: Re: National ID cards (Shostack, RISKS-21.75) I'm not going to comment on national ID cards directly, but only upon Adam Shostack's reasoning. Every web page (instruction, datum, etc.) is accessed a first time, as well, but caches still work pretty darn well on a statistical basis. Screening will always be a statistics game, but we need to attach wildly different costs to various kinds of screening misses. Clearly, 20 box cutters can ruin a lot of days. The IBM 360/30 didn't execute a "divide" instruction or a "convert to decimal" instruction very often, but when it did, they was so slow that they often dominated instruction trace timings. So the next generation of 360's improved the execution speed of those particular instructions. However, much of the improvement in computer execution speeds over the past twenty years is the result of tuning to more broadly valid statistical data, rather than focusing only on rare but costly instructions. Similarly, we need to continue to make _flying as a whole_ safer, rather than focus only on the threat of terrorism, as the recent NYC crash sadly proves. ------------------------------ Date: Tue, 20 Nov 2001 10:54:48 -0800 From: Mark Wilkins Subject: Re: Windows XP accounts by default are administrator with no password > If you create user accounts, by default, they will have an account type of > Administrator with no password." This is probably a result of aggressive product management. Some years ago I worked for Mitsubishi Consumer Electronics in their software department, and was tasked to write the code to implement parental lock on a (now long defunct) chassis of TV set. I'd implemented it so that all the settings would remain as parents locked and unlocked the TV, so that parents could set all their settings for each channel once and allow or deny TV viewing according to those settings as they liked. Much of that logic had to be re-implemented for a different behavior: unlocking the TV caused ALL of the information about which channels or times were or were not permissible to be erased, requiring that they be re-entered next time. The reason for this was that apparently support telephone calls on the issue of parental lock nearly never asked the question "Why can't I lock my kids out of the television?" and instead nearly always asked "My kids have locked me out of the television. What do I do?" Since those calls cost money to support a product for which the company had already been paid, they were to be minimized. The product had to be easy to unlock and hard to lock. I suspect this behavior in Windows XP is a similar matter. ------------------------------ Date: Tue, 20 Nov 2001 11:54:57 -0800 From: "Allan Hurst" Subject: Let's get really paranoid about e-mail and spam... Re: Porn spam being sent in my name (Sanders, RISKS-21.76) Here's how much worse it can get: In the past couple of years, I've opened up e-mail accounts on three different systems: Yahoo Mail, HotMail, and MyRealBox.com. These accounts were used ONLY for testing internet e-mail gateways on new e-mail systems that we set up for clients They have never been used for posting to a list, responding to an ad, and/or have never been entered into any Web site. - Within two months of opening the Yahoo! Mail account, it started receiving spam, none of it from Yahoo. - Within three days of opening the HotMail account, it started receiving spam, in amounts far larger than the Yahoo account. In both of the above cases, I had specifically selected to NOT be listed in either of the systems' directories, and to NOT receive e-mail offers from any of their "marketing partners". Neither of these accounts were ever used to respond to offers, entered into Web sites, or published anywhere. They were only used to send and receive test e-mail messages to and from new e-mail servers. Either Yahoo Mail and HotMail are lying about not publishing or selling addresses, or someone's harvesting e-mail addresses by sniffing packets. (Hence the subject of this message.) As much as I'd like to bash the vendors ... I strongly suspect the answer is that someone's found a way to harvest e-mail addresses. (Keep reading.) I next opened up a third test account, on MyRealBox.com. This is a demonstration mail service operated by Novell, Inc., to show off its NIMS product, and having met people from the NIMS team at various Novell functions, I had been informed that they specifically do NOT sell the MyRealBox accounts, nor use them for marketing purposes of any kind. For about six months, I received no spam of any kind on the MyRealBox account. Suddenly, I was flooded with everything from "failed delivery" messages to angry missives threatening me with bodily harm for spamming them. Some of the missives included the complete message, which was a piece of spam generated with my MyRealBox account name in the "From" and "Reply-To" fields! The messages did NOT originate from MyRealBox, however, nor did they pass through any "traceable" intermediate mail servers (only IP addresses were shown in the headers). This raises the question: if the MyRealBox account name wasn't sold (and I believe it wasn't), then how on earth did the spammers "harvest" my specific MyRealBox account name to use to send spam with? (And are there any steps one can take to prevent it from happening again?) This also brings to mind the risk of using a "free" internet e-mail account, or any type of outsourced e-mail server over which one has no legal or authoritative control. ------------------------------ 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 e-mail requests to with one-line body subscribe [OR unsubscribe] which requires your ANSWERing confirmation to majordomo@CSL.sri.com . [If E-mail address differs from FROM: subscribe "other-address " ; this requires PGN's intervention -- but hinders spamming subscriptions, etc.] Lower-case only in address may get around a confirmation match glitch. INFO [for unabridged version of RISKS information] There seems to be an occasional glitch in the confirmation process, in which case send mail to RISKS with a suitable SUBJECT and we'll do it manually. .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]. Lindsay Marshall has also added to the Newcastle catless site a palmtop version of the most recent RISKS issue and a WAP version that works for many but not all telephones: http://catless.ncl.ac.uk/w/r http://the.wiretapped.net/security/info/textfiles/risks-digest/ . http://www.planetmirror.com/pub/risks/ ftp://ftp.planetmirror.com/pub/risks/ ==> 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.78 ************************