>From sci.space.news Fri Aug 27 11:32:16 1993 >Newsgroups: sci.space.news >From: baalke@kelvin.Jpl.Nasa.Gov (Ron Baalke) >Subject: Mars Observer Update #2 - 08/26/93 >To: email@example.com >Followup-To: sci.space >Forwarded from: >PUBLIC INFORMATION OFFICE >JET PROPULSION LABORATORY >CALIFORNIA INSTITUTE OF TECHNOLOGY >NATIONAL AERONAUTICS AND SPACE ADMINISTRATION >PASADENA, CALIF. 91109. (818) 354-5011 > > MARS OBSERVER MISSION STATUS > August 26, 1993 > 2:30 p.m. Pacific Daylight Time > > Communications with the Mars Observer spacecraft have not yet >been restored, one and a half days past its planned insertion into >orbit around Mars. > > Mission controllers at JPL continued through the night and >morning with efforts to re-establish the necessary radio link with >the spacecraft by cycling the various elements of the >communications system. > > At 2:37 p.m. Pacific Daylight Time today, the continued >execution of the command loss timer subroutine will try to position >the spacecraft for optimum pointing and will switch antennas to try >to restore communications. > > Project officials still do not believe that the propulsion >tanks leaked or exploded at the time of their pressurization. The >pressure in the tanks at launch was 285 pounds per square inch >absolute (psia). As propellants were used during the three >trajectory correction maneuvers, the pressure was reduced to about >167 psia. Pressurizing the tanks would have raised the pressure to >264 psia. Any greater pressure would require a failure of both of >the in-series pressure regulators. The burst pressure specification >of the tanks is 465 psia and actual test data ruptured tanks at 678 >psia. Flow restrictions limit the rate at which the pressure can >increase. Analysis indicates that the probability that the >pressure in the tanks would increase to the burst level within the >9 minutes that the radio transmitter was off is less than 0.1%. > > Project officials are systematically evaluating the most >probable sources of the cause of the spacecraft's failure to >communicate. > > One such source which has been receiving considerable >attention is the potential failure of the spacecraft's central >clock, whose official name is the "redundant crystal oscillator," >or RXO for short. Proper operation of this device is required for >operation of the spacecraft's central computers, which sequence the >events on the spacecraft. > > The first hypothesis for the lack of communications pointed >to the failure of the central computer to turn the transmitter back >on. Failure of the central clock would prevent the central >computer from doing its job. After sending commands to turn on the >transmitter, switching to the backup clock was the next action >taken by mission controllers. > > The central clock has been the focus of investigation because >it contains transistors which have failed in other spacecraft >applications using this type of clock. > > The launch of the NOAA-I spacecraft was delayed at the end of >June 1993 when it was discovered that its RXO had failed. A >subsequent investigation revealed that the RXO failure was caused >by the failure of a 2N3421 transistor. Two of these transistors >are used in each of the redundant halves of the RXO. Transistors >from the same manufacturing lot as those in the NOAA-I RXO are >installed in the Mars Observer RXO, making the reliability of Mars >Observer's RXO suspect. > > The transistors fail when a weld between a gold-plated post >and an aluminum wire breaks. > > This potential problem was discovered when Mars Observer was >only 55 days away from Mars after the spacecraft had been in flight >for over nine months. Because of the way that these transistors >are used in the RXO, Mars Observer would be susceptible to losing >its central clock function if one particular transistor in each >half of the RXO failed. > > There is no alternative source of the central clock function >in Mars Observer, and should the loss of this function occur, it >would be a non-recoverable situation. > > The RXO, on its primary side, was working perfectly >immediately before the pressurization activity. The last time the >backup side of the RXO was tested was in a launch GO/NO-GO test on >launch day, when it was also found to be working perfectly. > > Project officials were not, at first, concerned about the >NOAA-I RXO failure because it would take a failure of two of these >transistors to cause the loss of the central clock function. The >spacecraft is not designed to automatically protect itself against >more than a single failure in any piece of hardware. > > The restoring of the spacecraft's transmitter and the >spacecraft's failure to act on ground commands could be tied to the >loss of the central clock function. Project officials now surmise >that one explanation for the loss of communications could result >from the failure of the crucial transistor in each half of the RXO, >or its failure to autonomously switch to the backup side. Then >there would be no central timing function. This failure could have >been induced by the shock of the pressurant valves operating during >the propulsion tank pressurization event on Aug. 21, after which >communications were not restored. >[Ron Baalke, Jet Propulsion Lab, M/S 525-3684 Telos >Pasadena, CA 91109 firstname.lastname@example.org]
As far as I can tell, the real problem was control-surface rate limiting. Cf. the YF-22 crash and the Space Shuttle ALT-5 multi-axis PIO. I've flown a rate-limited configuration in a variable-stability Learjet and it looked a lot the same, just before the safety trips gave the plane back to the safety pilot. I've read the articles in AvLeak and Flight International and looked at the video a couple of times. My branch chief and some USAF handling qualities guys are going to Sweden the end of next week, too. Not controls engineers, handling qualities engineers. Mary Shafer, Dryden Flight Research Facility
The Feedback section of the latest New Scientist relates the following Computer Weekly story about an unfortunate programmer at an unnamed bank. Apparently, the bank wanted to target its wealthiest customers with a mailshot promoting various new services and the programmer in question wrote a program to select the 2000 wealthiest customers from the bank's records and to generate an appropriate letter for each. In the process of testing the program, he made use of a fictitious customer named Rich Bastard. Unfortunately, as you may already have guessed, something went amiss and every single one of the bank's 2000 prize customers received a letter which began "Dear Rich Bastard, ..." The risks involved? Well, for one thing, the hapless programmer lost his job over the incident. More generally, I suppose it's just another example of the way in which the complex interactions amongst program development, testing, and maintenance can produce unpredicted and undesirable consequences. The latter analysis is, of course, rather generous to the programmer.
Brinton Cooper quotes out of context, incidentally from a book whose subtitle reads "the Hardware/Software Interface," a line he probably intends as a subject for meditation. Saying "...minimizing the logic is both complex and error-prone and, thus, is better left to a program," has ironic overtones in this forum. But I'd bet a cup of coffee that, taken in context, it's sound engineering advice. The workstations and PCs we use to read RISKS all contain semi-custom and sometimes programmable logic chips. Reduction of the Boolean logic equations, that is, minimization of AND-OR logic terms, directly influences the size of the chips and thus their cost. Reducing large Boolean equations by hand _is_ complex and error-prone, just like programming large systems in assembly language would be. Thus it's a safe bet that the book's authors are advocating the use of design automation tools for real-world digital logic design. Chip designers would argue, justifiably, that today's automated tools decrease both design time and design risk. The RISK Cooper illustrates is in mistaking a practical viewpoint for complacency. Wes Plouff Digital Equipment Corp, Littleton, Mass.
Until recently, I had the good fortune of living in a telephone exchange without this problem, but I had heard about it from others and just couldn't believe it was so. Why do I have to dial 1 before some numbers and not before others? The computer at the phone company politely tells me to dial 1 first, or to not dial 1 first depending on where the call is made to, but this is little comfort for my autodialer making a series of several thousand calls to send out FAXes. If they can tell me to add 1 or not, why can't they just add it or not for me? The Cisco router problem is particularly important because so many people use this router to secure their network into isolated partitions. [*** Some correspondence from Cisco doubts that this vulnerability exists, and indicates that there is certainly NO INTENTIONAL TRAPDOOR. An official response follows. PGN ***] The risks of not receiving risks and risks not finding out about it may be more severe than the risks of sending out risks for all to see. My computer mail address was recently cut off, and apparently, every piece of mail sent to me was not forwarded, and not reported as undelivered! I must have missed a lot of risks that I am now vulnerable to and don't know about! Then there is the question of who got those mailings I missed. Is there a forger out there claiming to be me? Or am I the forger claiming to be him? The finger command has a few minor problems worthy of note. One is that it tells you if my mail has been removed from the mail queue, but not if I really read it. Another is pointed out if you finger me at this mailing address. Something about the plan containing false and misleading information. FC
There are no known bugs in any software providing access-control-list functionality in any current cisco software. There has only been one very obscure bug that could cause a security problem in the history of our product, and we immediately fixed this problem, published an immediate workaround, and informed CERT of this problem. We have never, and will never implement any sort of trapdoor or backdoor functionality which would allow bypassing of ordinary security systems. Paul Traina, cisco Systems [***** NOTE ADDED ON 2 SEP 1993 TO THE ARCHIVE COPY: PLEASE SEE RISKS-15.01 FOR FURTHER CLARIFICATION. PGN *****]
In RISKS-14.87, PGN repeats the oft cited claim that the sendmail debug option opens a security hole. Although it is true that earlier versions of sendmail did allow debugging to enable mail to arbitrary addresses (including programs), this hole should be well plugged by now. Conversely, encouraging people to disable all debugging options may itself cause problems. Many of the debug flags are exteremely useful when installing and debugging config files. Scaring people into turning off all debugging is not productive. By the way, despite many claims to the contrary, the security hole used by RTM was not an intentional back door -- it was a bug, plain and simple, as I've published in the past (for example, see the C Advisor column in UNIX Review 7, 1 (January 1989)). Eric Allman <eric@CS.Berkeley.EDU> [Eric, Thanks for the clarification. BTW, are you convinced that EVERYONE is using the unbuggy version? I know some systems that do not get upgraded very often --- if ever! PGN]
PGN's reply on this subject ended with > Does anyone care? I've noticed that most people tend to focus their energies on whatever "fire" happens to be blazing in front of them. I often go to a sysadmin with a clear description of some hole in security (or procedures, or ...), only to be told "I'll get to it when I can" (which means "never"). The only time that the problem gets their attention is when an actual breach (or failure) occurs, and peoples' work is lost. I can sometimes feel like taking Robert Morris' approach and breaking something just so that it will get the attention it deserves. The preceding symptom is certainly not limited to computer systems. Here in Massachusetts, there has been a rash of "child fallen out the upper-story window" incidents this summer. The cause of the problem is children playing in an upper-story room with an open window and only the screen for protection. Now that 3 children have died and 13 more spent time in hospitals, local organizations are distributing safety bars for windows. I fear that the answer to Peter's question is "No, no-one cares, until someone gets hurt." Jim Hudson <JHudson@legent.com>
In New York, NY Telephone has managed to really screw up *67 caller ID blocking -- a phone line defaults to "send caller number" mode, and dialing *67 prevents the calling number from being displayed on the other side. If you tell the phone company that you want your line to default to NOT send the calling number, they give you "all call restrict" and you are supposed to dial *67 if you WANT your number to be displayed on the other side. Naturally, there's no way to tell which way a phone line defaults to -- except for the reminder stickers that NY Tel sends you to stick on your phone. So if you're using an unfamiliar phone, just what *67 will do is undeterminate. My suspicion is that NY Tel did this to discourage people from trying to suppress Caller ID, since they want the service to be as universal as possible. My suspicions are furthered by the fact that when I installed a new line, they didn't ask me whether I wanted to default to outgoing caller ID blocking or not...
Perhaps the most annoying feature of the *67 call blocking services is that they do *NOT* block your phone number for companies that purchase commercial "caller ID" services (Automatic Number Identification) from their common carrier. For example, when you call a catalog retailer's 800 number using the *67 number, the retailer is still able to capture your phone number and add it to their data base. The *67 service only blocks your number for people who have the residential Caller ID service. The RBOCs that offer *67 call blocking services do not seem to mention this distinction. As a result, many callers are tricked into thinking that their privacy is protected through *67 when, in many cases, it is not. Stuart C. Moore
Before we go overboard with this abstraction replacing reality idea, consider that books which we have been reading for much longer than we have had computers or television are also abstractions. Audio Visual media may be a great improvement on text but they cannot become reality. Otherwise we would not go to ball games, and foreign countries, join demonstrations and meet people for lunch. As in the case of any successful abstraction people's appetite for reality is increased not diminished by the taste they get on the television or computer screen. This actually goes back to the old debate in artificial intelligence - "Can a computer become sentient?" The true question there was not whether a computer can or not but "What is sentience?" In the same way before we ask whether virtual reality can replace reality, we must first ask what is it that we call reality.
Citibank gives out an ATM PIN with it's cards. Why in the world they don't use that as telephone authentication..., I have no idea. I do. My bank has an explicit policy that bank employees are not to be told PINs--PINs are only to be keyed into machines (which presumably encrypt them before transmission). If a dishonest person who found your wallet could do damage with your authenticator, imagine the damage that could be done by a dishonest "inside person." Jim H.
Tom Swift asks (in RISKS-14.88) about the common practice of asking for and using a separate password (Mother's maiden name) for bank accounts rather than using the already secret PIN. I think Banks have the right idea here, though they often implement it poorly. There are several good reasons for not using the PIN as a telephone verification password. 1. Most banks don't give PIN access to phone clerks since the PIN poses the most direct security risk (they must allow account numbers to be identified and PIN+acct+card writer == ca$h). 2. Many smaller banks and credit unions can't change the PIN without reissuing the card or account. While their PIN system may be crippled, it is certainly wise not to risk compromising it over the phone. 3. A pin is too easy to overhear over the phone. 4. What happens when you lose (forget) your PIN? You need some way of calling to have a new one assigned. Mother's maiden name isn't ideal, but almost every bank is open about the fact that they'll take any pronounceable password. Accordingly, you can make up a good mother's maiden name and have extra security. American Express handles things somewhat differently. Usually they ask a simple question like "is anyone else on the card with you?" or "how many additional cardholders are on the account?" but they tend to ask more detailed questions when you are talking major action (as opposed to simple queries). Among the more interesting questions are ones that ask you to describe recent transactions (once I was asked for the last meal I charged on the card) which, seem like good general authentication questions that would only be troublesome if the card were already stolen and used successfully. Joe Konstan
CALL FOR PAPERS IEEE COMPUTER SECURITY FOUNDATIONS WORKSHOP VII June 14-16, 1994 Franconia, New Hampshire Sponsored by the IEEE Computer Society The purpose of this workshop is to bring together researchers in computer science to examine foundational issues in computer security. We are interested both in papers that describe new results in the theories of computer security and in papers, panels, and working group exercises that explore open questions and raise fundamental concerns about current theories of security. Possible topics include, but are not limited to: access control distributed systems security authentication formal methods for security covert channels information flow data and system integrity secure protocols database security security models We are also interested in examining the interactions and trade-offs between computer security requirements and other system requirements such as availability, dependability, and real-time, and in exploring foundational security issues in emerging areas such as ubiquitous computing, multimedia, and computer supported cooperative work. The proceedings are published by the IEEE Computer Society and will be available at the workshop. Selected papers will be invited for publication in the Journal of Computer Security. Instructions for Participants: Workshop attendance will be by invitation only and limited to thirty-five participants. Prospective participants should send five copies of a paper (limit 7500 words), proposal for panel discussion or working group exercise to Li Gong, Program Chair, at the address below. Please provide E-mail addresses and telephone numbers (voice and fax) for all authors and clearly identify the contact author. IMPORTANT DATES: Author's submission: February 10, 1994 Notification of acceptance: March 11, 1994 Camera-ready final papers: April 11, 1994 Program Committee Simon Foley, Univ. Col., Cork, Ireland Virgil Gligor, U of Maryland, USA Simon Lam, U of Texas, Austin, USA Stewart Lee, U of Toronto, Canada John McLean, Naval Research Lab, USA Catherine Meadows, Naval Research Lab, USA Michael Merritt, AT&T Bell Labs, USA Jose Meseguer, SRI International, USA Jonathan Millen, MITRE, USA Chris Mitchell, U of London, RHNBC, UK Robert Morris, DoD, USA Ravi Sandhu, George Mason U, USA For further information contact: General Chair Program Chair Publications Chair Ravi S. Sandhu Li Gong Joshua Guttman ISSE Department SRI International The MITRE Corporation George Mason University Computer Science Lab Burlington Road Fairfax, VA 22030-4444 333 Ravenswood Avenue Bedford, MA 01730 +1 703-993-1659 Menlo Park, CA 94025 +1 617-271-2654 email@example.com +1 415-859-3232 firstname.lastname@example.org email@example.com
Please report problems with the web pages to the maintainer