Subject: RISKS DIGEST 16.58
REPLY-TO:
[email protected]
Errors-To:
[email protected]
RISKS-LIST: RISKS-FORUM Digest Friday 26 November 1994 Volume 16 : Issue 58
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
***** See last item for information on RISKS (comp.risks), disclaimers *****
Contents:
Hacker learns intelligence secrets (Mathew Lodge)
Automated Weather Reports for Pilots (Tom Keenan)
Extended Phone Failure in Iowa City (Douglas W. Jones)
Enormous water bills - gigo strikes again (James M. Politte)
Computer-generated bridge-tournament hands (G. Gates/M. Brader/PGN)
The PC as a RISC (how could I resist 8*) (A. Padgett Peterson)
Problem with 911 service in Philadelphia (Paul Robinson)
Department store security cameras linked to computer (David Hembrow)
Children on the Infobahn (Bradley K. Sherman)
Re: Pentium FDIV bug (Mike Carlton)
Re: Cell-phone ergonomics side-effect (Bill Innanen, Paul Robinson)
Re: Anon. on "TEN Q's" (Mark Seecof PSD x77605)
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.
----------------------------------------------------------------------
Date: Thu, 24 Nov 94 09:09:38 GMT
From: Mathew Lodge <
[email protected]>
Subject: Hacker learns intelligence secrets
The London "Independent" newspaper of 24-Nov-94 leads with a story that a
"hacker" gained access to a sensitive database of telecommunications
information at British Telecommunications (BT), the UK's largest (and ex-state
owned) carrier. The story was also carried by all the major television and
radio news programmes.
Tim Kelsey, author of the Independent story, reveals that details such as
telephone numbers and addresses for secret installations of the Ministry of
Defence, MI5 (the British intelligence agency responsible for the UK) and
MI6 (like MI5, but handles non-UK affairs).
"Thousands of pages of highly confidential BT records were sent across the
Internet to a young Scottish journalist, Steve Fleming, in July". Mr
Fleming received the information after making a news posting asking for
information on BT and hacking. The informant remained anonymous -- details
of how this was achieved are not given.
The hacker also gave details to Mr Fleming about how he too could access
the information. He applied through an employment agency for a short-term
contract at BT as a database designer, clearly stating on his CV that he
was a freelance journalist. He got the job, and was able to gain access to
the information because passwords were just left lying around the office.
BT is still going through a major staff restructuring programme, and as a
result has a large number of temporary (contract) staff. These staff need
passwords to the system to legitimately carry out their jobs, but because
of the constant flow of people, the passwords are often written down.
Mr Fleming learned, among other things,
* The location of MI6's training centre ("spy school"), located in a
non-descript building next to a pub in south London
* Information about the bunker in Wiltshire where the Government would go
in the event of nuclear war
* Details of telephone installations at Buckingham Palace and 10 Downing
Street [the Prime Minister's home], including personal lines to John
and Norma Major.
The system itself, the "Customer Services System", was designed and
implemented by an American company, Cincinnati Bell. It is supposed to have
internal mechanisms to prevent hacking (!)
So, what are the risks (briefly!)
1) Allowing temporary staff passwords that allow almost any data to
be retrieved. It sounds as if the security levels of the database
were either non-existent, or compromised.
2) Keeping sensitive information in the same database as
non-sensitive information.
3) The age-old chestnut of the uses of passwords.
A BT spokesman, speaking on the "Today" programme on BBC Radio 4 confirmed
that a "top level" investigation had been launched, but refused to confirm
or deny that the hack had taken place.
Mathew Lodge, Software Engineer, Schlumberger Technologies, Ferndown,
Dorset, UK, BH21 7PP
[email protected] (+44) (0)202 893535 x404
[The *Independent* items are in their entirety (28K) in
RISKS-16.58BT, courtesy of Brian Randell. PGN]
------------------------------
Date: Fri, 25 Nov 94 0:31:28 MST
From: "Tom Keenan" <
[email protected]>
Subject: Automated Weather Reports for Pilots
According to a piece on the CBC Alberta News on Nov 24:
Pilots are complaining about the inaccurate weather forecasts
being provided by new automated weather briefing equipment
installed at an Edmonton airport (and soon to be operational at
the Calgary airport.) The system apparently cannot keep up with
changing weather conditions and, in one specific case, a
Canadian Airlines plane landed in snow although the forecast did
not mention any snow. The airline has complained, and union
members are arguing for a return to human delivery of weather
info to pilots.
Dr. Tom Keenan, I.S.P., Dean, Faculty of Continuing Education, Univ. Calgary
2500 University Dr. NW Calgary, AB T2N 1N4 CANADA (403) 220-5429
------------------------------
Date: 23 Nov 1994 04:08:25 GMT
From:
[email protected] (Douglas W. Jones,201H MLH,3193350740)
Subject: Extended Phone Failure in Iowa City
On Saturday, Nov 19, Iowa City's telephone system, run by US West, shut down
at about 3:30 PM, local time, and service was not restored until between
7:30 and 9:30 PM (service was brought up a bit at a time). As phone outages
go, this was fairly severe! The population of the effected community is
over 60,000.
The Iowa City Press Citizen, on Tuesday, Nov 22, reported that the cause of
the failure has finally been determined. In July, a new telephone switching
system was installed, and in the past week, the old system was removed from
the building. As part of the removal process, the paper reports that an
electrical grounding cable was inadvertently removed, leaving the new switch
improperly grounded.
Apparently some customers noticed intermittent problems with their phone
service earlier in the day, and US West had technicians working on the
problem before the failure, but they were unable to diagnose the problem
until some time after the failure had occurred.
Once the failure was diagnosed, the paper's description makes it sound as if
the missing cable must have been easy to replace, but the 2 hour delay
between the fix and the complete restoration of service is disturbing. They
had to cold-start the ESS system or systems involved (can you put over
20,000 phones on one system?), but this can't account for 2 hours, can it?
My alternate hypothesis is that the improper grounding connection blew large
numbers of fuses in alternate ground paths that weren't supposed to carry
current, leading to a very time consuming job putting things right.
Lessons: First, this failure seems to be a perfect example of the fact that
grounding problems are notoriously difficult to diagnose. Second, I suspect
that nobody involved in the design of modern ESS systems would have guessed
that it would take 2 hours to restore service after the fault was repaired.
People who do such analysis or design other fault tolerant systems may need
to look at this failure as an example. I'm eager to see more technical
detail than the newspaper provided!
Doug Jones
[email protected]
------------------------------
Date: Wed, 23 Nov 1994 09:47:02 -0800 (PST)
From: "James M. Politte" <
[email protected]>
Subject: Enormous water bills - gigo strikes again.
In the quiet western-Missouri town of Warrensburg, a small house with
two occupants recently received a water bill amounting to $4,704.88.
The water meter had been replaced with a new one, and being new, it read
"000000". The previous reading from the last month, was "017060". The
computer assumes that numbers on a water meter only go up, of course. So
it was perfectly logical for the computer to assume that "000000" was
caused by the meter rolling-over after reaching "999999".
Subtracting 017060 from 1000000 yields 982940 - and I was in fact billed
for using 982940 cubic feet of water. (That's a column of water with a
base the size of my house and 495 feet tall.)
The water company was quick to correct this problem upon hearing about
it - but imagine if I had enrolled in the automatic payment program which
subtracts bills directly from my bank account...
J.Politte -
[email protected]
[A previous case due to the same cause, resulting in a water bill of
$22,000, appeared in RISKS-12.16, Software Engineering Notes, vol 16,
no 4, October 1991, and page 191 of my RISKS book. PGN]
------------------------------
Date: Wed, 23 Nov 94 16:48:10 PST
From: "Peter G. Neumann" <
[email protected]>
Subject: Computer-generated bridge-tournament hands
Mark Brader (
[email protected]) forwarded a note from
[email protected]
(Georgiana Gates) from rec.games.bridge. Georgiana played in the recent
Minneapolis Women's board-a-match Nationals bridge tournament, and she and
others noted that the computer-generated hands were IDENTICAL to those from
the first half of the semifinals of the Women's Knockout in San Diego (in
which they had also played).
This is not the first time for such an occurrence. RISKS-7.62, 7 Oct 1988
included an item from a New York Times column by Alan Truscott, contributed
by Paul Abrahams, which I entitled "Bridge over troubled pseudo-random
generation".
I presume that the initialization values for the pseudorandom generator
were duplicates. It certainly gives a new meaning to the term "duplicate
bridge".
------------------------------
Date: Thu, 24 Nov 94 08:43:43 -0500
From:
[email protected] (A. Padgett Peterson, Information Security)
Subject: The PC as a RISC (how could I resist 8)*
Just in time for the holiday season comes a new feature for the
PC - self-executing and playing Christmas Cards you can send to people
with only E-Mail reception.
Did you know that it is possible to write a complex program on the PC
using only ASCII printing characters ? XOR, AND, branching JMPs, PUSH,
POP, SUB, INC, and DEC all exist within the range of 40h-7Eh. True,
not all register and memory combinations can be used but enough.
After seeing an example done, I set out to make a few tests of my own
and have determined that is possible to write a program using only
ASCII characters that can decode and transfer execution to a "normal"
COM file that has been ASCII-encoded something like UUENCODE.
Of course with UUENCODE the problem is that first you needed to have the
UUDECODE program. With an ASCII-executable program, the medium is the message.
This is just what the world needs: self-extracting and executing E-Mail.
Padgett
------------------------------
Date: Fri, 25 Nov 1994 15:20:24 -0500 (EST)
From: Paul Robinson <
[email protected]>
Subject: Problem with 911 service in Philadelphia
CNN Reported that more than a dozen calls went into the Philadelphia 911
center to report a riot and fighting. Reports from callers ranged from
civil to frantic as they called to report a serious incident occurring,
while the 911 dispatch operators ranged from uninterested to downright rude.
A sample of one of the calls reported was something like this:
Caller: We need the police at 7100 Ridgeway, there's a group of
people in a fight...
Dispatch: (Bored) Is that all?
Caller: (Incredulous) IS THAT ALL? There's a caravan of cars
coming down here to participate in a damn riot, that's all!
Another caller returned a call reporting a fight verging on a riot in their
area. The 911 Dispatcher replied that she didn't know where they were.
It's that response that I wonder about; aren't most large city 911
systems equipped with name and ID for calls that come in? Smaller
Cities, I can understand may simply use 911 as a substitute for dialing
their emergency number and may not have name/phone lookup capability.
What got people upset was that, despite over a dozen 911 calls, police
still took 40 minutes to show up, at which point they called the coroner
to handle one dead 14-year-old, killed by some other teenagers armed with
nothing stronger than baseball bats. (So much for the claims that gun
control would make the streets safer.)
You can have all the high technology in the world and all the latest
equipment, but if you either don't have the people on hand, or the people
you have don't care, the technology can make things worse.
Paul Robinson -
[email protected]
------------------------------
Date: Tue, 22 Nov 1994 12:55:30 +0000
From:
[email protected] (David Hembrow)
Subject: Department store security cameras linked to computer
Electronic Snap (UK "PC Week" magazine, 22 November 1994)
Not-so saintly shoppers in Marks and Spencer's will soon find themselves
matched up in an electronic version of Snap! if they dare try beating the
latest security move. The company will use ceiling mounted video cameras
fitted to computers to compare pictures of known shoplifters in a trial in
one of its stores. Watch out, Beadle's about, and the police aren't far
away.
[Obvious risk of false positives ( which shoplifter do I look like? ),
false data being in the computer in the first place etc.]
Jeremy Beadle is a much hated/loved TV presenter in the UK who presents a
show a little like Candid Camera. Snap! is a card game played
(predominantly) by children. The objective is to match two identical
playing cards.
David Hembrow, Harlequin Ltd
------------------------------
Date: Tue, 22 Nov 94 22:38:04 PST
From:
[email protected] (Bradley K. Sherman)
Subject: Children on the Infobahn
I'm the father of a 9-year-old girl and a 4-year-old boy. I live in a major
metropolitan area --Oakland, California. As far as I'm concerned they can
read anything they want. They're not going to find anything on the USENET
that comes close to the real horror that exists on the streets of our
cities. I'm just happy that they have the desire and ability to read (well,
this is stretching it for the four-year-old).
I wonder what newsgroups the kids in Sarajevo are reading?
Bradley K. Sherman, Dendrome Project, Institute of Forest Genetics, PO Box 245
Berkeley, CA 94701
[email protected] 510-559-6437
------------------------------
Date: Wed, 23 Nov 1994 01:34:11 -0800
From:
[email protected] (Mike Carlton)
Subject: Re: Pentium FDIV bug
It would be nice to know just how bad the bug is. Intel certainly isn't
being very helpful. I ran a set of experiments this last weekend and found
819 divide cases with less than single-precision accuracy on the pentium. I
found 66 cases with just 14 bits accuracy (as in the first 4195835/3145727
example). BTW, that example was originally posted to comp.sys.intel by Tim
Coe of Vitesse Semiconductor.
More info on my experiments is at:
ftp://www.isi.edu/pub/carlton/pentium
For another simple example (the smallest my searching found), try the
following in a spreadsheet or calculator program running on a pentium:
5505001/294911 = 18.66600093 on a buggy pentium
= 18.66665197 the correct answer
The original reports of the bug mentioned double precision cases which
returned 29 or so bits of accuracy, instead of the expected 52. At
that point I wasn't very concerned by the bug (we had just taken
delivery of a pentium workstation and I convinced the machine's user
that it wasn't necessary to ask for a replacement processor). I've
since changed my mind.
People have correctly pointed out that there are bugs in the OS, the
compiler, your application program, etc. How many programs really need
need more than 29 bits accuracy?
But Tim Coe's post showed that the error could get much worse than
that. Tim also pointed out that the bug can occur in both single and
double precision divides. Drawing upon his information, I was able to
come up with a small set of divisors likely to cause the bug and write
a search program that takes just 30 minutes to find the 800 cases.
The risk? How about the way Intel marketing has handled this
situation? They have not (yet) publicly described the extent of the
bug. I've heard numbers like a 1 in 10^10 chance of hitting it and my
back-of-the-envelope calculations tend to agree with this. It could
be higher though, we have no way of knowing yet.
However, Intel hasn't described the magnitude of the errors. Could it
be less than 14-bit accuracy? My experiments lead me to believe that
it won't get any worse, but until Intel comes forward with a description
of the cause of the bug we won't know. Until then, can people really
rely on pentium calculations for critical work? If you can't trust
any result there is no point in using the pentium.
What I really don't understand is why Intel didn't set up a PC doing
random testing with one of the first pentiums off the fab line. Doing
so would have exposed this bug in short order. It looks like that
failure may turn out to be quite expensive.
--mike
[email protected] USC/Information Sciences Institute (310) 822-1511
------------------------------
Date: Sat, 26 Nov 1994 12:09:02 -0500
From:
[email protected] (Bill Innanen)
Subject: Re: Cell-phone ergonomics side-effect (Stanley, RISKS-16.57)
Robert Stanley (
[email protected]) wrote in RISKS-16.57 about a mishap
with a Nokia pocket sized cellular telephone. In this instance the one
touch re-dial feature of the phone was inadvertently activated while in the
owner's pocket, resulting in a supposedly private meeting being recorded on
an answering machine.
As a (very satisfied) owner of a Nokia cell phone I would add a couple more
RISKS. Namely, failure to become acquainted with the features of one's
high tech widgets, and/or the failure to use same.
On my model 2120 Nokia there are two features either one of which would
have prevented this mishap. As Mr. Stanley notes, the Nokia does not have
a flip cover to protect the buttons from inadvertent presses. I personally
think this lack is a Good Idea. The fewer moving breakable parts the
better. However there is definitely a need to protect the keyboard. Nokia
handles this electronically rather than mechanically. On my phone the
"Keyguard" function is activated by the key sequence <Menu>-*. This this
puts a notice on the screen that the keyboard is protected until the same
key sequence is entered again. One can still answer the phone with the
Keyguard active, however. I habitually keep the Keyguard active since I
also carry my phone in my pocket. (Pants pocket in my case -- my shirt
pocket is occupied by my "nerd protector" full of pens and pencils.)
The other Nokia feature that could have averted this problem is that the
"one touch re-dial" can be turned off via the configuration menu.
Personally I find it convenient and use it, relying on the Keyguard to
protect me from unwanted redials.
Bill Innanen
[email protected]
------------------------------
Date: Wed, 23 Nov 1994 15:35:54 -0500 (EST)
From: Paul Robinson <
[email protected]>
Subject: Re: Cell-phone ergonomics (Stanley, RISKS-16.57)
> ... it is an extraordinarily sobering experience to hear
> a sensitive work discussion issuing hours later from the
> speaker of your home voice messaging system.
Question: is this real or are you just repeating the plot of Michael
Crichton's {Disclosure}? :)
In {Disclosure}, the main character claims his boss - who is female -
sexually harassed him by placing him in a compromising situation and trying
to force him to have sex with her (he is married). He is able to show that
she forced herself on him because he was testing a shirt-pocket sized
cellular phone, had called a friend on it, and had not hit the "END" key,
and his friend ended up with a recording of this "sensitive work discussion"
on HIS answering machine...
Life imitates fiction.
Paul Robinson -
[email protected]
[Also noted by
[email protected] (A. Padgett Peterson),
[email protected] (Jan I. Wolitzky),
[email protected] (Martin Minow).]
------------------------------
Date: Wed, 23 Nov 1994 17:43:33 -0800
From:
[email protected] (Mark Seecof PSD x77605)
Subject: Re: Anon. on "TEN Q's" (RISKS-16.57)
I agree with anonymized but urge: when giving "polite false" telephone
numbers to salespeople, give NULL numbers, dammit, not random ones. I don't
want calls from your sales contacts. (I find the TOD number (locally
853-1212) works well.)
Mark Seecof <
[email protected]>
------------------------------
Date: 23 November 1994 (LAST-MODIFIED)
From:
[email protected]
Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.
The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks.
Undigestifiers are available throughout the Internet, but not from RISKS.
SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on
your system, if possible and convenient for you. BITNET folks may use a
LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S.
users on .mil or .gov domains should contact <
[email protected]>
(Dennis Rears <
[email protected]>). UK subscribers please contact
<
[email protected]>. Local redistribution services are
provided at many other sites as well. Check FIRST with your local system or
netnews wizards. If that does not work, THEN please send requests to
<
[email protected]> (which is not yet automated). SUBJECT: SUBSCRIBE
or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent]
CONTRIBUTIONS: to
[email protected], with appropriate, substantive Subject:
line, otherwise they may be ignored. Must be relevant, sound, in good taste,
objective, cogent, coherent, concise, and nonrepetitious. Diversity is
welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS
MESSAGES in responses to them. Contributions will not be ACKed; the load is
too great. **PLEASE** include your name & legitimate Internet FROM: address,
especially from .UUCP and .BITNET folks. Anonymized mail is not accepted.
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.
All other reuses of RISKS material should respect stated copyright notices,
and should cite the sources explicitly; as a courtesy, publications using
RISKS material should obtain permission from the contributors.
ARCHIVES: "ftp crvax.sri.com<CR>login anonymous<CR>YourName<CR> cd risks:<CR>
or cwd risks:<CR>, depending on your particular FTP.
Issue j of volume 16 is in that directory: "get risks-16.j<CR>". For issues
of earlier volumes, "get [.i]risks-i.j<CR>" (where i=1 to 15, j always TWO
digits) for Vol i Issue j. Vol i summaries in j=00, in both main directory
and [.i] subdirectory; "dir" (or "dir [.i]") lists (sub)directory; "bye<CR>"
logs out. CRVAX.SRI.COM = [128.18.30.65]; <CR>=CarriageReturn; FTPs may
differ; UNIX prompts for username, password;
[email protected] and
WAIS are alternative repositories. See risks-15.75 for WAIS info.
To search back issues with WAIS, use risks-digest.src.
With Mosaic, use
http://www.wais.com/wais-dbs/risks-digest.html.
FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving
it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info
regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL
RISKS COMMUNICATIONS; as a last resort you may try phone PGN at
+1 (415) 859-2375 if you cannot E-mail
[email protected] .
------------------------------
End of RISKS-FORUM Digest 16.58
************************
