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…
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]
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
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
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]
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".
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
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
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
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
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
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
> ... 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).]
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