The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 16 Issue 58

Friday 26 November 1994

Contents

o Hacker learns intelligence secrets
Mathew Lodge
o Automated Weather Reports for Pilots
Tom Keenan
o Extended Phone Failure in Iowa City
Douglas W. Jones
o Enormous water bills - gigo strikes again
James M. Politte
o Computer-generated bridge-tournament hands
G. Gates/M. Brader/PGN
o The PC as a RISC (how could I resist 8*)
A. Padgett Peterson
o Problem with 911 service in Philadelphia
Paul Robinson
o Department store security cameras linked to computer
David Hembrow
o Children on the Infobahn
Bradley K. Sherman
o Re: Pentium FDIV bug
Mike Carlton
o Re: Cell-phone ergonomics side-effect
Bill Innanen
Paul Robinson
o Re: Anon. on "TEN Q's"
Mark Seecof PSD x77605
o Info on RISKS (comp.risks)

Hacker learns intelligence secrets

Mathew Lodge <lodge@ferndown.ate.slb.com>
Thu, 24 Nov 94 09:09:38 GMT
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    lodge@ferndown.ate.slb.com (+44) (0)202 893535 x404

   [The *Independent* items are in their entirety (28K) in
   RISKS-16.58BT, courtesy of Brian Randell.  PGN]


Automated Weather Reports for Pilots

"Tom Keenan" <keenan@acs.ucalgary.ca>
Fri, 25 Nov 94 0:31:28 MST
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


Extended Phone Failure in Iowa City

Douglas W. Jones,201H MLH,3193350740 <jones@pyrite.cs.uiowa.edu>
23 Nov 1994 04:08:25 GMT
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  jones@cs.uiowa.edu


Enormous water bills - gigo strikes again.

"James M. Politte" <oprime@netcom.com>
Wed, 23 Nov 1994 09:47:02 -0800 (PST)
 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 - oprime@netcom.com

   [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]


Computer-generated bridge-tournament hands

"Peter G. Neumann" <neumann@csl.sri.com>
Wed, 23 Nov 94 16:48:10 PST
Mark Brader (msb@sq.com) forwarded a note from ggates@Starbase.NeoSoft.COM
(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".


The PC as a RISC (how could I resist 8)*

A. Padgett Peterson, Information Security <padgett@tccslr.dnet.mmc.com>
Thu, 24 Nov 94 08:43:43 -0500
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


Problem with 911 service in Philadelphia

Paul Robinson <PAUL@tdr.com>
Fri, 25 Nov 1994 15:20:24 -0500 (EST)
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 - Paul@TDR.COM


Department store security cameras linked to computer

David Hembrow <davidh@harlequin.co.uk>
Tue, 22 Nov 1994 12:55:30 +0000
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


Children on the Infobahn

Bradley K. Sherman <bks@s27w007.pswfs.gov>
Tue, 22 Nov 94 22:38:04 PST
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 bks@s27w007.pswfs.gov  510-559-6437


Re: Pentium FDIV bug

Mike Carlton <carlton@ISI.EDU>
Wed, 23 Nov 1994 01:34:11 -0800
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 carlton@isi.edu  USC/Information Sciences Institute  (310) 822-1511


Re: Cell-phone ergonomics side-effect (Stanley, RISKS-16.57)

Bill Innanen <wgi@aplcomm.jhuapl.edu>
Sat, 26 Nov 1994 12:09:02 -0500
Robert Stanley (rstanley@sybase.com) 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   wgi@aplcomm.jhuapl.edu


Re: Cell-phone ergonomics (Stanley, RISKS-16.57)

Paul Robinson <PAUL@tdr.com>
Wed, 23 Nov 1994 15:35:54 -0500 (EST)
> ... 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 - Paul@TDR.COM

   [Also noted by
      padgett@tccslr.dnet.mmc.com (A. Padgett Peterson),
      wolit@library.att.com (Jan I. Wolitzky),
      minow@apple.com (Martin Minow).]


Re: Anon. on "TEN Q's" (RISKS-16.57)

Mark Seecof PSD x77605 <marks@bierce.latimes.com>
Wed, 23 Nov 1994 17:43:33 -0800
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 <marks@latimes.com>

Please report problems with the web pages to the maintainer

Top