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…
GREENBELT, Md. (AP) Police used a 3-foot, 480-pound robot to disarm a man who allegedly shotgunned his girlfriend to death and barricaded himself inside their apartment. Prince George's County authorities sent the remote-controlled robot into the apartment Thursday after police were unable in a five-hour standoff to persuade Craig Smith, 22, to surrender. Smith fatally shot his live-in girlfriend Cynthia Wilkinson, 24, and sexually assaulted an unidentified woman who was a friend of Wilkinson's, police said. The woman jumped out a window of the second-story apartment and ran to a neighbor's home to call police. After negotiations with Wilkinson broke off, police borrowed a robot that the fire department uses to dismantle suspected explosive devices, said Sgt. Alan Day, a police department spokesman. Transmitting the scene by a video camera, the robot at the direction of a fire department technician opened a closet door. Wilkinson could be seen hiding under a pile of clothes and the robot's mechanical claws reached out and pulled them away. When Smith grabbed the clothes back from the robot and began to cover himself up again, the robot fired a high-pressure water gun to knock the shotgun out of Smith's hands and disorient him, said a police spokesman, Cpl. Keith Evans. Police rushed in and arrested Smith. The Prince George's County Fire Department bought the robot known as Remote Mobile Investigator-9 RMI-9 for short seven years ago for $45,000. Capt. Victor Stagnaro, a fire department spokesman, said it was the first time the local police had used RMI-9 to catch a suspect. Smith was charged with first-degree murder and sexual assault. Evans said that Wilkinson and Smith argued Wednesday night after she apparently told him she wanted to end their relationship. The dispute resumed Thursday morning, and Smith shot Wilkinson while they argued, Evans said. [Sept. 3, 1993 The Associated Press]
The following two articles were posted on a local BBS of a company I work for:
------------------------------
. 93/09/02 12:06 Entrance of children to our building.
Following an incident which occurred last Tuesday evening (an employee's
child switched off the UPS main electricity switch of one of the floors),
we recommend that children not be left unattended in any part of the
building.
The best advice is to stay with the children in the lobby where
'dangerous attractions' are minimal.
We have taken precautions to avoid recurrence of similar incidents
by installing special locks on the electricity cabinets.
------------------------------
. 93/09/02 15:00 To those who suffered from the UPS fall
I apologize for my son, he's 20 month old, yet he needed less than
20 second on the floor to break the UPS down...
------------------------------
I checked the said UPS switch — it's an emergency-shutdown type: big, red, and
located near the bottom of the control panel. In short, conspicuous enough to
be located quickly in an emergency — or at any time by a two-year-old kid...
Amos Shapir, The Hebrew Univ. of Jerusalem, Dept. of Comp. Science.
Givat-Ram, Jerusalem 91904, Israel, Tel: +972 2 585706 amos@cs.huji.ac.il
There is an interesting story in THE SCIENCES, July/August 1993: "The Discovery of Debugging," by Brian Hayes, pps. 10 — 13. It describes experiences programming EDSAC, which the story says was the the first true stored program computer, at Cambridge in 1949. EDSAC's first three programs — which calculated lists of squares and prime numbers — worked correctly the first time they were run! This was no mean accomplishment, in view of EDSAC's instruction set and the very rudimentary programming tools available. After that, it got difficult. While cleaning his office in 1979, EDSAC designer Maurice Wilkes came upon a thirty year old punched tape which contained an early version of a program for calculating a table of values for Airy's integral. Wilkes gave a copy to Martin Campbell-Kelly, who studied it using an EDSAC simulator. The 126 line program contained 20 errors! Most were trivial typos or logical errors, but one quite subtle error merely reduced precision in the fifth decimal place. The story quotes from a memoir by Wilkes, who recalls the exact moment when "the realization came over me with full force that a good part of the remainder of my life was going to be spent finding errors in my own programs." The SCIENCES story cites an article by Martin Campbell-Kelly in ANNALS OF THE HISTORY OF COMPUTING 14(4) 1992 and Maurice Wilkes' book MEMOIRS OF A COMPUTER PIONEER. - Jon Jacky, Department of Radiation Oncology, U. of Washington, Seattle
As a reader of RISKS who combines his vocation, journalism, with his avocation, computers, I'm writing in with a request. In the course of working on an assignment for one of the TV networks, I came across references to "offshore data havens." These are data networks, alleged to be in the formative process, which will glean data by means fair and foul from the world's legitimate data bases. The implication is that formerly confidential information, be it about individuals, corporations or governments, would seep across networks. The information would then be available, at a price, to anyone who wanted it. My questions are: * Are "offshore data havens" actually being formed, and if so, where? * What are the inherent problems that come to mind? Don't be afraid to state the obvious; television audiences aren't experts in this area. I'd love to see this become a topic for discussion on RISKS, but would also appreciate (with thanks in advance) any responses sent to me directly. john_bruni@cup.portal.com
Let's go back and review history (briefly). The CERT teams, beginning with the
original CERT at CMU, were a reaction to the now infamous Morris Worm of 1988.
The folks who "solved" the worm problem by disassembling the worm and
generating patches for the network community, in a matter of hours, were the
university people, both staff and students.
Then, we had source code.
Today vendors are more and more making their source code unavailable, or too
expensive, or available only under untenable terms(1). Fewer of us university
people now have source code for contemporary systems. Yet the crackers out
there have all the source code they can steal, which is quite a collection. I
know, I saw it.
The network is as vulnerable today as it was in 1988... We'll see what
happens the next time!
-Jeff
[1] Terms for example that prohibit students from having access.
> The problem with restricting information to CERT teams, etc. is that this: > 1 - creates a techno-elite > 2 - limits distribution far too much And in any case, I don't think it works. A couple years ago, I was handed the job of running a cluster of machines at Caltech. Through various connections (Caltech, JPL, CERN, the HEP community, etc.) I ended up on many public and private mailing lists for security information, without even trying. Usually I'd receive a half-dozen slightly different copies of the same alert, before the sanitized CERT version went out. (This was useful for gauging the severity: if I only received a couple pre-CERT notes, I could probably defer the problem; if I received ten, I had to act.) I think the restrictions the various Response Teams give themselves serve only to allow them to tell themselves — and more importantly, their bureaucrats and lawyers — "We're doing everything possible to limit the spread of dangerous knowledge." Whether their efforts in this direction accomplish anything or not is another question.
According to the Globe and Mail (last Saturday, I think), the discrepancy arose because the police counted individual offenses, whereas StatsCan counted "incidents", which could encompass several offenses (e.g., a rape could result in charges of assault, sexual assault, use of a weapon, etc.). --Rodney
While paying for groceries at a "pack the bags yourself" discount supermarket,
I presented a chit for a $15 credit, obtained when I returned several bags of
soda cans. The cashier punched the cash register, and it stopped with an
alert condition. It seems that "manager approval" is required whenever a
credit of more than $5 is entered. At this store, the managers have long
since tired of dealing with these alerts, so they have issued manager-only
cash register override keys to all cashiers.
The cashier inserted and twisted a key, and the machine began to void
out the entire $100 transaction, item by item.
cat food, -$0.29
cat food, -$0.29
...
The cashier shrieked for help, but it was not to be had; the manager
trainee on duty that Labor Day didn't know anything more than she did.
After a minute or so, the cash register finished up and displayed
balance: $0.00
The young lady turned to me and explained that she would have to pass
every item over the scanner again. Unpack forty cans of cat food and
fifty jars of baby food? I explained that this option was not
available to her, and that she had needed to devise another solution.
She proceeded to phony up a set of transactions to create a balance identical
to the one I'd had before the disaster. Her arithmetic was none too good, so
she adjusted it by entering fictitious coupon discounts.
As I paid (the correct amount), she explained that there are *two* keys — the
"manager" key and the "professional" key. The latter is used only to turn on
the cash register in the morning, and to void out an entire transaction.
There is a single lock on the register, into which either key is inserted.
The two keys are hard to distinguish from each other. And store management
keeps them on a single keyring for ease of access.
(This same store also allows forklifts in the aisles during business hours,
with employees riding the fork in violation of OSHA rules. And they are
building a database of individual purchasing habits. It's a wellspring of
RISK examples.)
-=- Andrew Klossner (andrew@frip.wv.tek.com)
>The cost of an exhaustive attack is an interesting number. It gives us an >upper bound for the cost of efficient attacks. However, it is never, itself, >an efficient attack. What has bothered me for some time about Clipper/Capstone/SkipJack is exactly this question and the concern that what might be an exhaustive to some might not be what the user would think. Consider the possibility that every person in the United States were issued a SkipJack key - better, suppose that every possible ZIP code in the United States were issued a key (10^9 as opposed to approx. 2.5*10^8 women, men, and children). Next suppose that every key issued were known (not WHO they were issued to, just WHICH had been issued). An exhaustive attack is now 10^9 trials with average success in 5*10^8 trials. At a 40 MHZ rate (common for DSPs) this would take well under a minute for an exhaustive search. No trapdoors, backdoors, or weak keys. Just a database of all issued keys. In the sixties, a thief who wanted your GM car often did not have YOUR key, they had ALL the keys (on a ring about six inches in diameter - typically took about five minutes to find the right one). The disclaimer here is usually one of random seeds etc but does anyone really think that every key is going to have a unique random seed ? Or is it more likely that the two agents will each contribute their 80 bit piece and then a few thousand keys run off. And that the first (or last) from each batch along with the count might be for some nameless agency ? My belief is that the SkipJack algorithm is every bit as strong as everyone has said it will be. The question will it really take an exhaustive attack or will there be a "black bag" attack possible that will stem from the key generation process. Creative accounting at work. Padgett ps I believe in Clipper/Capstone/SkipJack & if the price is within reason will be one of the first to use it. Most people do not care if our government can listen in. Just no surprises, Teapot Domes, or fingers- crossed promises please.
jhudson@legent.com writes: > Now that 3 children have died and 13 more spent time in hospitals, local > organizations are distributing safety bars for windows. This example reminded me of an old saying in the architectural and building trades: "Building codes are written in blood." Every requirement that exists in modern building codes was created to prevent a repeat of previous deaths. Not that we should feel complacent, but the difficulty is hardly limited to software development. Taking shortcuts is a time-honored activity, and when it works it has clear benefits: there's no value in making a beam 10 times stronger than it needs to be, while there's lots of value in building a house affordably. The trick is to learn the *appropriate* safety factor. Neither safety-be-damned nor safety-at-ANY-cost is a workable approach. But probing the margin of what's safe tends to lead to accidents. As long as foresight is not 20-20, there's no way around this. Petroski's book "To Engineer is Human" is an excellent discussion of the technical and moral dilemmas involved here. Required reading for RISKS folk. Tom Lane
The following is an excerpt from the "Caller ID And Blocking Fact Sheet" I
received from New England Telephone.
How Does Line Blocking Work With Emergency Calls?
If you have Line Blocking and an emergency service provider has
Caller ID, the provider will NOT receive your number UNLESS you
unblock your number by pressing *67 (dial 1167 on a rotary/pulse
phone) before you call '911' or other seven digit emergency numbers.
Line Blocking and Per-Call Blocking pertain to Caller ID only. Call Trace
and Call Return are unaffected by either Line Blocking or Per-Call Blocking.
# Monty Solomon / PO Box 2486 / Framingham, MA 01701-0405
# monty%roscom@think.com
[I have a huge collection of messages on blocking, dialing 1, *67,
and related topics. I think we have peaked on those discussions,
so I'll call a halt for a while. Thanks to all of you who sent in
contributions on those topics. PGN]
Kenneth Wood reported the saga of a bank that mailed letters to its 2000 wealthiest customers, all addressed to "Rich Bastard", thanks to a careless programmer. It's worth noting that if the bank had given the mailing even a cursory check before dropping it into the mail stream, the odds are that the mistake would have been noticed and the mailing aborted. Of course, one can't expect a bank to personally inspect every envelope that churns out of their automated systems. But it would seem that with a relatively small mailing of such importance (dealing with your biggest customers) a little extra checking would have been a good investment! The RISK is putting total faith in the system, of course. --Lauren--
From Washington Post newswire 08/27
U.S. Acts to Ease Export Controls On Computers; Industry Officials
Say Proposed Standard Falls Far Short of Need
By Peter Behr, Washington Post Staff Writer
"The Clinton administration moved yesterday to ease Cold War-era
controls on exports of high-powered U.S. computers to the former Soviet
Bloc and other countries, fulfilling a campaign promise President Clinton
made to the Silicon Valley executives who supported him last year."
The article continues with comments on the lost sales caused by Cold War
restrictions on computer exports. The new Commerce Decision rules allow
export of microprocessors rated at 67 Mops (million operations per second),
a big boost from the previous limit of 12 Mops. However, multiprocessor
units are still on the forbidden list.
Sales to the former Soviet Union are still subject to approval by COCOM,
the Coordinating Committe for Multilateral Export Controls. Apparently
some members of COCOM--Germany, in particular--are trying to link
relaxation of computer export restrictions with relaxation of
telecommunications gear.
***
It will be interesting to see if the long-standing assumption that export
restrictions prevent the distribution of technology to the interdicted
nations. My reading of the DES-restriction debacle is that export controls
on high tech are a farce. The U.S. restrictions hurt U.S. manufacturers
and are a boon for everyone else.
Michel E. Kabay, Ph.D., Director of Education, National Computer Security Assn
The only conclusion I seem to be able to draw from problems like the
sendmail DEBUG hole is that more care needs to be spent designing software so
that bugs in security-critical programs CANNOT compomise the system.
Mailers are inherently complicated things, that require privileges in
order to work. It seems to me that in designing a complex program that
requires privileges, the complex part and the privileged part should be
separated. The privileged part should be simple enough that its function can
be verified in a couple of minutes of code-browsing with a cup of cappucino.
The complex part can be as convoluted and gnarly as you wish, and can have all
the debug options its complexity requires.
A good example of this design philosophy is anonymous FTP. There was a
pretty nasty bug recently described in the wustl ftpd, a popular
implementation that is widely used. Any user on the network could get root
access to a system running that version of ftpd. How can this happen? Because
ftpds are complicated and do lots of stuff (especially the wustl one, which is
extremely "feature heavy") - they also require privs in order to work right.
This is a deadly combination. You'll find it wherever there are consistent
security problems. A lateral thinking approach to FTP is to configure ftpd the
way we do at TIS: you do the chroot and setuid before ftpd is even invoked.
Ideally, the worst the complex code can do to you is give you a core
dump. Ideally, the critical code should be a page or 2 of clear,
straightforward operations. If you have to comment your security critical
code, perhaps it's too complex. ;)
mjr.
Notice of Meeting and Call for Papers
8th Z User Meeting - ZUM'94
Organized by the Z User Group in association with BCS FACS
29-30th June 1994
St. John's College, University of Cambridge, UK
Program committee:
Rosalind Barden, Logica, Cambridge Jonathan Jacky, Univ. of Washington, USA
Jonathan Bowen, Oxford Univ. Peter Lupton, IBM Hursley
Elspeth Cusack, BT John McDermid, York University
Neville Dean, Anglia Polytechnic Univ. Sylvio Meira, Univ. of Pernambuco,Brazil
David Duce, Rutherford Appleton Lab. John Nicholls, Oxford Univ.
Anthony Hall, Praxis plc Gordon Rose, Univ. Queensland, Australia
Brian Hepworth, British Aerospace Chris Sennett, DRA Malvern
Howard Haughton, Lloyd's Register Sam Valentine, Univ. of Brighton
Mike Hinchey, Univ. of Cambridge Jim Woodcock, Oxford Univ.
Darrell Ince, Open Univ. John Wordsworth, IBM Hursley
The committee of the Z User Group invites the submission of papers related to
the interests of users of the formal notation Z. Sessions on the following
themes are planned, and papers on these topics are especially encouraged:
* Industrial experiences
* Application of Z to safety-critical systems
* Projects and processes for formal methods - organizational issues
* Z and concurrency
* Educational issues (an extra half-day session)
Papers for presentation and publication will be reviewed and selected by the
program committee. The timetable for submitted papers is as follows:
Submission of draft paper: 1st October 1993
Notification of acceptance: 30th November 1993
Final copy for Proceedings: 31st January 1994
Z User Meeting in Cambridge: 29-30th June 1994
A maximum limit of 20 pages is requested. Industrial contributors may submit
extended abstracts if they prefer. Please include four copies of your
submission and indicate if you wish your paper to be considered for one of the
special themes. The following invited speakers are planned:
David Garlan, Carnegie-Mellon University, USA: Z and education
Mike Gordon, University of Cambridge, UK: Z and HOL
Leslie Lamport, DEC Systems Research Center, USA: Z and concurrency
Jim Woodcock, Oxford University, UK: Z and MoD 00-56
Robert Worden, Chairman of Logica Cambridge, UK: Z and industry
Maurice V. Wilkes, Olivetti Research (Emeritus Professor, University
of Cambridge): After dinner speaker on the occasion of the 45th
anniversary of the EDSAC meeting (first European computer
conference) held in Cambridge, June 1949, and hosted by him.
The meeting will be sponsored by BT, Logica and Praxis and is supported by
the UK BCS FACS group the European ESPRIT ProCoS-WG (8694) Working Group.
General enquiries may be directed to:
Jonathan Bowen (Conference Chair)
Oxford University Computing Laboratory, 11 Keble Road, Oxford OX1 3QD, UK
Email: Jonathan.Bowen@comlab.ox.ac.uk
Tel: +44-865-272574, Fax: +44-865-273839
Submitted papers and extended abstracts should be sent to:
Anthony Hall (Programme Chair)
Praxis Systems plc, 20 Manvers Street, Bath BA1 1PX, UK.
Email: jah@praxis.co.uk
Tel: +44-225-444700, Fax: +44-225-465205
Proposals for tutorials, tool demonstrations, publishers' stands, and
requests for information concerning local arrangements should be sent to:
Mike Hinchey (Tutorial Chair)
University of Cambridge, Computer Laboratory
New Museums Site, Pembroke Street, Cambridge CB2 3QG, UK
Email: Michael.Hinchey@cl.cam.ac.uk
Tel: +44-223-334419, Fax: +44-223-334678
Until beginning of October 1993 at DEC Systems Research Center,
Palo Alto, California, USA, Email: hinchey@src.dec.com
A special session on Educational Issues relating to Formal Methods (Z
in particular) is being organized for the Friday morning (1 July 1994)
after the main Z User Meeting 1994 to be held in Cambridge (29 and 30
June 1994). For further information, please contact:
Neville Dean (Education Session Organizer)
Applied Sciences, Anglia Polytechnic University, Cambridge CB1 1PT, UK
Email: CDEAN@vaxa.anglia-polytechnic.ac.uk
Tel: +44-223-352992 ext 2329, Fax: +44-223-352979
Subscribers to RISKS may be interested in attending and/or presenting a paper at the 1994 Annual Meeting of the Northeast Decision Science Conference, April 6-8, at the Sheraton Hotel and Conference Center in Portsmouth, New Hamshire. The conference has a Business Law/Business Ethics track which last year featured papers on the implications of the Americans with Disabilities Act for ATM managers, and the legal implications of Expert System use. Other tracks include: Accounting Curriculum and Studies Environmental Management Finance and Real Estate Human Resource Management International Business Management Science Marketing MIS/DSS/AI Microcomputing Organization, Theory, Policy and Behavior Operations Management Quality/Productivity Service Management Statistical Theory & Applications Papers presented are also published in the conference proceedings. All papers must be double spaced. Authors must submit one copy plus three additional copies for each track for which the paper is to be considered. Papers should not exceed 20 pages in length. Each copy of the paper should have two title pages. The first should have both the title and author information (including mailing address); the second should have only the title. Each submission should include a 3" X 5" card with the following data: 1. Author(s) 2. Affiliation 3. Address(es) 4. Office and Home Phone Numbers 5. Submission Title 6. Appropriate Track(s) Each submission should also include a stamped, self-addressed postcard with the author(s) name and the title of the submission for acknowledgement of receipt by the Program Chairperson. Papers must be received no later than October 3, 1993. Notifications of acceptance will be mailed by December 1, 1993. Accepted papers must be typed in final condensed and camera-ready form and returned to the Proceedings Editor by January 5, 1994. Specific instructions will be mailed to the authors with the acceptance letters. Submissions are to be sent to: Dan Reid 1994 NEDSI Program Chairperson Whittemore School of Business and Economics University of New Hampshire Durham, NH 03824 (603) 862-3382 The Sheraton Portsmouth Hotel and Conference Center has provided a limited number of rooms at the rate of $89-94/night (single) and $99-104/night (double), plus tax. (For reservations call (603) 431-2300 and state that you are attending the NEDSI Meeting). Other questions, contact chair.
Please report problems with the web pages to the maintainer