The RISKS Digest
Volume 21 Issue 93

Tuesday, 5th March 2002

Forum on Risks to the Public in Computers and Related Systems

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

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…

Contents

Malfunction shuts down computer-controlled amusement park ride
Chuck Hardin
A$ 22,000 in fines for missing car-toll transponder
Peter Trei
Air Transat emergency landing
John Johnson
Nick Petreley: Identity theft
Anthony W. Youngman
Metro: Time runs out for Domesday discs
Chris Leeson
RISKS to computers from society
Arthur J. Byrnes
Corporate Web sites leave cold steely feeling
Dan Jacobson
Tunneling too close to the person you're trying to protect: SafeWeb
David Martin
Privacy risk in Netscape 6
Sim IJskes
Electronic Voting in Ireland
Peter Thornton
Re: Miami-Dade OKs touchscreen voting
Les Barstow
Mark Nelson
Re: The homograph problem
Partha
Re: Dangerous Characters
Dick Botting
Darrell Fuhriman
Bill McGonigle
REVIEW: "Security Fundamentals for E-Commerce", Vesna Hassler
Rob Slade
Info on RISKS (comp.risks)

Malfunction shuts down computer-controlled amusement park ride

<Chuck Hardin <chardin@suchdamage.org>>
Sat, 02 Mar 2002 08:57:38 -0600

  http://news.bbc.co.uk/hi/english/uk/england/newsid_1850000/1850592.stm

  It was a perfect day in the capital for viewing the skyline from the giant
  London Eye.  But a computer problem made the 450-ft-high structure rotate
  too fast, and it was halted amid safety fears.  Engineers have been
  brought in to get the attraction, officially known as the British Airways
  London Eye, up and running again.

This calls to mind Ben Morphett's narrative in RISKS-21.50 about a carnival
ride which gave him a bad moment by displaying a blue screen of death just
before it began its (planned?) rapid descent.  The difference is that in his
case, the computer was merely providing some graphical effects and was not
apparently responsible for controlling the ride.  Not so in this case.

Four hundred and fifty feet is a long way to fall, or to be hurled, due to
an ill-considered RISK.


A$ 22,000 in fines for missing car-toll transponder

<"Trei, Peter" <ptrei@rsasecurity.com>>
Tue, 26 Feb 2002 15:20:10 -0500

  A man used City Link more than 220 times without an e-tag, attracting at
  least $22,000 in fines, because he did not know it had become a toll road,
  the Melbourne Magistrates Court was told yesterday. [...]
  http://theage.com.au/articles/2002/02/26/1014704951335.html

Some highways in Australia cannot be legally used without a radio tag.  This
poor soul hadn't updated his address with the DMV.  The RISK lies in
building systems which automatically rack up charges without limit, and no
backup notification system.  A big flashing sign saying 'E-Tag missing!'
might have helped.  Peter Trei


Air Transat emergency landing

<john.johnson@dalsa.com>
Mon, 4 Mar 2002 15:36:27 -0500

I thought RISKS readers would be interested in a developing story in the
news about a computer problem on the Canadian Air Transat flight that made
an emergency landing in the Azores last summer.  Apparently, as early
reports describe, a "computer program" incorrectly reported a fuel leak as
an "imbalance".  To correct the "imbalance" the "computer program" diverted
fuel from a good tank to the tank that was leaking thus both tanks were
emptied.  Inflight.  The skill of the pilot and the availability of an
island with an airport in the Atlantic Ocean averted a disaster.

Source: Canadian Press, *Toronto Globe and Mail*, *Toronto Star*, & other
Canadian newspapers


Nick Petreley: Identity theft

<"Anthony W. Youngman" <Anthony.Youngman@ECA-International.com>>
Thu, 21 Feb 2002 13:05:11 -0000

  http://www.computerworld.com/cwi/story/0,1199,NAV47-74_STO68446,00.html

