Text File

precedence: bulk Subject: Risks Digest 20.46

RISKS-LIST: Risks-Forum Digest Saturday 19 June 1999 Volume 20 : Issue 46

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 <URL:http://catless.ncl.ac.uk/Risks/20.46.html> and at ftp.sri.com/risks/ .

***** THE ANNUAL SEASONAL SLOWDOWN BEGINS NOW. ***** ***** BIG BACKLOG of incremental stuff not included. ***

Contents: NASA discloses space station blunder (SigmaXi ScienceInTheNews) Y2K test sends sewage flowing in Los Angeles (Henry Baker) Resetting the A320 computer (Diomidis Spinellis) Intuit/Quicken Force Users to Internet & MS Internet Explorer (Lauren Weinstein) MS Word not as helpful as it thinks (Bill Shymanski) YANTBOF: yet another NT buffer overrun flaw (Epstein Jeremy) New ATM hazard (Aahz Maruch) Yet another ATM scam (Mike Williams) The cell phone that wouldn't stay OFF (Michael Heilman) Another case of credit-card 'security' (David Alexander) Maldesigned computer system slows background checks (Kragen Sitaker) Factoid paranoia (Mike Giroux) Risks of keywords in CSV files (Rex Black) REVIEW: "Intrusion Detection", Edward G. Amoroso (Rob Slade) Abridged info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: Fri, 18 Jun 1999 11:39:49 -0400 From: inthenews <inthenews@SIGMAXI.ORG> Subject: NASA discloses space station blunder

A blunder by flight controllers prevented the new international space station from moving out of the way of dangerous space junk. The rocket debris ended up passing at a safe distance. NASA said the sequence of computer commands sent up by flight controllers to fire the station's engines over the weekend failed because of human error. It disclosed the incident Thursday.

Initially, the U.S. military organization that tracks objects in space predicted the rocket chunk would pass within two-thirds of a mile of the space station on Sunday. It ended up coming no closer than 4 1/2 miles. http://www.latimes.com/HOME/NEWS/WIRES/WHEALTH/tCB00V0366.html [*The Los Angeles Times, 18 Jun 1999*; From SCIENCE-IN-THE-NEWS]

Sigma Xi Homepage http://www.sigmaxi.org Media Resource Service http://www.mediaresource.org American Scientist magazine http://www.sigmaxi.org/amsci/amsci.html

------------------------------

Date: Fri, 18 Jun 1999 06:45:45 -0700 From: Henry Baker <hbaker@netcom.com> Subject: Y2K test sends sewage flowing in Los Angeles

A supposedly routine test of LA's Y2K readiness of the emergency preparedness system at the San Fernando Valley sanitation plant caused about 4 million gallons of raw sewage to be dumped into the Sepulveda Dam area. A gate to a major sewer pipe closed without warning because of a programming error. [Source: article by Miguel Bustillo, Karima A. Haynes, Patrick Mcgreevy, http://www.latimes.com/HOME/NEWS/FRONT/t000054865.html, *L.A. Times*, 18 Jun 1999; PGN-ed]

------------------------------

Date: Sat, 19 Jun 1999 03:05:01 +0300 From: Diomidis Spinellis <dspin@aegean.gr> Subject: Resetting the A320 computer

I was travelling from Athens to Munich on Lufthansa flight LH 3425 on 16 Jun 1999. Shortly before taxiing for takeoff, our A320 plane left the runway and moved aside. The captain immediately informed us that we were having a slight technical problem that they would try to rectify and that we would be given further information in a short while. About five minutes later the following announcement was made:

"Ladies and Gentlemen this is your captain again. We had to reset two of our computers and now it is looking real fine again."

During the flight the crew kindly allowed me to talk to the first officer about the incident. My prepared list of questions concerned the problem domain, its criticality, frequency of occurrence, and reporting procedures. According to the captain, the problem occurred on a flight control computer (ELAC1) and involved erroneous position monitoring of the right elevator. The officer assured me that the problem was not critical, occurred on only one of four different reports and although it was part of a ground checklist it would not have been a problem during the flight. I was told that such problems sometimes do occur and that the problem had already been reported by telex to the airline's maintenance base.

