Subject: RISKS DIGEST 11.33 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Friday 22 March 1991 Volume 11 : Issue 33 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: A billion here, a billion there... [$B column omitted] (Saul Tannenbaum) Sprint says NO to increased account security (Lauren Weinstein) Re: "What the laws enforce" (Paul Smee, Mike Godwin, Neil Rickert) Old Soviet spacecraft loss attributed to software (Henry Spencer) Fake Cashpoint duped Customers (Paul Johnson) Solutions Incorporated FaxGate software (Peter Furmonavicius via jwn2) Long-dormant bugs (Martyn Thomas) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line. Others ignored! REQUESTS to RISKS-Request@CSL.SRI.COM. For vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 11, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ---------------------------------------------------------------------- Date: Fri, 22 Mar 91 00:05 EDT From: Saul Tannenbaum Subject: A billion here, a billion there... [$B column omitted] The following Editors' Note appeared on Page 3 of the New York Times, Thursday, March 21: Because of a computer typesetting misadjustment, the Money Market Funds table appearing in Business Day each Thursday since February 14 has carried incorrect figures for the total assets of some funds and for their yields. The asset figures have omitted the billions column for amounts of $1 billion of more; a fund, for example with assets of $12.345 billion would have been shown with $345 million. In addition, since Feb. 21, the column labeled 7-day yield has actually shown the 7-day effective yield, a higher figure. Readers reported the erros soon after they first occurred, but through an editing laps, the table continued to appear while repairs where awaited. A corrected format begins today on page d9. It includes both the 7-day yield and the effective 7-day yield, but omits the assets. At least Fortran would have printed *'s.... Saul Tannenbaum, Manager, Scientific Computing, USDA Human Nutrition Research Center on Aging at Tufts Univ., STANNENB@HNRC.TUFTS.EDU STANNENB@TUFTS.BITNET ------------------------------ Date: Thu, 21 Mar 91 13:15:41 PST From: lauren@vortex.com (Lauren Weinstein) Subject: Sprint says NO to increased account security There have been reports in various forums recently of various concerns regarding U.S. Sprint's new policy of allowing access to almost all (1+ long distance dialing) customer account balances based only on 10 digit phone numbers (previously, account numbers had been needed to obtain such information). Account balances for all phone numbers with 1+ service selected to Sprint, except for those customers connected to Sprint by high volume leased line facilities (e.g. T1) are apparently accessible via the system. Concerns have been expressed about misuse of this data by outside organizations, competitors, or even other carriers looking to target the "big" customers. Certainly most people have been assuming that the amount of their long distance bills was not "public" information. I have been following this rather closely, and over the last several weeks have had a complaint working its way up the chain in Sprint. As a user of Sprint (as well as other carriers) I personally feel that account balance information should be private between the carrier and the customer. If reasonable protections cannot be provided for that information in automated systems, customers should at least have some method for "opting out" of the automated account system itself. Sprint has been very good about staying in touch about this issue. The "end of the line", so to speak, has been Ms. Rochelle Richter at the Sprint Executive Offices. She's an "Executive Analyst" in the offices of the President of Sprint (Mr. LeMay) and the Sprint CEO (Mr. Esrey). She tells me that they have been informed of the concerns I expressed over this system. The number for the Sprint Executive Offices where Ms. Richter (or the other persons mentioned above) can be reached is (800) 347-8988. Ms. Richter also discussed the issue with the gentleman in charge of the development and management of the automated system itself, Mr. Rick Shield at (816) 276-6242. I'm sorry to report that Sprint at this time does not view the privacy issues involved as a problem. They do plan to add a requirement that users enter their zipcode as well as their 10 digit number, apparently viewing the zipcode as a security measure. I assume that most of us agree that the addition of the zipcode does not represent any real security improvement, since it is trivially available to anyone who wants it in most cases. The Sprint view is that they have had very few complaints from customers about the system (she claims only two), that they don't see what the concern is about account balance information, and that they haven't heard of any similar systems causing problems for the customers or the companies providing information. She invites those with concerns about this issue to contact her directly at the toll-free 800 number above. She made it clear that unless they get significant numbers of complaints from customers, there is currently no intention for any change other than the "zipcode" requirement mentioned above. She also invites comments to herself or Rick Shield from persons who have documented evidence of the privacy/security problems which could result from such systems. If any of you are Sprint customers and *are* concerned (either as an individual or as an organization) about the privacy issues involved with this system, or even if you are a non-customer and can offer Sprint some insight into the issues involved, I would suggest that each of you take Ms. Richter up on her offer and express your views, so that Sprint will have more opinions on which to base any future decisions about their system. --Lauren-- ------------------------------ Date: Thu, 21 Mar 91 18:10:42 GMT From: P.E.Smee@gdr.bath.ac.uk Reply-To: P.Smee@bristol.ac.uk (Paul Smee) Subject: "What the laws enforce" (Jim Thomas, alias TK0JUT1, RISKS-11.30) >... One can oppose trespass while simultaneously opposing Draconian attempts > to stomp on those who tread >tackily in our once-pastoral fields. There is a very tricky balancing act involved, though, and I don't believe that the 'physical trespass' analogy holds very well. Seen from the point of view of the person whose system is being hacked, the amount of time and manpower required to 'resecure' a system after it's been hacked is approximately the same regardless of whether the 'hacker' committed destructive acts, or simply logged in and straight back out. It takes a long time to make sure that data integrity has been preserved, and that no trapdoors or trojan horses have been left behind. Thus, from the point of view of the victim, even 'harmless hacking' results in a great amount of damage. As for 'forbidden knowledge', what does that include? I'd regard it as VERY serious if someone has, for example, a plaintext list of usernames and passwords for our system, even if they haven't used it. You never know when they will. They've effectively got a gun at your head. I confess to having difficulties with all this, for which I don't have an easy answer, because I do hold the (officially forbidden, here) belief that 'hacking' (in the most general sense) can provide a very valuable educational experience for the hacker -- and we are supposed to be an educational institution. At the same time, though, I deeply resent the time I lose whenever I've got to help clean up after one -- even if, after a week of investigation, we find that nothing harmful has been done. I would certainly like to find a solution for all this. ------------------------------ Date: Thu, 21 Mar 91 16:24:05 EST From: mnemonic@eff.org (Mike Godwin) Subject: Re: "What the laws enforce" (Johnson, RISKS-11.32 >...He could claim that he wasn't planting a bomb, but how can you be sure? This is an insupportable analogy. Few breakins have as much evidence of malicious intent as Bob's example here. There is no way to "be sure," as Bob correctly points out. But it takes minimal understanding of the "cracker" subculture to determine that very few have malicious intent. It is a premise of our legal system that criminal prosecutions be based on a culpable mental state on the part of the person who is convicted. If kids or anyone else damages a system accidentally and/or non- maliciously, the proper legal remedy is civil litigation. (An even better remedy, of course, is to be nonnegligent as far as maintaining attractive nuisances go. In the case of the Atlanta hackers, for example, the touted E911 document was copied from a computer that was accessed through an account with a null password. The kids got 14 to 21 months.) > As a prudent office-building-owner, wouldn't you call in >the police bomb squad, and deny access to the tenants until the whole >building had been inspected and been declared safe? If your office was entered after you took too few measures in maintaining building security, it's a little late to show prudence when the mad bomber has already shown up, I'd think. >When we have a breakin (and we have had a couple), how much time is it >going to cost ... It costs much less to practice good security in the first place. > Just counting the direct cost of manpower, the sum involved is many >thousands of dollars. It is perfectly appropriate to sue to recover this amount. This is a civil proceeding, not a criminal one, however. Or did you think that the purpose of the criminal-justice system was to save you litigation costs? > I am for making the penalties for computer trespass extremely painful ... Nothing disturbs me more than people who blithely call for more and harsher criminal laws. It is apparent when one studies the criminal justice system in this country that we prefer to criminalize some activities rather than make responsible policy decisions. More than a million people are in jail (the highest rate of imprisonment in the world, when I last checked), yet we don't want to build new jails for them. Oh, yes--*much* wiser to send some 19-year-old kid to prison on the basis of a bankrupt theory of deterrence than to make sure he doesn't get in in the first place. And let's remove the requirement of criminal intent for conviction, shall we? Let's expand the criminal law to include anything and everything that is inconvenient, or that we don't like. >Most administrators who've had to clean up and audit a system of this size >probably think that a felony rap is too light a sentence. At times like that, >we tend think in terms of boiling in oil, being drawn and quartered, or maybe >burying the intruder up his neck in an anthill. It is precisely this kind of mentality that was so common, once upon a time, in concentration-camp guards. It is amazing to me that one can admit this sentiment in public without embarrassment. Mike Godwin, Electronic Frontier Foundation (617) 864-0665 mnemonic@eff.org ------------------------------ Date: Thu, 21 Mar 1991 22:42:45 GMT From: rickert@cs.niu.edu (Neil Rickert) Subject: Re: "What the laws enforce" (Johnson, RISKS-11.32) >Begging your pardon, but there is a great difference between trespassing >on my property and breaking into my computer... Begging your pardon, but there is a great difference between logging into a computer using an account with no special privileges, and being found in a high-rise with wire and detonators. Let me describe a couple of experience from my past. They occurred in the 1970s. At that time I had an account on our campus (the campus I was at then) mainframe. The account had no special privileges. I was a faculty member, and not part of the computing services staff. Experience 1: While using a feature of the editor, I noticed a suspicious discrepancy. Exploring this, it looked like a security problem. To test this, I attempted to submit a job under the identification of one of the Systems Programmers. Actually I submitted an essentially null job (IEFBR14 for those who recognize this name). My submission was successful. I immediately reported it to the System's Programmer, who fetched the output of his (my) job, and immediately set to work to remove this misfeature from the editor. Experience 2: While using a software debugging system, I noticed a suspicious feature. Exploring it, I discovered I could change the contents of a register used by the system when in a highly privileged state (Supervisor State). The bit I actually changed was an insignificant bit with no purpose, but I could equally have changed any register and gained control of the system. I again reported this to the Systems programmer, who immediately set to work documenting it so as to report it to the vendor. What is the relevance of these experiences? Simply this. If the same circumstances occurred again, I would take the same action. I would consider it unethical NOT to act as I did. Yet, some people in these discussions of intrusion, etc, would define my actions as computer crime, punishable by lengthy prison terms. Sure, in the circumstances, they would probably exonerate me based on my motives. But still their definition of computer crime is wrong. It is a head in the sand approach which pretends that if we just punish the 'criminals' the problems will go away. They won't. Neil W. Rickert, Computer Science, Northern Illinois Univ., DeKalb, IL 60115 +1-815-753-6940 ------------------------------ Date: Thu, 21 Mar 91 23:10:09 EST From: henry@zoo.toronto.edu Subject: Old Soviet spacecraft loss attributed to software An interesting report from Bart Hendrickx of Belgium in the April issue of Spaceflight, based on a newly-published Soviet book about unmanned Mars exploration (Yuriy Markov, "Kurs Na Mars", Mashinostroyeniye, Moscow 1989). In part, he writes: As is known, one of the three Soviet [Mars] probes readied for the 1971 launch window got stranded in Earth parking orbit and was renamed Cosmos-419. It now turns out this was intended to become Mars' first artificial satellite. Unlike its companions Mars-2 and 3, which were combined orbiter/landers, Cosmos-419 merely consisted of an orbiter. The resulting weight reduction would have allowed it to fly a faster trajectory and reach Mars orbit ahead of America's Mariner-9, clinching another major first for the Soviet space programme. The probe failed to leave Earth orbit due to a "most gross and unforgivable mistake" made by programmers during the input of code-numbers into its on-board computer. (No further details, alas.) Henry Spencer at U of Toronto Zoology ------------------------------ Date: 22 Mar 1991 11:42:58-GMT Subject: Fake Cashpoint duped Customers From: paj A report on the back page of the 21 March Computer Weekly describes a home-made box with a keyboard which was placed on a cashpoint machine in Hove, England. It seems that four customers put their cards in the box and typed in their PINs. The machine then recorded the PIN and kept the cards. The intention appears to have been to remove the box and use the cards and PINs to extract money from real machines. A fifth customer became suspicious and called the police. Jean Paul English was arrested and plans for the box were found in his home. He told police that he made the machine out of curiosity. When tried at Lewes Crown Court he denied two charges of forgery but admitted to one specimen charge of stealing a cash card. The fake ATM did not fall within the definition of an `instrument' in the 1981 forgery act. This relates somewhat to the `droid' discussion last week in RISKS. Its not just in shops and customer service departments that the droid mentality shows up. It does not seem to have occured to the first four customers that the box might not be official or that it could be removed (and hence could not contain cash). I suppose they just expected to get their cards back from it. Paul Johnson, GEC-Marconi Research +44 245 73331 paj@gec-mrc.co.uk UUCP:!mcvax!ukc!gec-mrc!paj ------------------------------ Date: Fri, 22 Mar 91 08:17:23 -0800 From: jwn2@qualcom.qualcomm.com Subject: Solutions Incorporated FaxGate software >Sender: "QuickMail (CE Software) Users" >From: Peter Furmonavicius >Subject: Solutions Incorporated FaxGate software > >Recently, I mentioned our use of facsimile networking software called >FaxGate, from a company called Solutions Incorporated. I would like to >warn anyone considering the use of this package about a potentially >serious security problem. FaxGate prepends the lines from the "Address" >portion of the Special Address dialog box to every fax that it transmits. >However, this is where the user must specify the phone number for the >outgoing fax that they wish to be sent. So what's wrong with that? >Well in lots of sites I'm sure, users that wish to send non-local >faxes must append their phone credit card numbers or local toll >authorization numbers to the outgoing 'long-distance' phone number. >And this would consequently get printed at the remote site where the >fax is sent! We have found this to be unacceptable and are therefore >discontinuing our use of this software until the problem is corrected. >If anyone has any further comments or corrections (or circumventions), >let's hear them. Thanks. > Peter ------------------------------ Date: Fri, 22 Mar 91 15:27:18 GMT From: Martyn Thomas Subject: Long-dormant bugs All the theoretical work on software reliability demonstrates that there should be very many paths which are rarely executed, in most software. That is why we are so concerned about the difficulty of establishing the probability of failure of software, when the target probabilities are very low. We should therefore *expect* reports of bugs showing up after a very long time. It is evidence that the problems we identify are real. There isn't much software out there which has been running for 20+ years - but the amount is growing very quickly. We can expect an increasing number of anecdotes about long-dormant bugs, until they become commonplace and not worth remarking. Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK. Tel: +44-225-444700. Email: mct@praxis.co.uk ------------------------------ End of RISKS-FORUM Digest 11.33 ************************