Nick Petreley's *Computerworld* column (18 Feb 2002) describes how some
unknown person hijacked his phone account and made loads of long-distance
calls "at his expense".  The saga goes from bad to worse as poor security
and company incompetence frustrates his attempts to stop the fraud.

  [After noticing the frequent calls to Germany, Nick canceled his calling
  card and switched his long-distance carrier.  The person who had been
  piggybacking on his old card then managed to switch his new account back to
  the old carrier and make more calls.  It turns out that person had created
  a Web account for him, so that he no longer received statements.  The
  entire saga is a real horror story, and very well worth reading.  Lots of
  lessons to be learned.  PGN]


Metro: Time runs out for Domesday discs

<"LEESON, Chris" <CHRIS.LEESON@london.sema.slb.com>>
Mon, 4 Mar 2002 09:51:50 -0000

The BBC's 1986 Domesday Project (a time capsule containing sound, images,
video and data defining life in Britain) is now unreadable. The data was
stored on 12-inch video discs that were only readable by the BBC Micro, of
which only a handful still exist.  The time capsule contains "250,000 place
names, 25,000 maps, 50,000 pictures, 3,000 data sets and 60 minutes of
moving pictures.".  The article notes that the original Domesday Book
(compiled in 1086 for tax purposes) is still in "mint condition".
[Source: London *Metro*, 01 Mar 2002]

Additional comments of my own:

The BBC Micro, along with the original Sinclair Computers, was the computer
that sparked off the "computer revolution" in the UK. The BBC Micro was
especially popular in schools, whereas the Sinclair computers were more
popular in the home.

To be fair, the 1986 Domesday Project was in the days before the really
rapid changes in technology came into force - the BBC Micro was not a bad
choice of platform then, especially when you consider that there were very
few other choices available (50,000 pictures alone take up a lot of space).

Moral/Risk: If you are wanting long-term data storage, the format is just as
important as the materials.

This is not a new problem - It has appeared in Risks before (RISKS-21.56:
'NASA data from 1970s lost due to "forgotten" file format' for one...), but
is worth keeping in mind. I still have an old Commodore 64/128 disk with my
(very) old account details on it - not that I have a C64/128 any more.  My
permanent records, however, are the printouts.

PS: "Domed... We are all Doomed..."


RISKS to computers from society

<"Arthur J. Byrnes" <arthur@ajb.com>>
Sat, 23 Feb 2002 20:53:21 -0500

Reading the various articles about buffer overflow and WiFi security
problems, makes you think that Society has to worry about risks from
computers.

Then I have two incidents in one week that remind me that computers are the
ones at risk.

First a I get a misdirected plain-text e-mail from a major insurance company
with login IDs, passwords, and usage instructions, (that seemed to come
from one of those "Dummies" books).  As much as my curiosity wanted to try
them out, my ethics stopped me.  A note to the company got an auto reply, no
thanks, or inquiry about how/why I ended up with this seemingly important
e-mail.

Then later in the week I added a new Web site to my Microsoft Central
account.  The welcome plain-text e-mail contained my login name and password,
which is also my .Net login.  They made clients sign up for .Net in order to
continue using their service.  (I'm glad I don't use it for anything else!)

Two major companies that should have known better, put Society's computers
at Risk, with a practice that is unpardonable.  Never send login IDs and
passwords together...

Arthur J. Byrnes  http://www.ajb.com


Corporate Web sites leave cold steely feeling

<Dan Jacobson <jidanni@deadspam.com>>
28 Feb 2002 03:56:16 +0800

Now that I have traded my corporate life for "back to nature", every once in
a while there is a long term bond from my past life or something that is
about to expire, hence I must log on to some corporate site, wherein right
off the bat:

Browser Upgrade
   Thank you for visiting Jackson National Life Insurance Company's
   Web site. We have noticed you are using an earlier version of null.

Also, aren't those little lock symbols supposed to lock when asking for SS#,
passwd, etc.?

And don't you hate those Web sites that after filling in a long form, you
are to pick which of the 50 states you live in... I get stuck here.  I would
have used the toll free phone # but it is not toll free for me.

