risks@CSL.SRI.COM (RISKS Forum) (03/23/91)
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.COM<CR>login anonymous<CR>AnyNonNullPW<CR>
CD RISKS:<CR>GET RISKS-i.j<CR>" (where i=1 to 11, j always TWO digits). Vol i
summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye<CR>" 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 <SAUL_SY@hnrc.tufts.edu>
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 <rickert@cs.niu.edu>
------------------------------
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 <paj@gec-mrc.co.uk>
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:<world>!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" <QM-L@YALEVM.YCC.Yale.Edu>
>From: Peter Furmonavicius <PETER@YALEVM.YCC.Yale.Edu>
>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 <mct@praxis.co.uk>
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
************************