risks@CSL.SRI.COM (RISKS Forum) (02/20/91)
RISKS-LIST: RISKS-FORUM Digest Tuesday 19 February 1991 Volume 11 : Issue 13
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Contents:
MAD HACKER appeal fails (Darren Dalcher)
Paid to know everything about everybody? (Murder, She Wrote) (Kent M Pitman)
Retail Sales Oversight -- No backup (Dave Rotheroe)
Re: Tube Tragedy (Pete Mellor)
Re: Serious bug in SVR3.2 gives root access easily (Richard H. Miller,
Sean Eric Fagan, Steve Nuchia, anonymous, Daniel A. Graifer)
Re: Errors on Vietnam Veterans Memorial (Al Arsenault, Mary Smolka)
Driving records (Jim Griffith)
Re: Quick n' easy access to Fidelity account info (Steve Golson)
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.
FTP VOL i ISSUE j: ftp CRVAX.sri.com<CR>login anonymous<CR>AnyNonNullPW<CR>
CD RISKS:<CR>GET RISKS-i.j<CR> (where i=1 to 11, j is always TWO digits. Vol i
summaries in j=00; "dir risks-*.*<CR>" 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: Tue, 19 Feb 1991 14:15:18 PST
From: "Peter G. Neumann" <neumann@csl.sri.com>
Subject: MAD HACKER appeal fails [From Darren Dalcher]
Nicholas Whiteley, 21, of Ascot Gardents, Enfield, UK, was convicted earlier
[see RISKS-10.03,09,10,27] on four counts of damaging property, and sentenced
to 12 months in jail, 8 of them suspended. A week later he was out on bail,
pending appeal. The appeal process was completed on 22 January, and was
dismissed. He was reportedly the "first computer hacker in Britain to be
jailed". He had "deleted and added files, put on messages and changed
passwords of existing users enabling himself to use the system." [Thanks to
Darren Dalcher at King's College, London, for a clipping received this morning
from the 6 Feb 91 Enfield Independent, apparently mailed on 6 Feb, although
unpostmarked, with a stamp that was uncancelled.]
------------------------------
Date: Mon, 18 Feb 1991 16:24-0500
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Paid to know everything about everybody?
In last night's ``Murder, She Wrote'' one of the key characters was a pesky
little IRS agent that went around always getting his way by making veiled
threats which bordered on extortion. Irksome, but nothing really new from a
plot perspective.
What disturbed me more was that as the plot progressed, Jessica knew she was
out of clues and needed help. So she went to what she called ``somebody who is
paid to know everything about everybody'' (the IRS guy) ... and with only a
little bit of coaxing, managed to the agent that it was in the tradition of
trapping Al Capone on his taxes for him to reveal to her information on the
suspect. And she probably thought that neither of them had done anything
wrong.
I'm going to write to CBS about this one. Maybe I won't be the only one.
It seems to me like a little well-placed pressure on TV writers and producers
might not only get them back in line, but could even lead to some interesting
plot lines exploring the potential bad side-effects of ``well-intentioned''
invasions of privacy, such as this one.
------------------------------
Date: 18 Feb 91 21:02:00 GMT
From: rotheroe@convex.com (Dave Rotheroe)
Subject: Retail Sales Oversight -- No backup
I went to my local 'Best Buy' - a new home appliance, electronic, and computer
discount store in my area, to buy a few things last Saturday. Things went
smoothly until I wanted to pay. Turns out their main store computer was dead -
down for the count. In their incredible wisdom, there was no backup system, as
the system was supposed to "come right back within a few minutes of going
down". There was one (1) printout of prices in the entire store, which was
being kept at the service desk so they could continue to work. The registers
had no price help, which ment there were people running all over the store
getting prices. In addition, the automatically printed credit card receipts
weren't, forcing the clerks to manually imprint and fill out the forms, and
make phone calls for authorization - tasks they admitted they weren't properly
trained for, and had never done before. Probably the only reason the store
managed to deal with it at all was that business was light. I found it both
amusing and scary that the chain apparently has no backup system (like a
printout for each register), and does not train their employees in exactly what
to do and expect in the event of a long-term failure.
Dave Rotheroe, CONVEX Computer Corporation, Richardson (Dallas), TX 75083-3851
(214) 497-4512 rotheroe@convex.COM
------------------------------
Date: Wed, 13 Feb 91 21:24:38 PST
From: Pete Mellor <pm@cs.city.ac.uk>
Subject: Re: Tube Tragedy (RISKS-11.03)
Following my original mailing, Bill Carney <8332P@EARN.NAVPGS> wrote to say:
> I had always thought that the were pressure sensitive switches located on
> each of the doors. I am basing this assumption on the fact that on the
> New York City Transit system, a child can hold the subway doors open.
This gave me pause for thought. Eventually I replied more-or-less as follows:
I hope no child brought up in New york ever tries it on the London
Underground! The doors *can* be held open, but only by brute force. I would
say it would take a fairly strong man to prevent them closing. This is based
on observation of strong men attempting to get on as the doors were closing,
and on feeling the force personally when doing the same myself. The safety
feature is that the train will *not* move while any door (other than the
guard's) is open.
I have watched the guard carefully (on the few remaining two-man trains). He
checks the platform, and pushes a button to close the doors. If these are
obstructed, a light illuminates on the control panel. He opens the doors, to
give the passengers a chance to get clear, checks, and tries again. When the
doors close successfully and the warning light goes out, he pushes another
button, and the train starts to move. (In the case of a driver-only train, I
assume that the system is similar, except that the driver operates it, and
checks using a TV monitor at the end of the platform.)
The limit for a door to trigger the warning seems to be a couple of inches,
so that if a leg or arm is trapped, there should be no problem. If a
shoulder-bag is trapped outside, and the door closes on the strap, however
(as once happened to me), the train will move.
The interesting thing on two-man trains is that the guard's door must remain
open as the train starts to move. Often there are several carriages with a
guard's control panel, though obviously, only one is operational on the train
at any given time. There must therefore be a way of selectively disconnecting
a door from the warning system, and I *think* that this is what the
"butterfly clasp" does. I asked the guard the other day where the clasp was.
(I couldn't see anything resembling a butterfly anywhere.) He knew what it
was, all right, but he wasn't going to tell me. "There've been too many
accidents with those things!", he said. He told me to write to LU if I wanted
more information.
In the meantime, is there anyone out there who is well-informed about safety
systems on the London Underground, who can explain a) how a *passenger* could
operate such a device, b) why no special key is required to operate it, and
c) why the warning system cannot be designed so that *only* the door next to
the active guard's control panel can remain open *for whatever reason* as the
train begins to move?
I have also heard a story that a woman was strangled a short time ago when
the doors closed around her neck. Can anyone confirm this?
Peter Mellor, Centre for Software Reliability, City University, Northampton
Sq.,London EC1V 0HB +44(0)71-253-4399 Ext. 4162/3/1
------------------------------
Date: 15 Feb 91 17:27:11 GMT
From: rick@pavlov.ssctr.bcm.tmc.edu (Richard H. Miller)
Subject: serious bug in SVR3.2 gives root access easily (RISKS-11.10)
> Date: Wed, 13 Feb 1991 12:19:18 CST
> From: pwolfe@kailand.kai.com (Patrick Wolfe)
> Subject: serious bug in SVR3.2 gives root access easily
>
> In my opinion, the rest of us are probably screwed. I seriously doubt any of
> these OS vendors will stop working on SVR4 to fix this bug in SVR3.2, except
> possibly for customers who pay for software maintenance. Many vendors are just
> about ready to ship their SVR4 release. I suspect most will tell those of us
> who don't pay for maintenance that we must upgrade to fix the bug.
[As an aside, I have a difficult time understanding why a person who does not
pay for software maintenance expects to have bugs fixed. If you choose to
not pay for the service, then don't expect the vendor to fix it for free.]
Now, as far as the risk is concerned, is this a good stand? Should security
holes be in a special category as far as fixes from the vendor are concerned?
The risk here is obvious since I, as a user of a BBS with a system with a
security flaw which is not fixed due to the unwillingness of the operator to
pay for software maintenance, have some exposure due to the hole. Should a
system operator disclose the type of hardware and software he is running as
well as the status of his maintenance so his users can determine their
exposure?
Should vendors provide security fixes free to authorized purchasers since the
type of risk is different than other bug fixes? What is the liability of a
system operator who chooses not to disclose that S/W maintenance is not done
and thus 'fixed' security bugs for a platform are not present? Can any
liability be attached to the vendor because of the operator's decision to not
pay for security fixes?
Richard H. Miller, Asst. Dir. for Technical Support, Baylor College of
Medicine, One Baylor Plaza, 302H, Houston, Texas 77030 (713)798-3532
------------------------------
Date: Sun, 17 Feb 91 00:33:35 -0800
From: sef@kithrup.com
Subject: Re: Serious bug in SVR3.2 gives root access easily
In RISKS DIGEST 11.10 pwolfe@kailand.kai.com (Patrick Wolfe) writes:
>It just goes to show that it was a good idea when I set my bbs up to run in a
>"chroot" filesystem, where even if a user could break out of the bbs program
>into a shell, there is no compiler (in fact, there are hardly any useful
>commands at all) to mess around with.
This seems like a good place and time to point out that that isn't really
'secure' from the bug in question. The major security aspect in the above
described system comes from the fact that there is no compiler or (easy?)
access to the shell; the chroot() only makes things slightly more
interesting and challenging. (I leave it to the reader to figure out how to
change u.u_rdir, since *the entire u block is writable*.)
Systems known not to be affected by the bug include Dell UNIX (both 3.2 and
r4), in addition to the ones listed by Patrick.
For more details on the entire affair, read comp.unix.sysv386.
Sean Eric Fagan sef@kithrup.COM
------------------------------
Date: Fri, 15 Feb 91 23:16:44 GMT
From: steve@nuchat.sccsi.com (Steve Nuchia)
Subject: Re: serious bug in SVR3.2 gives root access easily
On the subject of the 386 Unix security bug, which we recall makes
the u area (per-process system data structure) writable by user processes,
Patrick Wolfe (pwolfe@kailand.kai.com) said:
>It just goes to show that it was a good idea when I set my bbs up to run in a
>"chroot" filesystem, where even if a user could break out of the bbs program
>into a shell, there is no compiler (in fact, there are hardly any useful
>commands at all) to mess around with.
The number of ways one can go about getting bits into a file is truly amazing.
Even cat, or any of its moral equivalents, might do it if the bytes can get
past the serial driver. In fact, finding a way to turn on an execute
permission bit is the hardest part of getting out of many chroot boxes.
The point I wanted to make here, lest anyone think that chroot is a shield
against this bug, is that the process' current root is stored (just like its
current directory) in the u area too.
This coupling of failure modes may strike one as undesirable initially,
But security is not the same as functional failure protection. Rather than
making a single point to failure by grouping individually tollerable
failure points, putting all the security eggs in one u-area basket
makes a *single* single point to failure out of a whole clutch of them.
If the failure of any *one* component breaks the system, you don't
gain anything by running them on seperate power supplies.
Steve Nuchia South Coast Computing Services (713) 964-2462
------------------------------
Date: 14 Feb 91
From: [anonymous]
Subject: 386 Unix Security bug fixes from vendors
Without addressing any of the detailed (and significant) issues surrounding the
security bug in question at this time, the following is worth noting in any
case:
A recent poster to this list implied that they felt there would be no bug fixes
forthcoming for non-most-recent versions of 386 Unix from the various vendors.
This is not the case. Two of the main vendors involved, ISC (386ix) and Everex
(Esix) have announced no-cost bug fixes or upgrades to be available to deal
with the problem. ISC said that they expected their fix to become available
around 22 Feb 91. Other involved 386 Unix vendors can hopefully be depended upon
to follow suit.
------------------------------
Date: Mon, 18 Feb 91 11:33:51 est
From: Daniel A. Graifer <dag@fciva.UUCP>
Subject: Discussion of major security hole AT&T SYSV/386 in comp.unix.sysv386
Over the last few days, there has been a substancial discussion occuring in
comp.sysv.386 regarding a major security hole in a number of the commercial
Unix System V/386 version 3 releases.
On Thu Feb 14 08:11:04 EST 1991 lumpi@dobag.in-berlin.de posted a complaint
that he had found a technique by which any process could give itself
superuser priviliges under ISC Unix. He claimed that ISC had been ignoring
his communications for half a year. In "dispair" he posted a 50 line c program
which when executied made the /etc/passwd and /etc/shadow files world
writable. He also posted an uuencoded binary.
Responses poured in from owners of other systems. SCO Unix appeared immune,
as were newer Dell releases. ESIX was vulnerable, as are some of the
hardware vendor's proprietary releases (such as Prime's EXL300 series).
The bug arises from a combination of two factors in Intel 80386 based
machines. Since many of these machines run without a numeric coprocessor,
allowance must be made to trap floating point instructions and invoke an
emulator. Since the performance degradation of switching to kernal mode
for each instruction would be large, the emulator runs in user mode. However,
it stores some items in the same memory page as the process' userid, and
must have write access to this page (SysV/386 memory protection is on a
per page basis, the second contributing factor). A process which may call
the emulator can dummy-up a pointer into this page and set it's uid to zero
(superuser).
It was claimed that AT&T has known about the trapdoor for some time, had
informed the source licensees long ago, and had distributed a fix with the
V.3.2.1 tapes. An employee from SCO claimed they had fixed the problem
independently prior to the AT&T release. After someone on the net confirmed
that older versions of Dell unix were affected, an employee of Dell posted a
telephone number where owners of outdated releases could obtain fixes. An
ISC employee posted that a fix would be available to A SUBSET (emphasis added
owners after February 22 by calling ISC's support number.
The discussion contained two threads especially interesting to risks readers:
Was it proper for the "discoverer" of the hole to post it so widely and
in such a dangerous form? In his defence, he has not only raised the
community's awareness of a serious problem, he has also forced ISC to
respond to the issue. I did not see any postings in the group saying
"Oh yeah, we systems administrators new about that."
If it can be established that the vendors were well aware of the problem
prior to the release of the software, were they legally negligent in
distributing those release, and liable for any losses there customers
sustained due this bug?
Because these systems are so 'cheap' (you can build a nice workstation for
significantly less than $1000), they are being installed at an enourmous
rate throughout the economy. Even when the vendors get off the dime and
distribute fix already supplied by AT&T, how many vulnerable systems will
be left in operation?
This reminds me of the "sendmail bug" exploited by the Internet-Worm, or the
less well know System V "Inode Bug". As a purchaser of operating systems, I
have no expectation that they will be bug free, but I am incensed when vendors
fail to distribute available fixes to well known major problems. Or at least
make sysadmins aware in the release notes of their existence!
Daniel A. Graifer, Coastal Capital Funding Corp., 7900 Westpark Dr. Suite
A-130, McLean, VA 22102 (703)821-3244 fciva.FRANKCAP.COM!dag@uunet.uu.net
------------------------------
Date: Fri, 15 Feb 91 16:22:03 MST
From: Al Arsenault <arsenaul@usafa.af.mil>
Subject: Re: Errors on Vietnam Veterans Memorial
The following excerpts are taken from an Associated Press story in the Friday,
15 February Colorado Springs Gazette-Telegraph.
"Up to 38 live Viet vets may be listed as dead"
The man responsible for deciding which names were carved on the Vietnam
Veterans Memorial says there may be as many as 38 Army veterans mistakenly
listed as dead. Robert W. Doubek said he wasn't positive at the time that the
men had been killed because their records were incomplete. But he included
them anyway because he didn't know that it would be possible to add names once
the memorial was built. "I had the idea these people might be lost to history
if we didn't include them", Doubek said in an interview.
The Associated Press disclosed earlier this week that 14 Army veterans listed
as dead on the wall are alive. After reading that story, Doubek volunteered
that there may be another 24 errors. Apparently it is `impossible' to REMOVE
names.
------------------------------
Date: Fri, 15 Feb 91 08:07 EST
From: Mary Smolka <GA82293@INDYLLY.BITNET>
Subject: vietnam vet's name on memorial
Regarding the comment about a name on the Vietman Memorial possibly
being MIA:
I was a tour guide in Washington DC for two summers while I was in
college, and learned all sorts of trivia about the various memorials.
It's true that there are different symbols on the memorial to denote
KIA or MIA; a diamond next to a name indicated KIA while a cross, or a
plus sign, indicates MIA. If a soldier listed MIA is found to have been
killed, a diamond can easily be carved over the cross. If a soldier
formerly MIA is found to be alive, the plan is to engrave a circle
around the cross to denote "the circle of life." At the time I was
guiding ('87,'88) there were no cases of this occurring, and I haven't
heard of any since.
With over 58,000 names on the memorial, there WERE mistakes made.
Between my first and second summers, several names were added that had
been found to be left off the memorial when it was first commissioned.
And from what I understand, there are some other names that SHOULD be
on, but there isn't any more room. Hope this helps.
Mary Smolka.
------------------------------
Date: Fri, 15 Feb 91 10:38:36 PST
From: griffith@dweeb.fx.com (Jim Griffith)
Subject: Driving records (was Risks of having a sister)
sullivan@poincare.geom.umn.edu discussed tying tickets to drivers' licenses and
vehicles. My understanding of California law is that they distinguish between
parking tickets and moving violations. A moving violation is tied to a
driver's license, while a parking ticket is tied to a vehicle. So moving
violations can affect license renewal, while parking tickets can affect vehicle
re-registration. Strikes me as an intelligent approach, although I'm curious
as to how the DMV deals with changes of ownership of cars with unresolved
violations.
Jim
------------------------------
Date: Thu, 14 Feb 91 19:14:45 EST
From: sgolson@east.sun.com (Steve Golson)
Subject: Re: Quick n' easy access to Fidelity account info
In RISKS 11.03 Carol Springs reports on a Fidelity Investments account
inquiry service that can be accessed with only the account holder's SSN.
I called Fidelity to ask them about it. They said the service had been
discontinued due to customer complaints, and that in any case it did
*not* allow complete access to holdings info. What you got was the
closing prices of the stocks etc. being held in the account, but *not*
the total value. Still this is bothersome enough.
Fidelity does has a service called FAST (Fidelity Automated Service
Telephone) which requires an account number and the last four digits
of your SSN. Once you are into FAST you can get balance inquiries,
make account transfers, and even open new Fidelity accounts...
Steve Golson -- Trilobyte Systems -- Carlisle MA -- sgolson@east.sun.com
(consultant for, but not employed by, Sun Microsystems)
"As the people here grow colder, I turn to my computer..." -- Kate Bush
------------------------------
End of RISKS-FORUM Digest 11.13
************************