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: firstname.lastname@example.org (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 email@example.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 (firstname.lastname@example.org) 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 email@example.com 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.COMfirstname.lastname@example.org
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.
email@example.com 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 — firstname.lastname@example.org (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