precedence: bulk Subject: Risks Digest 21.62 RISKS-LIST: Risks-Forum Digest Saturday 25 August 2001 Volume 21 : Issue 62 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: Oklahoma whistleblower asked to accept felony conviction (Deborah Weisman) Follow-up on Oklahoma whistleblower (PGN) Wireless security vulnerabilities (PGN) AirSnort! (PGN) Kaiser Permanente (identity withheld by request) Air Force officer mails confidential information to all cadets (Jim Griffith) Re: Avoiding prosecution of the DMCA (David Petrou, Fred Cohen) Re: Why I don't publish my HDCP results (Bill Weitze, David Gillett) Re: rot13 (Mike Perry) Hack the vote? Not in Broward County! (James Paul) Re: Runway incursions (Bill Hopkins) Code Red 9? Code Crimson (Alistair McDonald) AT&T - the computer MUST be right! (Sharon Mech) Re: DejaGoogle rides again (Geoffrey Leeming) Re: Risks of automated junk/spam filters (AlphaLau) Yet another MS Hotmail risk (Kimmo) REVIEW: "SSL and TLS", Eric Rescorla (Rob Slade) Dependable Systems and Networks DSN-2002 Call for Contributions (Anup Ghosh) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Wed, 22 Aug 2001 10:40:06 +0300 From: Deborah Weisman Subject: Oklahoma whistleblower asked to accept felony conviction A Federal prosecutor has asked Brian West, a 24-year old sales and support employee of an Oklahoma ISP "to accept a felony conviction and 5 years probation" for notifying the editor-in-chief of his local newspaper *Poteau Daily News* that they had failed to set up password security for their Web site: no authentication, anyone could edit the site using Microsoft FrontPage. Following their phone conversation, the EIC gave a tape of the conversation to the Poteau Police Department, who invoked the FBI. [http://www.macintouch.com/newsrecent.shtml; PGN-ed] Computer Center Faculty of Agriculture Hebrew University of Jerusalem P.O.B. 12 Rehovot 76100 ISRAEL 972-8-9489232 dvorah@agri.huji.ac.il [Also noted by Ron LaPedis at http://www.linuxfreak.org/post.php/08/17/2001/134.html. PGN] ------------------------------ Date: Sat, 25 Aug 2001 10:12:13 PDT From: "Peter G. Neumann" Subject: Follow-up on Oklahoma whistleblower Sheldon Sperling , the U.S. Attorney in the Brian K. West case, has responded to various e-mail protests on his handling of the case. He claims that West was not arrested and has not been charged. However, an investigation is pending, to determine whether West "intentionally accessed a computer without authorization or exceeded authorized access (to access a computer with authorization and to use such access to obtain or alter information in the computer that the accesser is not entitled so to obtain or alter), (2) whether the employee thereby obtained information from a protected computer (a computer which is used in interstate or foreign commerce or communication), and (3) whether the conduct involved an interstate communication. 18 USC 1030." [The full statement from Sperling is included in a message from Declan McCullagh, which is accessible at http://www.politechbot.com/ .] I have noted in this space before that when there is no security in place, the alleged culprit cannot have exceeded authority when no authority is implied. As long-time RISKS readers will recall, this issue came up relating to the trial of Robert Tappan Morris: in 1988, the Internet worm never exceeded authority, because no authority was required to use the sendmail debug option, to use the .rhosts mechanism, to execute the finger daemon, or to read an unprotected encrypted password file. I wonder how if prosecutors will ever figure this out! As long as we attempt to shoot the messenger and hide lame security behind overly broad laws, weak security will prevail, and whistleblowers will be much rarer than glassblowers. (For example, DMCA is among other things an attempt to outlaw whistleblowers.) ------------------------------ Date: Sun, 19 Aug 2001 13:16:18 PDT From: "Peter G. Neumann" Subject: Wireless security vulnerabilities Sitting in the Morristown (N.J.) Memorial Hospital, AT&T Labs' Avi Rubin (a note from Avi on WEP insecurity is in RISKS-21.57) noticed that his laptop wireless connection card was blinking, and then discovered that the hospital's wireless network was open to his laptop, using 802.11b (Wi-Fi) and automatically granting him access. [Source: As Wireless Networks Grow, So Do Security Fears, by John Schwartz Sunday Business Section of *The New York Times*, page 10, 19 Aug 2001 (National edition), PGN-ed; full article at http://www.nytimes.com/2001/08/19/technology/19WIRE.html] [Another case of *not* having to exceed authority because there was no security involved! Sloppy hospital? Insecurity by obscurity? PGN] ------------------------------ Date: Fri, 24 Aug 2001 11:52:33 -0700 From: "Peter G. Neumann" Subject: AirSnort! AirSnort, WEPCrack, and other programs available on the Internet make it easy to sniff sensitive data such as passwords that fly around 802.11b wireless Internet networks. A competing standard, Bluetooth, is not susceptible, although Bluetooth is considered "more vulnerable to spies than hard-wired networks." [Source: AP item, 24 Aug 2001, courtesy of Ken Nitz; PGN-ed] The vulnerabilities have been noted here before, but now maybe there will be some incentives to do something about it? On the other hand, probably not, if our historical RISKS warnings are not observed, as usual. ------------------------------ Date: Tue, 21 Aug 2001 19:23:53 -0700 From: identity withheld by request Subject: Kaiser Permanente There's a self-service section on the Kaiser Permanente (an HMO) Web site at http://www.kaiserpermanente.org/ that allows you to notify them of a change of address. In bold letters next to the submit button, it claims "Your information is secure!". Sounds good. Checking View Source showed the form was being submitted over SSL. Ok, let's submit the information. A few minutes later an e-mail arrives. No encryption. Ouch -- it contains a verbatim copy of the personal information I typed into the form. So much for "Your information is secure!". Why bother breaking SSL flows, when you can just watch the e-mail? ------------------------------ Date: Sat, 25 Aug 2001 14:48:44 -0500 From: Jim Griffith Subject: Air Force officer mails confidential information to all cadets AP reports that an Air Force Academy officer accidentally sent confidential information about some 40 cadets to all 4400 cadets at the school. The mail in question contained details of past and pending disciplinary issues, including the identity of confidential informants in some cases. The information in question was reportedly protected by federal law, and officials subsequently ordered cadets to delete the letters. http://www0.mercurycenter.com/breaking/docs/044576.htm ------------------------------ Date: Sun, 19 Aug 2001 20:56:30 -0400 From: David Petrou Subject: Re: Avoiding prosecution of the DMCA (Ferguson, RISKS-21.60) Just staying out of the U.S. won't necessarily do the trick. The DoJ can obtain an arrest warrant based upon a criminal violation of the DMCA and seek extradition from a number of countries. If US law is violated and the country where the person is has an extradition agreement with the United States, the foreign government will cooperate in arresting the person and having that person delivered to the United States for prosecution. ------------------------------ Date: Fri, 17 Aug 2001 15:47:51 -0700 (PDT) From: Fred Cohen Subject: Re: Avoiding prosecution of the DMCA (Ferguson, RISKS-21.60) The DMCA has also had effects on my forensic analysis products. Because the current copyright law makes anything that is put into tangible form copyright unless made otherwise by the author (or by law), things like criminal records are copyright. This means that if the criminal tries to protect their material - for example by hiding it using steganography, encrypting it, or by putting it on a computer with a password to prevent unauthorized access - then that work is protected by the DMCA (after all, the password on Windows systems is effective protection unless you try to circumvent it). Because the primary purpose of most of my forensic analysis tools is to reveal things that are protected from revelation, and because the DMCA makes it illegal to distribute such a device, I have been forced (based on the recent arrests and other threats against authors of such things) to withdraw my forensic products from the market. I should note that companies like Access Data who sell products that are explicitly designed for undoing encryption, etc. are almost certainly in violation of the DMCA. While the FBI might not arrest them now because they sell to the FBI (and other in law enforcement - as did I), this does not mean that the FBI cannot arrest them at any time and charge them with a felony. Indeed, sale to law enforcement is not legal, even though law enforcement can, on its own, build and use such tools. The effects on research and education are even more interesting. For example, I am having a discussion with my university now about canceling courses on forensics and cryptanalysis because in these courses we teach people how to get around protection of this sort and may provide the capabilities to do so in so teaching. The DMCA has, I believe, made this illegal - and if you are teaching such a course next semester, you might think about the issues as well. On the research side, I don't work on research I cannot publish, so I am canceling the aspects of my research that go into these areas. Fred Cohen Fred Cohen & Associates.........tel/fax:925-454-0171 fc@all.net The University of New Haven.....http://www.unhca.com/ http://all.net/ Sandia National Laboratories....tel:925-294-2087 ------------------------------ Date: Fri, 17 Aug 2001 21:36:04 -0700 From: "Bill Weitze" Subject: Re: Why I don't publish my HDCP results (Ferguson, RISKS-21.61) Hmm, a blind person could sue the publisher under the Americans with Disabilities Act. > Why did the movie industry campaign for the DMCA if it doesn't work? The > movie and record industry have a history of claiming that new technologies > will bankrupt them. They complain about paper books, too. In the September 18, 2000 issue of U.S. News and World Report, p. 55, an article titled "The empire strikes back" states the following: A typical book, for example--the old-fashioned kind--finds its way to five or six readers beyond the original purchaser, according to Laurence Kirshbaum, CEO of Time Warner's trade-publishing arm. "One of the attractions of electronic publishing," he says, is the ability to "cut down on this pass-along." I wrote to U.S. News as follows: This "loaning", as its practitioners call it, is indeed most subversive. There are even institutions, called "libraries", which carry on this sort of thing in a wholesale fashion. This was started by a very dangerous individual named Franklin; maybe Mr. Kirshbaum should sue him. Bill Weitze, San Jose, CA ------------------------------ Date: Fri, 17 Aug 2001 16:38:04 -0700 From: David Gillett Subject: Re: Why I don't publish my HDCP results (Ferguson, RISKS-21.61) To my mind, one of the more dangerous aspects of DMCA is the deliberate conflation and confusion of "copy protection" (use restriction mechanisms) with "copyright protection". Experience has already shown that the former are not an acceptable substitute for the latter, a lesson which DMCA attempts to unlearn by fiat. ------------------------------ Date: Tue, 21 Aug 2001 18:55:08 +0100 From: "Mike Perry" Subject: Re: rot13 (RISKS-21.58 and .59) If companies are using rot13 to "encrypt" copyrighted information, doesn't that make every unix user in the USA a criminal under the DMCA? It would be interesting to see what would happen to "the system" if a few million people went to the police and confessed... ------------------------------ Date: Fri, 17 Aug 2001 23:03:31 -0500 (CDT) From: james.paul@mail.house.gov Subject: Hack the Vote? Not in Broward County! In RISKS-21.61, Adam Shostack noted that Broward County was apparently going to let students have a crack at their new touch-screen voting systems. Bob Cantrell, director of intergovernmental affairs for the Broward Supervisor of Elections, claims that this will not happen. [Source: William Welsh, 17 Aug 2001 *Washington Technology*, PGN-ed from http://www.washingtontechnology.com/news/1_1/daily_news/17017-1.html] ------------------------------ Date: Fri, 17 Aug 2001 19:35:42 -0400 From: "Bill Hopkins" Subject: Re: Runway incursions The runway-incursion system that's behind schedule (RISKS-21.60) is the Airport Movement Area Safety System (AMASS). It uses data from the Airport Surface Detection Equipment (ASDE-3), a primary radar. "Primary" means it relies on reflections, not transponders, for detection and ranging. It seems to me that any system that relies only on position tracking is going to have a tough time reliably detecting incursions without racking up lots of false alarms. The distance from the hold-short line to disaster is so small and the time to react so limited that the alarms have to be set to go off on very small changes. Variations in RF propagation, changing reflections from other moving aircraft (or service trucks), and system instabilities almost guarantee that they will when nothing is wrong. The technical folks may be able to tune each system to a level that ATC finds acceptable, but it will be slow, labor-intensive, frequent, site-specific, and expensive. Results will vary from facility to facility. Much better systems are technologically feasible. Flight Management Systems know when the aircraft is stopped, when its brakes are off, when the engines are spooling up. A prototype FAA system controls red Runway Status Lights (RWSL) for visual back-up to "hold short" instructions, based on whom the controller has cleared to use the runway. The next generation aircraft radios have provision for addressable data link. Moving map displays are increasing common. Limited vocabulary speech understanding is increasingly reliable. Mix these together with some intelligent design for the controller's display, and the runway monitor can raise a fuss when the pilot fails to acknowledge a "hold short", or the brakes come off too early, not when the radar jitters. Most operational errors by ATC and pilots will be prevented by putting redundant information where it is useful instead of relying on memory; others will be caught and corrected early. Life will be good. Stocks will rise. Politics will be civil. PGN's puns will all be funny. To all of us. The risk: believing it might actually happen in our lifetime? Bill Hopkins (whopkins@wmi.com, no longer in the ATC biz) ------------------------------ Date: Fri, 24 Aug 2001 16:06:13 +0100 From: Alistair McDonald Subject: Code Red 9? Code Crimson Two weeks into the Code Red exploit, when variant II or III or whatever you want to call it was particularly active, incidents.org noticed that another MS security flaw was being exploited. Their report is here http://www.incidents.org/diary/august2001.php#132. They give no data as to how many compromised systems are out there, possibly the reported probes are all an attempt to "jump start" the worm. The vulnerability is described at http://www.microsoft.com/technet/security/bulletin/ms01-023.asp. Again, there has been a patch available for some time (since May, apparently), yet I'm sure that some systems will be unpatched. My Win2K SP2 machines did not need the patch, so I guess it's installed with SP2. When will the world wake up and stop buying software from a software company that obviously can't write software well? [Actually, the buying decision is probably done by people who know little about software, IMO]. Alistair McDonald, Bacchus Consultancy Ltd http://www.bacchusconsultancy.com ------------------------------ Date: Fri, 17 Aug 2001 17:26:03 -0400 (EDT) From: "Sharon Mech" Subject: AT&T - the computer MUST be right! Our long distance service is plain, vanilla AT&T service. Long-distance charges appear on our local Ameritech phone bill. This past month, we got a bill showing charges for the AT&T One Rate plan, for which we had not signed up. (We also have an anti-slamming policy signed & on file.) So I called Ameritech. After negotiating their automated attendant hell, I was told that there was nothing they could do - I needed to call AT&T. At AT&T, more automated attendant hell. When I get the rep on the line, I give her my phone number and name, and explain the problem. She tells me that she can't help me, because our phone number has someone else's name on it, and neither I nor my husband is that person (whose name she will not reveal - I guess privacy does matter!) and she can't give me to a supervisor, thank you for calling AT&T! Just a note: We've lived at our house for 7 years, and always had the same area code and phone number. Apparently the AT&T record had been changed in February of this year, and our phone number was now associated with a different name and address. If there was a notation of who authorized the change, she sure didn't tell me - after all, it wasn't my phone line.... Back to Ameritech. Their rep confirmed that our line was indeed our line, in my name, at our address. I was fortunate - this rep had initiative. Once I explained the situation (took a couple of repeats) he put me on hold & called AT&T to set up a conference call. Things almost fell apart at this point, because Ameritech reps have a pretty strict time limit on their calls. We got an AT&T rep on the phone at just about the limit. He went on to explain to the AT&T rep that my line was really my line. She wasn't buying it - after all, her computer MUST be right, but finally grudgingly agreed to amend her record, noting his ID, info, etc. as justification. Finally we could get to the point of removing the unwanted calling plan. Mission accomplished. One last detail - the calling plan cost a certain amount, but also involved a credit. Because the plan changes tariffs & long distance rates, our long- distance usage (minimal) had been billed at the wrong rate, and neither of the reps could tell me what we actually owed. Sharon Mech ------------------------------ Date: Mon, 20 Aug 2001 08:59:45 +0100 From: "Leeming, Geoffrey" Subject: Re: DejaGoogle rides again (Weingart, RISKS-21.61) What risks? If you read a post in Deja/Google it gives you a nice link to the rest of the thread. Full marks to Google for only giving one link to the thread as a whole, not one to each of the entries. If it had been the wrong thread, getting one link to each entry would have meant that the next search result would have been pushed way down the list. Geoffrey Leeming, Technical Security Manager Lehman Brothers International Ltd. +44 (0) 20 7260 1338 [Also noted by several others. PGN] ------------------------------ Date: Wed, 22 Aug 2001 09:14:01 +0100 (BST) From: AlphaLau Subject: Re: Risks of automated junk/spam filters (Loftis, RISKS-21.60) Unfortunately, this happens with Yahoo Mail as well. Their "Bulk Mail" feature is similar, and you used to be able to specify if an email was indeed not spam. Of course what they actually did with it... Y!Mail also has a nifty "Block email from this Address" feature that will send email with those addresses into a blackhole. I have suggested to Yahoo to keep a log of blackholed emails, just the date, from, to & subject fields should be enough. All I got in reply was, that is how the blocking works. Use Y!Mail Filter to manually handle it. So in effect, users are saddled with 2 spam "features" that are not really useful. I have disabled both. Still, Y!Mail is one-up on Hotmail with it's block-mail feature! :) Alpha ------------------------------ Date: Mon, 20 Aug 2001 17:44:25 +0300 From: Kimmo Subject: Yet another MS Hotmail risk One addition on Michael Loftis' article about MS's Hotmail service (http://catless.ncl.ac.uk/Risks/21.60.html#subj11): I also have a Hotmail account to handle the private mail and I noticed today an interesting behaviour concerning the Junk Mail-folder: Now, logging in this morning (Aug 20) I noticed a warning mail from Hotmail Staff (Aug 18) that my account size is too large. Opening the mail was impossible, because all I got was a warning that I was 5120K over my quota. Someone's spam bot had gone to overdrive and sent over 600 spams to my account (all similar and from the same address, size about 10K). Emptying the Junk Mail folder (and blocking the spammers address) meant that I could again use my account normally and also read the mail from Hotmail Staff, which told me that if I didn't react before Aug 23, Hotmail would start "deleting messages (usually older ones from all of your folders) until your account is smaller than the 2-MB size limit". Apparently, this is normal behaviour for MS Hotmail, as I managed to find out in the service conditions. 5 days reaction time, before we start emptying your account starting from the oldest. The risk? If someone does not check his/her Hotmail for a week (eg. vacation, illness), it is very easy to remove all his/her mail from all the folders by simply sending in too much spam. Including the Junk Mail-folder into the account size limit makes this kind of "denial-of-mail" very easy, because mail in a Junk Mail folder isn't deleted for 14 days from it's arrival. Fortunately, I don't trust WWW-based email services enough to use them for anything important but still: wiping out your email box is a nuisance. Kimmo Pyykkö, Development Manager, New Communications Services/ Technology Center tel. +358 2040 58328 ------------------------------ Date: Mon, 20 Aug 2001 10:42:59 -0800 From: Rob Slade Subject: REVIEW: "SSL and TLS", Eric Rescorla BKSSLTLS.RVW 20010607 "SSL and TLS", Eric Rescorla, 2001, 0-201-61598-3, U$39.95/C$59.95 %A Eric Rescorla ekr@rtfm.com %C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8 %D 2001 %G 0-201-61598-3 %I Addison-Wesley Publishing Co. %O U$39.95/C$59.95 416-447-5101 fax: 416-443-0948 %P 499 p. %T "SSL and TLS: Designing and Building Secure Systems" The preface states, quite clearly, that this is a work for designers, programmers, and implementors. In other words, it's a very technical book. Even the preface, though, is written with a clarity that is unusual, and refreshing, in technical literature. Chapter one provides some background to communications security and encryption. The material is demanding, and is definitely not a primer. A number of items are glossed over, but the persistent reader should be able to glean some very solid explanations of important concepts. The "family tree" of SSL (Secure Sockets Layer) is given in chapter two, with a description of the development steps along the way. Chapter three outlines the basic, or most common, mode of SSL, and then provides details about specific aspects of the algorithms and data structures used at different points. Various options and extensions, for a number of functions, are described in chapter four. The security of the SSL system itself, as opposed to the security it provides for transactions, is thoroughly examined in chapter five. Chapter six is an examination of performance issues, and the ways in which execution can, and can't, be improved. SSL is, of course, only a protocol and not a full application. Design considerations for effective use within a system are detailed in chapter seven, and sample C and Java code for effecting the operations is given in eight. SSL was designed for, and is most widely used with, HTTP (HyperText Transfer Protocol), and chapter nine details the requirements and difficulties of using the system to secure Web communications. Chapter ten uses SMTP (Simple Mail Transfer Protocol) as an example of the use of SSL to protect other communications operations. Finally, Rescorla compares SSL to the major competing systems of IPsec, S-HTTP (Secure HTTP), and S/MIME. (It is nice to see that the author identifies his own potential bias in the debate.) This book is aimed at a technical audience, and members of that group will undoubtedly welcome it. However, the lucid presentation, and range of security concepts covered make this a useful reference for many others. Those involved in online commerce and the necessity to secure transactions over insecure links will find solid discussions addressing those issues. Security analysts and practitioners may be challenged to look into the internals of systems generally examined only at a superficial level. And anyone interested in the security of the Internet will find a clear and fascinating review of its underpinnings. copyright Robert M. Slade, 2001 BKSSLTLS.RVW 20010607 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: Thu, 23 Aug 2001 08:31:18 -0400 From: Anup Ghosh Subject: Dependable Systems and Networks DSN-2002 Call for Contributions The International Conference on Dependable Systems and Networks (DSN-2002) Bethesda, Maryland, USA 23-26 Jun 2002 http://www.dsn.org Full papers and workshop proposals due 19 Nov 2001 This conference has combined the International Symposium on Fault-Tolerant Computing (FTCS), the Working Conference on Dependable Computing for Critical Applications (DCCA), into the DSN track now called Dependable Computing and Communications, and in 2002 will also include the International Performance and Dependability Symposium (IPDS). See www.dsn.org for submission information. [PGN-ed for RISKS] ------------------------------ 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.62 ************************