Here is a verbatim - I hope - transcription from a printed log I was shown:

F/CTL servo fault R Elevator POS MON XDLR

(Disclaimer: I am not an aviation expert; the report is my - perhaps limited - understanding of the captain's answers.)

The risks? As far as I know modern flight-control computers do not need a reset before takeoff*, nor should a reset be needed after a human operator error. Obviously a software or hardware fault had caused the computers to malfunction. Since resetting a computer does not typically isolate and correct faults (otherwise Windows would long have reached a 0% defect rate), we were flying on a plane with a known and demonstrated software fault. Although the problem manifestation was on a non-critical area, we all know that the underlying cause could well result in more serious side-effects since it occurred on a critical flight control component. More worryingly, this appeared not to be a singular event.

[*] Interestingly the Space Shuttle software does need to be reloaded between different flight phases. A fascinating description can be found in Gene D. Carlow. Architecture of the space shuttle primary avionics software system. Communications of the ACM, 27(9):926-936, September 1984.

Diomidis Spinellis, University of the Aegean

------------------------------

Date: Sat, 19 Jun 99 12:22 PDT From: privacy@vortex.com (Lauren Weinstein in PRIVACY Forum) Subject: Intuit/Quicken Force Users to Internet & MS Internet Explorer

PRIVACY Forum Digest Saturday, 19 Jun 1999 Volume 08 : Issue 09

Moderated by Lauren Weinstein (lauren@vortex.com) Vortex Technology, Woodland Hills, CA, U.S.A. http://www.vortex.com

Date: Sat, 19 Jun 99 09:46 PDT >From: lauren@vortex.com (Lauren Weinstein; PRIVACY Forum Moderator) Subject: Intuit/Quicken Force Users to Internet & MS Internet Explorer

Greetings. Just as the banking industry in the U.S. has been issuing concerns about the security of Internet and Web-based banking systems, one of the biggest players in the online banking industry, Intuit, makers of Quicken, have quietly moved to force all of their users onto the Internet for all online banking services, and in some cases are requiring the use of Microsoft's Internet Explorer instead of other browsers such as Netscape Navigator.

Catherine Allen, chief executive of the Banking Industry Technology Secretariat, a division of Bankers Roundtable, recently said, "The banks feel that firewalls and what they have internally is in great shape, but the link is to the consumer and PC environments [where they find security more suspect]."

While newer versions of Quicken software have apparently been Internet-based for some time, many users had opted to stay with older versions since they used direct dialup lines for communications, and did not rely on Microsoft's Internet Explorer.

However, Intuit (and/or in some cases users' banks) over the last two months or so have been sending out a somewhat confusing series of letters, informing these users that their versions of Quicken are not "Y2K" compliant, and that they must upgrade by designated nearby dates (e.g. June 30, 1999) or lose their online banking access. Some materials simply suggested that certain features (such as pre-scheduled bill payments) would have problems past Jan 1 2000--other materials claimed a total cutoff of services to non-upgraded users. Sometimes the same letter seemed to make both statements.

Intuit and/or user banks made a number of options available, including a free minimalist downloadable upgrade and various payment-based enhanced upgrades. However, the fine print of these offers (sometimes buried at the end of the letters) indicated that all access would be via the Internet for these new versions. Arrangements for limited free Internet access would be available to those who didn't already have an Internet Service Provider, the letters suggested.

I spent a couple of weeks clarifying this whole situation with Intuit and their public relations firm through a lengthy series of phone calls. While it wasn't difficult reaching Intuit's public relations folks, getting to people who could answer technical questions at this level was a bit more of an effort. However, everyone involved was polite and willing to address my questions in a direct manner to the extent that they could.

The bottom line is that all users of older Quicken software *do* need to upgrade and *will* be using the Internet for all future transactions. There will be limited free Internet access available for Quicken transactional use (I believe an hour a month, which would be sufficient for this purpose) for people who need the service. It is a bit unclear how long this free access would be available--one person suggested indefinitely, but this does not appear to be a guarantee.

I'm told that existing users doing the minimalist upgrade from older Quicken versions (e.g. Version 5 for Windows) will not need to install or use Internet Explorer (IE) for most online operations. Users of the more sophisticated upgrades may be required to use IE for more functions, and *all* new users of Quicken will be required to install and use IE for secure signup--Intuit claims that Netscape doesn't have the "required" functionality for this purpose.

I'm also told that the "standard" installation option of many or all of these new Quicken versions will install IE by default. This means that if you do not want an IE installation (and if you're in a category of existing user that doesn't need it) you would probably have to disable the IE installation via the "custom" installation options of the Quicken setup program. This could be particularly important to users who may be concerned about losing existing associations and defaults for any other web browser already installed (which may be affected by an IE installation), or where security concerns over IE's ActiveX functions and other related system complexities are present.

I have in the past expressed other concerns with Quicken. A continuing problem is that if online banking transactions are not downloaded at frequent enough (unannounced) intervals, transactions will be silently lost and all related calculations and records from that point onward will be in error unless manually corrected. Intuit's response to this issue continues to be suggesting that users have paper records to fix such problems, and that most users access their data frequently enough that it isn't an issue for them. Frankly, I would argue that this rather negates much of the point of using the software in the first place, if you can't trust the transaction record, even if relatively few people might be affected by this particular undocumented problem! I did by the way again suggest (this time to a Quicken product manager) that users at *least* be warned when transactions have been lost--they again said they'd consider it...

So, if you're a Quicken user, and you've recently been told you need to upgrade due to that mean old Y2K monster, you're not alone if the situation seemed a bit confusing based on the materials you received in the mail.

PRIVACY Forum Digest V08 #09, Lauren Weinstein --- http://www.vortex.com Host, "Vortex Daily Reality Report & Unreality Trivia Quiz" --- http://www.vortex.com/reality

------------------------------

Date: Sat, 19 Jun 1999 13:33:09 -0400 From: Bill Shymanski <wtshyman@mb.sympatico.ca> Subject: MS Word not as helpful as it thinks

I recently helped edit a specification, in which a list of items to be supplied had the wrong quantities shown. It turns out Microsoft Word 97 though that the list beginning "1 Rack", and continuing on from there, was supposed to be a numbered list - so Word "helpfully" automatically incremented what was meant to be the quantity field as if it were sequence numbers of a list. Luckily this was caught at draft stages, but the risk of getting quantities wrong is present.

On the whole, I find that features of this nature cost more time than they save; the software is never smart enough to figure out what I really want and when it guesses, it usually gets it wrong. I'd sooner type my own numbered lists than fight with the word-processor. Automatic renumbering is also fairly useless if you happen to refer elsewhere in the document to, say, item 3.4.5 and Word has renumbered it after the reference was created.

W. T. Shymanski <wtshyman@mb.sympatico.ca>

------------------------------

Date: Fri, 18 Jun 1999 06:53:49 -0700 From: "Epstein, Jeremy" <Jeremy_Epstein@NAI.com> Subject: YANTBOF: yet another NT buffer overrun flaw

Just in case anyone hasn't seen it already: http://www.eeye.com/database/advisories/ad06081999/ad06081999.html for the technical info, or http://www.wired.com/news/news/technology/story/20285.html for a higher-level description.

This was also mentioned briefly in *The Washington Post*, 18 June 1999.

--Jeremy

[And Microsoft is accusing eEye of unfairly releasing information on this flaw, whereas eEye is claiming they notified MS -- which did not fix it rapidly enough. The obvious comment must be Old McRosoft had affirm: eEye, eEye, Owe! See http://www.excite.com/computers_and_internet/tech_news/zdnet/ ?article=/news/19990617/2277295.inp PGN]

------------------------------

Date: Thu, 17 Jun 1999 09:30:08 -0700 (PDT) From: Aahz Maruch <aahz@netcom.com> Subject: New ATM hazard

UTM Systems (http://www.utmsystems.com/) is offering a new ATM card reader that goes into the floppy drive of a PC. I wonder how easy it'll be to crack the system to collect passwords -- they're advertising it for use in point-of-sale systems.

------------------------------

Date: Wed, 16 Jun 1999 11:13:05 +0100 From: "Mike Williams" <mikew@harlequin.co.uk> Subject: Yet another ATM scam

There was report in the Preston Citizen (Lancs. UK) last week about a new ATM scam. This has taken place at ATMs at large supermarkets. Basically, 'devices' have been added to the exterior to get the pin number and read the card's magnetic strip -

'One device is an invisible key pad which is placed over the existing keys, which records the pin number, while another invention placed over the card slot copies the data on a magnetic strip. ... Because the user gets the card back and the cash requested they believe nothing is wrong. ... Police fear hundreds of local people have been affected by the scam. ... "We have talked to around 200 victims locally, most of who have been losing varying amounts in 250UKP sums."'

The bank has reportedly put a warning on its ATMs (I don't use there ATMs) warning customers to be on the lookout, and advises customers that if '... they see anything suspicious on a machine they should not use it.'

It seems supermarket ATMs were targeted since the crooks can easily keep an eye on them from the car park, plus have unobserved access to them at night - the supermarkets are usually on the edges of towns with minimal lighting.

No need to point out the risks ...

------------------------------

Date: Thu, 17 Jun 1999 13:06:08 -0400 From: Michael_Heilman@infoimage.com Subject: The cell phone that wouldn't stay OFF

My wife and I received a very long, very unusual message on our answering machine one day. Under a complex layer of foreground noises, there was a discernible conversation being recorded. After listening to it several times and recognizing personally significant phrases, we were quite concerned. It took several puzzling hours to realize what had happened: my wife had slipped her cell phone into her purse and as we were walking down the street, something pressed against the re-dial and called our home phone. Our answering machine recorded our muffled conversation under a layer of noises from the phone rubbing and jostling.

The RISK became apparent a couple of week later when my wife received a call from a business colleague asking if she had just called him back after their conversation, because he had just overheard the strangest sounding phone call. Well, what he heard, by the same mechanism, was my wife discussing, with someone else, her previous conversation with him right after hanging up and putting her phone away. Luckily, she had had nothing derogatory or confidential to say!

Looking for a solution: the phone has a keyboard lock that requires pressing 1-2-3 to unlock ... pretty good, but not foolproof. If the phone is turned off, it is very easy for it to get turned back on--just a quick press of one button.

------------------------------

Date: Wed, 16 Jun 1999 10:19:53 +0100 From: David Alexander <dave_ale@online.rednet.co.uk> Subject: Another case of credit-card 'security'

Yesterday I telephoned my credit card company to make some enquiries about various options they were offering. It was the first time I had called them for at least a year. Imagine my surprise when I was first asked to enter my credit card number in full and then informed that 'in order to improve security I needed to decide on a 4 digit number to be used to verify who I was in future'. I was then asked for my date of birth and the expiry date on my card as proof of who I was before being allowed to give them a number.

Hopefully the alarm bells have already gone off in your heads like they went off in mine. The whole idea is so full of holes and risk. Anyone who has accepted my card will have the full number and expiry date. Here in the UK you can get a copy of a Birth certificate with minimal difficulty, so anyone could ring up purporting to be me and 'swipe my identity' [pun intended]. I haven't sat and thought through in detail exactly what scams they could then pull off by telephone in terms of obtaining items by deception or simply wrecking my relationship with the company.

Be careful what you do on the phone.

David Alexander, Camberley, England, Founder member, European Top Methanol Racers Association http://home.rednet.co.uk/homepages/dave_ale/dave_ale.html

------------------------------

Date: Tue, 15 Jun 1999 17:23:26 -0400 (EDT) From: kragen@pobox.com (Kragen Sitaker) Subject: Maldesigned computer system slows background checks

I expected to see this in the latest RISKS. It appeared in USA Today on 1999-06-03, page 1A and 2A, in an article entitled, "Pentagon crisis: Security-check backlog." Amid discussion of various kinds of mismanagement, agency politics, and the effects of the backlog (capsule summary: people like me who have security clearances get them by filling out some forms and then having Defense Security Service people chat with everyone they've known for the last ten years, and the process takes way too long), there was this juicy tidbit:

That flap was nothing compared to the problems that have emerged in the past eight months, since the security service turned on its new computer system at its Baltimore operations center. The Case Control Management System, or CCMS, [outgoing DSS director Steven] Schanzer says, was designed to "automate the management of the investigative process." But, say DSS officials, the system isn't working and there is no backup operation in place. [It's not clear whether they decommissioned an older computer system without thorough testing of a new one, or whether they just didn't have an older computer system that did the things this one does.]

Last April, the computer system crashed for four days, meaning ... "no internal or external customers could get information from the system."

Schanzer says the problem is simple: the system choked on paper. It was designed to take electronic questionnaires from security applicants, but it was deluged with tens of thousands of paper submissions.

Another problem: The agency assumed applicants would fill out the forms correctly. In many cases, that hasn't happened, and the system can't detect the errors, Schanzer says. [Is this connected to forms being filled out by hand instead of via EPSQ, which won't allow submission of forms with certain kinds of errors? Or is this a separate problem? Is this related to the crash?]

There is yet a third problem. Schanzer says the agency now has figured how to get the paper through the system, but once a case is completed, it takes about 20 days to get a print-out. [What? Why? No clues here.] ... "It should take no time at all," he explains. [...]

"We are bringing on an independent team to assess where we are with the computer system," he [John Hamre, deputy Secretary of Defense] says. "I need to know if we are barking up an empty tree" with the existing system, or whether it should be replaced.

Earlier parts of the article explain that many, many people are getting paid to sit around and do nothing until their clearances are granted (or denied, in which case they are fired), and that soon, some classified contracts will cease to progress until clearances are granted, and that the NSA has recently gotten an exemption from the Pentagon to hire PIs to do the NSA's background checks, instead of relying on DSS.

The RISKS are not clear here, due to (what appears to be) USA Today's usual shoddy reporting. It sounds like the usual problem of undue reliance on untested software that was designed without reference to real life.

<kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>

------------------------------

Date: Tue, 15 Jun 1999 05:25:14 PDT From: Mike Giroux <rmgiroux@hotmail.com> Subject: Factoid paranoia

An interesting research project is described at

http://www.research.digital.com/wrl/projects/Factoid/index.html

Basically, this is a device that would log all of the small "factoids" that a person passes by each day (broadcast by other factoid devices in billboards or business cards, for instance), and then upload them into a home database in a secure way at any opportunity.

This system is only in the theoretical stages, so this isn't an urgent problem. However, my worry about the factoid system is about the "subpeona-bility" of the home database. Would you want a step-by-step record of where you went and who you saw each day of your life available to anyone who wants to start a nuisance civil suit against you?

Apart from that concern, though, it looks like a cool toy, and maybe even a useful tool. Maybe if "factoid privilege" were part of the law, this thing could take off.

Mike

------------------------------

Date: Tue, 15 Jun 1999 17:20:34 -0500 From: Rex Black <rexblack@ix.netcom.com> Subject: Risks of keywords in CSV files

Here's a fun "file portability" bug that sucked up a couple hours of my day.

1. Create a comma-separated variable file with three or four variables.

2. Name the first column "ID".

3. Try to import the file into Excel 97. You will receive a "Sylk: File format invalid" error.

4. Rename the first column "BugID".

5. Repeat step three. No problem.

I'm guessing that the file import facilities use the word "ID", if it occurs in the first two bytes of a file to be imported, as a keyword meaning, "The next few bytes will tell you what type of file this is." When the next few bytes are just the headers for the rest of the columns, Excel pukes.

The Risk? In my opinion, this is the old "laconic/cryptic error message" risk. Had the error message said, "Keyword 'ID' followed by invalid type," I would have gotten it right away. Instead, I went off on a wild goose chase involving fix-width columns, tab-separated columns, and the like, before I tried twizzling the header and--behold!--it worked.

Rex Black Consulting Services, Inc., 7310 Beartrap Lane, San Antonio, TX 78249 +1 210 696 6835 http://www.RexBlackConsulting.com

------------------------------

Date: Thu, 17 Jun 1999 08:43:56 -0800 From: Rob Slade <rslade@sprint.ca> Subject: REVIEW: "Intrusion Detection", Edward G. Amoroso

BKINTDET.RVW 990423

"Intrusion Detection", Edward G. Amoroso, 1999, 0-9666700-7-8, U$49.95 %A Edward G. Amoroso eamoroso@mail.att.net %C P. O. Box 78, Sparta, NJ 07871 %D 1999 %G 0-9666700-7-8 %I Intrusion.Net Books %O U$49.95 973-448-1866 fax: 973-448-1868 order@intrusion.net %P 218 p. %T "Intrusion Detection"

This is not (very much not) to be confused with the identically named, and almost equally recent, book by Escamilla (cf. BKINTRDT.RVW). Where Escamilla's is basically a large brochure for various commercial systems, Amoroso has specifically chosen to avoid products, concentrating on concepts, and not a few technical details. The text is based on material for an advanced course in intrusion detection, but is intended for administrators and system designers with a security job to do.

Chapter one, after demonstrating that the term means different things to different people, gives us an excellent, practical, real world definition of intrusion detection. This is used as the basis for an examination of essential components and issues to be dealt with as the book proceeds. Five different processes for detecting intrusions are discussed in chapter two. Each method spawns a number of "case studies," which, for Amoroso, means looking at how specific tools can be used. (This style is far more useful than the normal business case studies that are long on who did what and very short on how.) Intrusion detection architecture is reviewed in chapter three, enlarging the conceptual model to produce an overall system. Chapter four defines intrusions in a way that may seem strange, until you realize that it is a very functional description for building detection rules. The problem of determining identity on a TCP/IP internetwork is discussed in chapter five, but while the topic is relevant to intrusion detection, few answers are presented. Correlating events is examined in chapter six. Chapter seven looks at setting traps, primarily from and information gathering perspective. The book ends with a look at response in chapter eight.

The bibliography is, for once, annotated. While I do not always agree with Amoroso's assessments; I think he tends to give the benefit of the doubt to some who primarily deliver sensation; the materials are generally high quality resources from the field. Books and online texts are included, although the emphasis is on journal articles and conference papers.

The content is readable and, although it seems odd to use the word in relation to a security work, even fun. I suppose, though, that I must point out that your humble "worst copy editor in the entire world" reviewer found a significant number of typographic errors. (And some that can't be put down to typos: I think you'll find that it's "berferd" rather than "berford.")

This book works on a great many levels. It provides an overall framework for thinking about security. It thoroughly explains the concepts behind intrusion detection. And it gives you some very practical and useful advice for system protection for a variety of operating systems and using a number of tools. I can recommend this to anyone interested in security, with the only proviso being that you are going to get the most out of it if you are, indeed, responsible for designing network protection.

copyright Robert M. Slade, 1999 BKINTDET.RVW 990423 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: 23 Sep 1998 (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 <risks-request@csl.sri.com> with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] .MIL users should contact <risks-request@pica.army.mil> (Dennis Rears). .UK users should contact <Lindsay.Marshall@newcastle.ac.uk>. => 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.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 19" for volume 19] or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. PostScript copy of PGN's comprehensive historical summary of one liners: illustrative.PS at ftp.sri.com/risks .

------------------------------

End of RISKS-FORUM Digest 20.46 ************************