OK, now turning to the AT&T Universal card site... Ah, AT&T, equal
opportunity employer... OK, but still, cant use the Lynx browser... what if
I was vision impaired?  And, why after establishing that I am not spam,
cannot I have an e-mail conversation with these corporate giants about
compatibility issues with their Web sites without having to "login to
send/receive secure e-mail"... takes half of my modem session.

http://www.geocities.com/jidanni/ Taiwan(04)25854780


Tunneling too close to the person you're trying to protect: SafeWeb

<"David Martin" <dm@cs.bu.edu>>
Thu, 14 Feb 2002 16:50:52 -0500

A tunnel is the prototypical example of a security mechanism that doesn't
compose well: it creates an end-to-end connection that can bypass
intermediate scrutiny.  SafeWeb, the Web anonymizing service, fell into this
trap by attaching the browser end of its tunnel too closely to the user and
thereby bypassing meaningful browser protections.  The result is that users
of the service are at higher risk of some types of privacy attacks than
those who refrain from using the service.

Note that SafeWeb's anonymizing service was shut down in December for
business reasons.  However, its technology was licensed to In-Q-Tel (the
venture capital firm funded by the CIA) and PrivaSec LLC.  PrivaSec is
currently offering a public beta test of its service based on SafeWeb's
technology at its Web site http://www.privasec.com.  For simplicity, we'll
pretend the system is still running at safeweb.com in the rest of this
article.

First a quick SafeWeb overview: a SafeWeb user types in a URL.  It goes to
safeweb.com within an SSL connection; SafeWeb sanitizes the requested
content and delivers it back to the browser.  The origin server Web site
only sees a connection from safeweb.com, and eavesdroppers near the user
only see an encrypted connection to safeweb.com On-screen, SafeWeb uses
frames to separate the SafeWeb controls from the requested content.  Let's
call them the "control" and "content" frames.

Now let's meet the protections: (1) simultaneously open windows or frames
can only communicate with each other if they're from the same domain, (2)
scripts stop running when a new page is displayed, and (3) cookies are
available only to the domain that set them.

