Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
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.]
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.
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
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: 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
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
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
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.
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
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.
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.
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
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
Please report problems with the web pages to the maintainer