The problem is that both of SafeWeb's frames are served from the same tunnel
(https://www.safeweb.com/) even though their content comes from radically
different sources: the trusted SafeWeb site on the one hand, and the
untrusted third party site on the other.  Since both frames come from the
same domain, the Web browser exposes each Document Object Model to the
other: protection #1 is gone.

Since the control frame is basically static, it's a great place for an
attacker to tuck away any code that needs to persist throughout the browsing
session — like spyware.  So protection #2 is gone too.

SafeWeb also wanted to support pseudonymous persistent cookies.  Since the
content frame is always associated with a single privacy domain, they
aggregated all of the pseudonymous cookies from sites a user might visit
through SafeWeb into one "master cookie" associated with the fixed domain
safeweb.com.  That way, the individual cookies all get stored on the user's
computer in a slightly different form, and SafeWeb doesn't have to maintain
any persistent state on their servers (and users don't have to log in to
SafeWeb, etc.).  But this approach discards protection #3 as well.

To exploit these lost protections, an attacker has to take control of one of
the frames: the content frame is the obvious choice.  That turns out to be
not too hard.  SafeWeb *requires* that JavaScript be enabled in the browser.
Recognizing the risk, SafeWeb tried to sanitize scripts delivered to the
content frame, but they didn't go nearly far enough.  The result?  By
choosing to use this privacy enhancing system, users become vulnerable to
having their IP address revealed, *all* of their cookies stolen, and the
remainder of their privacy-"enhanced" browsing session silently transmitted
to an attacker in spite of the layer of SSL protection.  This is not
speculation; we have tested several effective exploits against the system.

Discarding protection mechanisms is only justified if those protections are
replaced by something stronger, or by something more valuable to the end
users.  SafeWeb's system did keep its users' identities out of routinely
gathered Web server logs.  But the cost was increased vulnerability to
targeted attacks, and it's hard to say whether the system's users would
consider this a good tradeoff.  There's no reason to think they would be
aware of the tradeoff at all.

Adding to the weirdness, we are told that this privacy enhancing service was
subjected to a "stringent" technological review by the CIA.

Details (24 pages, PDF) are available at
http://www.cs.bu.edu/techreports/pdf/2002-003-deanonymizing-safeweb.pdf.

In response to our observations, SafeWeb points out that their own service
is no longer in operation, that their new products didn't inherit these
problems, that the system was effective at resisting passive attacks, and
that the adversaries they had in mind wouldn't have been willing to use
attacks such as ours for fear of bad publicity.  They have also announced
that they are developing a fix for their licensees, In-Q-Tel and PrivaSec.

David Martin — dm@cs.bu.edu
Andrew Schulman — undoc@sonic.net


Privacy risk in Netscape 6

<Sim IJskes <sim@nyx.xs4all.nl>>
Thu, 21 Feb 2002 21:05:43 +0100

I just installed the Netscape browser version 6.2. I changed 'Internet
search' options so that Netscape performed searches through Google instead
of the Netscape search engine.

Some browsing in the files that were installed led me to this line:

action="http://info.netscape.com/fwd/lksidus_gg/http://www.google.com/search"

in a file "SBWeb_02.src". It looked as if Google directed search requests
are first sent to info.netscape.com. A quick look in the proxy server log on
the server confirmed my suspicion.

I guess that Netscape allows you to search other search engines than their
own, but still wants to know what you are searching....

P.S. a similar mechanism was also used in the 'SmartDownload manager'
some years ago, as i seem to remember (maybe still is).

Sim IJskes, Leiderdorp, The Netherlands      |   sim@nyx.xs4all.nl


Electronic Voting in Ireland

<"Peter Thornton" <Peter.Thornton@emr-radio.ie>>
Mon, 25 Feb 2002 14:48:22 -0000

Further to recent contributions on electronic voting, this is from the
Web site of the Irish department of the environment:
  http://www.environ.ie/press/electvote02.html
The "forthcoming general election" they refer to will be taking place in
the next three months. I note that they will be using "an industry
standard PC system". I presume that this means a Wintel box.

Green Light For Electronic Voting In Dublin North, Dublin West And Meath

Mr Noel Dempsey TD, Minister for the Environment and Local Government has
announced today (19 February) that the constituencies of Dublin North,
Dublin West and Meath have been chosen as the pilot constituencies for the
introduction of electronic voting.  "Subject to final testing of software,
my intention is that the voters in Dublin North, Dublin West and Meath will
be the first in the country to cast their ballots electronically. Thus, the
forthcoming General Election should usher in a new age of efficiency in the
voting process," said Minister Dempsey. "Electronic voting will dramatically
speed up the counting process with results for the constituencies likely to
be available within a half an hour of the final module, on which the cast
votes are stored, being delivered to the counting centres."

The electronic voting system to be used has been developed by the Dutch/UK
company, Nedap/Powervote. The Nedap/Powervote solution will provide a
'fullface' (large screen) machine which is successfully used in the
Netherlands and in the German cities of Cologne and Dusseldorf.  Election
preparation will be run from an industry-standard PC system and the
completion of the count will also be carried out on a standard PC and
programming unit.

In the run up to the introduction of electronic voting, there will be an
intensive public information campaign in the constituencies concerned to
ensure that all voters will be familiar with the new method of voting.

Peter Thornton, EMR Radio & Telemetry, Unit 11 Dunboyne Business Park
Dunboyne Co. Meath  Tel: +353-1-8013161


Re: Miami-Dade OKs touchscreen voting (Price/PGN, RISKS-21.90)

<Les Barstow <lbarstow@vr1.com>>
Thu, 21 Feb 2002 07:03:28 -0700

With physical access to voting machines and/or the software used to
control them, the only sure way to provide security is a paper record.

Especially with OpenSource software, it becomes possible to recompile
(and hence alter) any electronic-only record.  Closed Source software
isn't any better - it lacks public accountability and scrutiny.  Someone
could always create a new ROM, OS, or software image if given sufficient
knowledge, bypassing any security system that has been put in place.

So:  Print an OCR paper record when the voter finishes his vote.  He
gets to check the paper copy and put it in a standard secured voting
box.  The best parts are:

  (a) Since it's printed on demand, only the voter's candidate appears
      on the printout - the voter sees only who or what he voted for,
      or that he made no vote, and can easily check the paper before
      dropping it in the box.
  (b) Using OCR, independent auditing becomes easy.  The auditor needs
      little in the way of custom hardware or software to do the job;
      they only need to tweak their OCR readers.  Auditors could be
      chosen by mutual agreement of the candidates after the vote is
      completed (and only if a candidate determines he wants to have
      a recount), removing any temptation to bribe the auditing firm.

Les Barstow, System Administrator, VR1, Inc.
http://www.vr1.com  lbarstow@vr1.com

  [We've been talking about such schemes before here.  See Rebecca Mercuri's
  PhD thesis for a detailed analysis:
    http://www.notablesoftware.com/~evote
  noted in RISKS-21.10,13,14,61.  PGN]


Re: Miami-Dade OKs touchscreen voting (Brain, RISKS-21.92)

<Mark Nelson <mcnels1@h_o_t_m_a_i_l_._c_o_m>>
Fri, 22 Feb 2002 15:56:57 -0500

> The risks for vote-rigging on COTS systems [include]:

e) Someone tweaks the compiler of the compiler of the compiler of the...

See Ken Thompson's "Reflections on Trusting Trust"
  http://www.acm.org/classics/sep95/


Re: The homograph problem (RISKS-21.91 and 92)

<Partha <algolog@hd1.vsnl.net.in>>
Thu, 28 Feb 2002 19:16:12 +0530

I am a victim of one such problem. Our Indian bureaucrats in the Govt.
owned ISP called VSNL decided to create domain names using a mixture of
alphas and Arabic numerals. Resultant: I have an e-mail address containing a
"one". It is impossible to make out the "one" from "lower case L", and as
result of which I lose many many e-mails destined for me.  I have mitigated
the problem to a certain extent, by adding a descriptive note in my
signature box, but it is impossible to print such things on my visiting
cards.  Notice that there is also a "lower case L" in the second field of my
domain name "v-s-n-L". We (Indians) are perhaps the only ones in the world
to have such confusing combinations of alphas and numerals in their domain
names.

When will we ever learn?

PS: VSNL has now been "privatised". They changed the owners but they
kept the brilliant employees who created this mad domain name.

Dr. S. Parthasarathy, Algologic Research & Solutions, 78 Sancharpuri Colony,
Bowenpally, Secunderabad 500 011 - INDIA  Phone: + 91 - 40 - 775 1650


Re: Dangerous Characters (Lomas, RISKS-21.92)

<Dick Botting <rbotting@csusb.edu>>
Thu, 21 Feb 2002 13:41:31 -0800

This looks like the "sanitization" procedures for user supplied data that is
recommended for the Perl language.  Perl is used by many Webmeisters.
Typically, it has to call other programs and uses a "shell escape" to do so.
On UNIX boxes it does this in such a way that the shell interprets the
passed data as a command.  An apostrophe is a string delimiter and so a
stray blip can play havoc with string data...  A smart user can easily make
the server execute any command.  Hence User data is sanitized by removing
certain characters.

Another solution is to avoid Perl. Scripts written in Bourne/Korn/Born Again
SHell do not have this problem.  Care is still needed, but the removal of
the usual suspect characters is not necessary.


Re: Dangerous characters (Lomas, RISKS-21.92)

<Darrell Fuhriman <darrell@grumblesmurf.net>>
21 Feb 2002 13:49:09 -0800

I regularly have perfectly valid e-mail addresses rejected by Web forms
because they contain a '+' sign.  Most Web sites seem to assume that anything
not in the set [A-Za-z1-9_-] is invalid, even though the valid set defined
in RFC 2822 is much larger than that.

I wonder what's going to happen when, inevitably, e-mail addresses are
allowed to be in Unicode.  I fully suspect that we'll suddenly find a large
portion of the population unable to use their nifty new language appropriate
addresses.


Re: Dangerous characters (Lomas, RISKS-21.92)

<Bill McGonigle <mcgonigle@medicalmedia.com>>
Thu, 21 Feb 2002 11:46:48 -0500

Probably Waitrose is storing their orders in a SQL database.  In most SQL
statements, apostrophes need to be escaped, typically as '' (that's two
single quotes).  I've met so-called Web-site programmers to whom the notion
of an escape character suggests something out of a prison-break movie.
Often they notice a problem, with the database of course, when trying to
store text with an apostrophe, so they put some 'error checking' code in to
prevent those errors.


REVIEW: "Security Fundamentals for E-Commerce", Vesna Hassler

<Rob Slade <rslade@sprint.ca>>
Mon, 4 Mar 2002 07:44:27 -0800

BKSCFUEC.RVW   20020108

"Security Fundamentals for E-Commerce", Vesna Hassler, 2001,
1-58053-108-3, U$83.00
%A   Vesna Hassler hassler@infosys.tuwien.ac.at
%C   685 Canton St., Norwood, MA   02062
%D   2001
%G   1-58053-108-3
%I   Artech House/Horizon
%O   U$83.00 800-225-9977 fax: 617-769-6334 artech@artech-house.com
%P   409 p.
%T   "Security Fundamentals for E-Commerce"

"The purpose of this book is to give an in-depth overview of all the basic
security problems and solutions that can be relevant for an e-commerce
application."  I'm sorry, but "in-depth overview" sounds a bit like "jumbo
shrimp": it's an oxymoron.  And "all the basic security problems and
solutions that can be relevant for an e-commerce application" covers a lot
of ground.  (Which is, I suppose, why this text has twenty two chapters.)

Part one explains the basics of information security.  Chapter one defines
some of the basic jargon, but misses a number of the important fundamental
terms.  For example, the relationship between threats, vulnerabilities and
exploits is fairly basic to security and risk analysis, and yet all security
problems seem to be lumped together as threats.  The examination of security
mechanisms, in chapter two, is limited to cryptography.  Key management is
restricted to X.509 certificates and Diffie-Hellman in chapter three.

Part two looks specifically at security of electronic payment systems.
Chapter four briefly lists a wide variety of payment systems.  A terse set
of payment security problems is given in chapter five, while some seemingly
random cryptographic solutions are given in six.  A little bit of math for
functions directed at electronic cash and cheques is presented in chapters
seven and eight, respectively.  Chapter nine describes the Internet Open
Trading Protocol.

Part three deals with communications security.  Chapter ten is a general
look at networking.  Chapters eleven to fourteen examine different systems
for security at different layers, but the depth of coverage is very
inconsistent: extremely terse in some cases, with many gaps, and yet delving
into minute detail in others.

Part four examines Web security.  Chapter fifteen details the HyperText
Transfer Protocol (HTTP), which is good, since few texts bother to do.
Random topics related to Web servers make up chapter sixteen.  Web client
security topics are dealt with somewhat better in chapter seventeen,
although cookies aren't given any significant discussion.  Active content
does get its own chapter: eighteen concentrates almost exclusively on Java.
Chapter nineteen contains miscellaneous topics.

Part five covers some special issues for mobile or agent computing.  Agent
technology is described in chapter twenty, some cellular phone topics are
reviewed in twenty one, and smart card security is discussed in twenty two.

Well, overview it is.  The book does cover a variety of topics, although
there are a great many gaps and holes.  However, "in-depth" can't be
supported, except in a very few cases.  There are some topics that are
discussed in excruciating detail, but they are definitely in the minority.
As a college text this undoubtedly has its uses, but professionals or
businesspeople will find the inconsistent coverage problematic.

copyright Robert M. Slade, 2002   BKSCFUEC.RVW   20020108
rslade@vcn.bc.ca  rslade@sprint.ca  slade@victoria.tc.ca p1@canada.com
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade

Please report problems with the web pages to the maintainer

x
Top