The RISKS Digest
Volume 24 Issue 58

Thursday, 1st March 2007

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

USAF F-22A jets grounded by software glitch
PGN
Jeremy Epstein
Briz-M rocket booster explodes over Australia
Mark Luntzel via PGN
Software error reportedly contributed to sudden Dow-Jones drop
PGN
Don't compute and drive at the same time...
Paul Saffo via PGN
Risk of not knowing technology: jail
Ronald J Bottomly
The Risks of Updating 80 Year Old Equipment
Chuck Weinstock
Jim Geissman
RFID tracking
Paul Wallich
Putting the SSN genie back in the bottle?
Steve Summit
Re: DNS roots attacked
Robert Graves
R A Lichtensteiger
Joe St Sauver
Re: Crashing an in-flight entertainment system
PGN
Re: Amazing boilerplate in Fairfax County e-mail
Mark Brader
Disposable digital Cameras are truly digital
Jason Mechler
Carmakers copy and repeat error almost forever
Mark Brader
WOTE 2007 CfP
Josh Benaloh
REVIEW: "The Art of Software Security Assessment", Dowd et al.
Rob Slade
Info on RISKS (comp.risks)

USAF F-22A jets grounded by software glitch

<"Peter G. Neumann" <neumann@csl.sri.com>>
Mon, 26 Feb 2007 14:32:19 PST

  The F-22 continues to encounter bumps in its first air expeditionary force
  deployment to Okinawa. The 12 aircraft from Langley AFB, Va., spent an
  unscheduled week at Hickam AFB, Hawaii, after the leading four had to
  abort the trip's last leg.  As the Raptors reached the International Date
  Line, the navigation computers locked up, so the aircraft returned to
  Hickam until a software patch was readied.  "Apparently we had built an
  aircraft for the Western Hemisphere only," says a senior U.S. Air Force
  official.  When the F-22s arrived at Kadena AB, Okinawa, some Japanese
  citizens held a protest against the aircraft's noise.  [Source: Aviation
  Week & Space Technology, 26 Feb 2007, p.18; thanks to John Rushby and
  Martyn Thomas for that item.  PGN]

Gene Spafford noted another article:
http://www.dailytech.com/Lockheeds+F22+Raptor+Gets+Zapped+by+International+Date+Line/article6225.htm


USAF F-22A jets grounded by software glitch

<Jeremy Epstein <jepstein@webmethods.com>>
Fri, 23 Feb 2007 15:55:52 -0500

Navigational systems failed, planes forced to return to Hawaii [visually
having to follow their tankers to safety].  The problem turns out to be
software (no surprise there).  Fix created, "verified", installed, and
they're off again.

"A spokesman for Lockheed Martin this week insisted that the navigation
software problem was minor. 'The issue was quickly identified in a matter of
days and a fix installed in the airplanes, which were flown successfully to
Japan,' he said. 'There are 87 of these exceptional fighters and they are
out there performing exceptionally well, and their pilots continue to fly
them in new and greater ways.'"

Gee, I feel better knowing that.

http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9011691&source=NLT_PM&nlid=8

  [Long ago there was an urban legend about the F-16 flipping over and
  flying upside down when it crossed over the equator.  That report emerged
  because a consequential software flaw had actually been DETECTED in
  simulation, and had been FIXED before it could have happened in actual
  flights.  However, the F-22 Raptor was presumably unwrapped without the
  benefit of rapter simulation, testing, and other pre-flight analyses.
  This smacks of Alpha males doing Beta testing by risking their own Gamma
  globulin.  PGN]


Briz-M rocket booster explodes over Australia

<"Peter G. Neumann" <neumann@csl.sri.com>>
Thu, 22 Feb 2007 10:02:37 PST

> Date: February 21, 2007 9:32:24 AM PST
> From: SpaceWeather.com <swlist@spaceweather.com>
> Subject: Major Breakup Event over Australia
>
> Space Weather News for Feb. 21, 2007, http://spaceweather.com
>
> On February 19th, late-night sky watchers across Australia witnessed a
> bright explosion followed by a debris cloud that hung in the sky for
> nearly an hour.  At first a mystery, the source of the blast is now
> understood.  It was a Russian Briz-M rocket booster misplaced in orbit
> last year by the failed launch of an Arabsat communications satellite.
> The fuel tanks of the Briz-M ruptured on Feb. 19th, producing a vivid
> naked-eye display and more than 1000 pieces of debris.  Experts are
> calling this a "major breakup event," comparable to or even worse than
> last month's Chinese anti-sat test.  Visit http://spaceweather.com for
> more information and pictures of the Briz-M breakup.

  [Thanks for spotting this one to Mark Luntzel, who particularly noted
  the ambiguous concept of "misplaced in orbit".  PGN]


Software error reportedly contributed to sudden Dow-Jones drop

<"Peter G. Neumann" <neumann@csl.sri.com>>
Wed, 28 Feb 2007 11:37:15 PST

On 27 Feb 2007, the Chinese stock market experienced a 9% drop.  This
apparently inspired heavy selling on the New York Stock Exchange, with a
volume about twice normal.  At one time, the calculation of the Dow Jones
Industrial average was running about 70 minutes behind.  Recognizing some
sort of computer problem, DJ switched to a backup computer, which over a
period of about three minutes caught up — resulting in the posted average
dropping about 240 points in those three minutes.  This evidently led to
some further panic selling.  (At one point, the market was down 546 points,
although it later recovered to close down only 416.)  The cause of the
software problem is under investigation.  [Sources: Swiftness of Dow Drop
Due to Computers (The Associated Press), *The New York Times*, 27 Feb 2007;
A Glitch in the Financial Matrix: How Heavy Trade Volumes and a 70-Minute
Time Lag Wreaked Havoc Upon the New York Stock Exchange, Dan Arnall, ABC
News, 27 Feb 2007; starkly PGN-ed]


Don't compute and drive at the same time...

<"Peter G. Neumann" <neumann@csl.sri.com>>
Tue, 27 Feb 2007 12:02:23 PST

  [Many thanks to Paul Saffo for finding this item.  (He observed that this
  gives a new meaning to the concept of a "Windows crash"...  PGN]

A man who authorities say appeared to be driving while using his laptop
computer died Monday when his vehicle crossed into oncoming traffic and
collided with a Hummer.  After the crash, California Highway Patrol officers
found the victim's computer still running and plugged into the cigarette
lighter of his 1991 Honda Accord. ...  [Source: Man in fatal crash thought
to be using laptop, Associated Press, 26 Feb 2007]
http://www.latimes.com/news/local/la-me-laptop27feb27,0,6942169.story?coll=la-default-underdog


Risk of not knowing technology: jail

<"Ronald J Bottomly" <bottomly@erols.com>>
Thu, 22 Feb 2007 16:50:36 -0500

The AP recently ran a story about a substitute teacher who was convicted of
exposing students to pornography. Her contention that it was inadvertent
because she couldn't keep up with pop-ups seems plausible, but the equally
non-tech-savvy jury didn't buy it (despite the fact that the prosecution
never even made a reasonable case by checking for spyware).  What seems
particularly Kafka-esque is the potential 40-year sentence she faces.
http://www.courant.com/news/local/statewire/hc-14013002.apds.m0230.bc-ct--teacfeb14,0,7509985.story


The Risks of Updating 80 Year Old Equipment (Re: RISKS-24.29)

<Chuck Weinstock <weinstock@sei.cmu.edu>>
Sun, 25 Feb 2007 21:33:21 -0500

Although the system includes components built 80 years ago, the 25 May 2006
power outage on Amtrak's Northeast Corridor was caused by a youngster — a
four year old computer system.  According to *The New York Times*, 24 Feb
2007, a single command failed to execute on the evening of 23 May 2006, and
no one was alerted.  The computer system in question apparently reduced
power at the substation involved during maintenance and the failed command
was to restore the power levels to normal when maintenance was done.  The
result was a rush hour on May 25th that took down most of the Northeast
Corridor.

Interestingly the computer that failed was one of a pair designed to provide
redundancy.  The second computer was out of service at the time of the
failure.

It apparently is the case that reducing power during maintenance was
unnecessary.  When Amtrak asked an unidentified vendor why this was done,
they did not have a good explanation.  "After the blackout, the equipment
manufacturer decided that instead of fixing the system ... the whole
procedure should be eliminated..."

``In the old days, you had switches and gauges, and a glance would reveal
that one of them was out of position.'' said William Crosbie, the Amtrak's
vice president for operations.

[Edited down from the original article in *The New York Times*, 24 Feb 2007]
http://www.nytimes.com/2007/02/24/us/24amtrak.html


The Risks of Updating 80 Year Old Equipment (Re: RISKS-24.29)

<Jim Geissman <jgeissman@socal.rr.com>>
Fri, 23 Feb 2007 20:31:06 -0800

The key is in the Crosbie quote [last sentence in Chuck Weinstock's excerpt
above].  And not at all surprising — when you're not sure you understand a
technology, you tend to over-engineer and create objects that work forever.
When you think you understand, and are also trying to squeeze every penny
out of the objects, you cut corners (oops, I mean optimize by improving the
design), and then the system may fail wherever your understanding isn't
correct.


RFID tracking

<Paul Wallich <pw@panix.com>>
Wed, 21 Feb 2007 13:27:41 -0500

<http://www.sciencedaily.com/releases/2007/02/070201164742.htm>

Science Daily: An electronic accountability system developed at Oak Ridge
National Laboratory will result in savings of more than $2 million per year
at one federal facility alone and will ensure 100 percent accountability of
employees.

[... and so forth ...]

The article mentions the difficulties of making sure RFIDs at a classified
site don't serve as a conduit for leaking information, and claims (among
other things) safety benefits from knowing the locations of all employees
during an emergency (of some kind that miraculously manages not to knock out
any part of the tracking computers or their sensor network, or to damage
anyone's RFID).

As an inventory-control system, it quite possibly makes sense, with the
usual caveats. But one does wonder a little about the people-tracking side
of it and the possibilities for mischief if any of the reams of generated
data got into the wrong hands.

  [Also, RISKS readers should always be wary of claims of 100%
  infallibility.  PGN]


Putting the SSN genie back in the bottle?

<Steve Summit <scs@eskimo.com>>
Wed, 28 Feb 2007 22:52:58 -0500

There were several stories in the news today about a delay in implementing
new privacy-enhancing legislation in Texas.  All SSNs were to have been
stricken from publicly-accessible documents, including title records, deeds,
tax liens and birth and death records, but in response to complaints that
this work could not be completed in time, Attorney General Greg Abbott
issued a letter delaying the requirement by 60 days.  (See e.g.
http://www.weatherforddemocrat.com/homepage/local_story_059145859.html .)

On the one hand this is disappointing, because identity theft is bad, so
making SSN's less available is good.  But, on second thought, does it even
matter any more?

I get the impression that SSN's are so widely available (i.e., for just
about everyone in the U.S.) that trying to plug any one particular hole is
probably all but futile.  I found myself wondering (not for the first time)
what it would take to get U.S. commerce and society to properly separate the
tasks of identification and authentication.  Would federal legislation
mandating this separation be effective?  Would it be even remotely possible
to get passed?  And even if — somehow — it were passed, would it be hated,
because of the seeming "inconvenience" of having to remember and use secret
authenticators (as opposed to well-known public identifiers) when performing
transactions that required them?


Re: DNS roots attacked (RISKS-24.57)

<Robert Graves <rgraves@ozemail.com.au>>
Fri, 23 Feb 2007 23:12:29 +1100

> ... attacks lasted for hours but passed largely unnoticed by most computer
> users, a testament to the resiliency of the Internet.

I noticed.  I could access some local sites in Australia, but a number of
*major* sites such as Google.com.au were completely inaccessible for me.  I
would categorize the Internet as *Severely Damaged* at the time - but then I
am no expert.  Sadly, the thoughts that ran through my mind (and I'd guess a
number of those other *unnoticing* computer users) were a) why bother
complaining? and b) to whom to complain?  My ISP had no information on its
status page about any problems, and my ability to look at other potential
information sources was limited by the problem itself.  So, I turned the
computer off and went to bed.  I suspect those quoted "experts" have a
vested interest in downplaying the issue.

RISKS?  The very nature of the Internet seems to mitigate against "noticing"
issues such as this.  I just hope that the instabilities of the Internet are
resolved before it becomes too critical to our way of life.


Re: DNS roots attacked (RISKS-24.57)

<R A Lichtensteiger <rali@tifosi.com>>
Fri, 23 Feb 2007 16:51:27 -0500

<  [See RISKS-22.32 for the attacks that crippled 9 of the 13 root servers in
<  Oct 2002.  Perhaps the Internet is somewhat more robust now?  PGN]

Certainly the roots are.  f.root-servers.net is actually 34 geographically
dispersed nodes using IP anycast. The last numbers I have for the other
roots says i-root has 13 and j-root has 17 unique nodes.

It's harder to DDoS 34 machines than to do it to one.  And the effects will
be regionalized.  Depending on the distribution of the bots doig the
attacking, one or more nodes will be under greater load than others, so some
people will see worse response rates than others.

As the article you cite said, most folks didn't seem to notice the attack.
Redundancy is good for mitigating some risks (keeping this reponse on
charter! <g>).


Re: DNS roots attacked (RISKS-24.57)

<Joe St Sauver <joe@oregon.uoregon.edu>>
Wed, 21 Feb 2007 14:12:50 -0800

You mentioned the recent attack on the roots... unfortunately I don't think
there's much room to be cheery about the current state of security of the
DNS system... if you're interested, see "Port 53 Wars" from the recent
Internet2/ESNet Joint Techs session on "Security of the Domain Name System
and Thinking About DNSSEC," http://www.uoregon.edu/~joe/port53wars/ (PPT and
PDF formats provided)


Re: Crashing an in-flight entertainment system (Summit, RISKS-24.57)

<"Peter G. Neumann" <neumann@csl.sri.com>>
Wed, 21 Feb 2007 14:37:09 PST

[Hugh Thompson's blog continues with further discussion. PGN]
  http://blogs.csoonline.com/node/151

Submitted by Anonymous on Wed, 2007-02-21 11:25.

Er, Um, avionics software ain't that grand either, if you go by some
examples of Airbus software. An Airbus went off the end of a runway a
while back, and an investigation revealed:

 * A leetle bit of water froze in a brake cylinder.

 * The brake system software detected the problem, in the secondary brake
   system. So far so good. The software then:

 * Did its normal thing, disabled the PRIMARY brake system, the good one.

 * Put up a misleading error message on an out-of the way display page.

 * The pilot eventually noticed this error message, so he pressed a button
   to clear the message.

 * But he pressed the button for under 50 msec, so one flight control
   computer saw the press, but the other one didn't.

 * The computers noticed they disagreed, so one of them shut down.

 * The pilot noticed the shutdown, so he pressed a "master reset" button.

 * But as it turns out, the "master reset" button doesn't really, like,
   reset everything, but it tells you it did.

 * Therefore when they applied the brakes, only the secondary (frozen
   up) brakes were applied.

 * The pilots, used to this super double-redundant computer-controlled
   brake system, didn't even think to apply the brakes manually.

 * Plane went off end of runway, many $$$$$$$$ of damage.

That's just one example of AirBus software wonderfulness.


Re: Amazing boilerplate in Fairfax County e-mail (Goldberg, R-24.57)

<msb@vex.net (Mark Brader)>
Wed, 21 Feb 2007 16:21:05 -0500 (EST)

> Looks like the "cutting edge" is severing Fairfax from the Internet.
> Being offline would be bad enough, but bouncing e-mail?  For three or four
> days? Amazing.

Er, which county-level services is it that are so critical that if they're
unavailable via the Internet over a long weekend it's cause for words like
"hard-to-believe", "amazing", "anger", and "outrage"?

Mark Brader, Toronto, msb@vex.net


Disposable digital Cameras are truly digital (Re: R-24.52,54,56,57)

<Jason Mechler <jasonmechler@yahoo.com>>
Wed, 21 Feb 2007 11:52:49 -0600

To end recent debate about the existence of disposable digital cameras,
please see the following 2004 article in *Time* magazine.  An acquaintance
of mine bought one of these when they first came out and attempted to hack
so it could be reused.  A simple google search now pulls up instructions for
converting these phones to multi-use.

*Time* Article: http://www.time.com/time/gadget/20040825/
Single-to-Multi-Use Hacks: http://www.cexx.org/dakota/


Carmakers copy and repeat error almost forever (McIlroy, RISKS-24.57)

<msb@vex.net (Mark Brader)>
Wed, 21 Feb 2007 16:20:06 -0500 (EST)

 RISKS-16.3, 5 May 1994, contained an account of the shock of being locked

>> locked out automatically after closing the door on a stopped car with
>> the engine running ... The problem was reported for a Chevvy ...

No, it was reported for a Buick Century.  The same item mentioned a Chevy,
but *its* misfeature was to *unlock* doors automatically, perhaps posing a
theft risk.

Mark Brader, Toronto, msb@vex.net


WOTE 2007 CfP

<Josh Benaloh <benaloh@microsoft.com>>
Tue, 27 Feb 2007 17:24:51 -0800

Workshop on Trustworthy Elections (WOTE 2007),
University of Ottawa, Ottawa, CANADA, 20-21 Jun 2007
Call for Papers [due 9 Apr 2007]

Election technologies have been a major concern in recent years with
numerous questions raised about current methods.  The aim of the workshop is
to bring together researchers, policy makers, voting officials, and others
whose work relates to electronic voting systems to present, discuss, and
evaluate promising technologies and schemes to achieve high assurance of
accuracy and privacy in the casting and counting of votes.

Full CfP: http://research.microsoft.com/CONFERENCES/WOTE2007/

  [Josh is the program chair.  General chairs are David Chaum and Ron
  Rivest.  Past WOTE meetings have been very worthwhile.  This one is held
  in conjunction with the 7th Workshop on Privacy Enhancing Technologies,
  and organized by IAVoSS, the International Association for Voting Systems
  Sciences.  The emphasis is on cryptographic voting methods.  PGN]


REVIEW: "The Art of Software Security Assessment", Dowd et al.

<Rob Slade <rMslade@shaw.ca>>
Wed, 07 Feb 2007 13:39:41 -0800

 Mark Dowd/John McDonald/Justin Schuh

BKTAOSSA.RVW   20061214

"The Art of Software Security Assessment", Mark Dowd/John
McDonald/Justin Schuh, 2007, 0-321-44442-6, U$54.99/C$68.99
%A   Mark Dowd http://taossa.com/
%A   John McDonald
%A   Justin Schuh
%C   P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario  M3C 2T8
%D   2007
%G   0-321-44442-6
%I   Addison-Wesley Publishing Co.
%O   U$54.99/C$68.99 416-447-5101 fax: 416-443-0948 800-822-6339
%O  http://www.amazon.com/exec/obidos/ASIN/0321444426/robsladesinterne
  http://www.amazon.co.uk/exec/obidos/ASIN/0321444426/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/0321444426/robsladesin03-20
%O   Audience a- Tech 2 Writing 1 (see revfaq.htm for explanation)
%P   1174 p.
%T   "The Art of Software Security Assessment"

One of the important parts of a book proposal is a review of the
literature that might be related to your topic, and how your book
differs from the competition.  The preface states that, unlike other
software security texts, this one doesn't deal with security design
and defensive programming, but concentrates on how to find
vulnerabilities.  The authors obviously haven't done their homework:
there are a number of books that talk about finding weaknesses and
loopholes in software.  There are even books that specialize in
finding vulnerabilities in specific types of software, such as the
rather spotty "Database Hacker's Handbook" (cf. BKDBHKHB.RVW) and the
much superior "How to Break Web Software" by Andrews and Whittaker
(cf. BKHTBWSW.RVW).  And most of them seem to be, like this work,
directed at consultants, security professionals, developers, and
quality assurance people.

"The Art of Software Security Assessment" is somewhat distinctive in
being particularly directed to programmers.  Thus, readers from the
consulting, security, and quality assurance fields who do not have a
very strong programming background will probably find themselves at a
loss to navigate the maze of coding examples.

Part one is an introduction to software security assessment.  Chapter
one, on software vulnerability fundamentals, starts with a very
verbose definition of "vulnerability" that seems to boil down to the
idea that a vulnerability is something that someone can use against
you.  The authors also propose that problems be examined in terms of
design vulnerabilities (this is what some other software development
literature describes as flaws), implementation vulnerabilities (bugs),
and operational vulnerabilities.  (The latter seems to be related to
improper requirements specification, or simply use of a program in the
wrong situation.)  One section runs through the software development
life cycle (SDLC) noting the types of problems to be addressed in each
phase, but the material is much less useful than that in Gary McGraw's
"Software Security: Building Security In" (cf. BKSWSBSI.RVW).  A brief
overview of design review is found in chapter two, along with a larger
section of miscellaneous security technologies.  There is also a more-
than-usually helpful explanation of threat modeling using data flow
diagrams and attack trees.  Some of the material is idiosyncratic: the
description of "bait-and-switch" attacks seems to be confused with the
birthday attack against hash digests.  An unstructured collection of
content about vulnerabilities, more security technologies, and network
models makes up chapter three.  Chapter four titularly talks about the
application review process.  This medley of ideas about ways to check
code will give you some suggestions if you are starting the operation,
but there is little in the way of analysis of the recommendations.

Part two turns to software vulnerabilities.  Chapter five provides
very detailed information about the various types of buffer overflows,
although the explanations are not always clear unless you already
understand the concepts.  Important facts about the means of data
representation in the C programming language are listed in chapter
six, and the abstractions are applicable to other languages.  Chapter
seven suggests reviewing code in terms of function, such as separately
auditing variable use, procedure calls and returns, and memory
allocation.  Problems with common string-handling (and therefore text-
related) statements in C are discussed in chapter eight, along with
the significance of differential handling of not-quite-universal data
representations by various languages (this commonly results in
malformed data attacks).  Not quite in a separate part to themselves,
chapters nine through twelve provide internal details of the UNIX and
Windows privilege and permission functions, as well as process
handling.  Chapter thirteen deals with process state information,
primarily concerning various race conditions.  Unfortunately, the
outlines given are not as helpful as they could be, due to a reliance
on code examples at the expense of explanations.  The authors would do
well to emulate the style adopted by Diomidis Spinellis in "Code
Quality: The Open Source Perspective" (cf. BKCQTOSP.RVW) who also
stresses the auditing of source code, but provides extensive textual
background as well.

Part three looks at software vulnerabilities in practice, although limited
to network operations.  Chapter fourteen provides details of many of the
basic Internet protocols, noting checks that should be made for dangerous
conditions.  The discussion of firewalls, in chapter fifteen, has oddly
little material on application-level proxies (and only tangential mention of
circuit-level proxies), concentrating on the examination of packet headers.
Miscellaneous attacks, with no readily evident theme, are listed in chapter
sixteen.  Chapter seventeen details HTTP (HyperText Transfer Protocol) and
other Web technologies, catalogues some attacks, and gives a brief set of
vulnerability checking guidelines.  Various vulnerabilities in Web scripting
and programming languages are noted in chapter eighteen.

There is a great deal of valuable information within this volume.  However,
there isn't sufficient explanatory content for the work to stand as a primer
for beginners, and the lack of structure reduces the utility as a
professional reference.  The reliance on code examples is reasonable for a
work aimed at programmers, but it does limit the audience to that group.  In
addition, the practical parts of the book, in particular, greatly emphasize
Web applications.  As it stands, this work has much of value to Web
developers and Web software testers, but it could have had much broader
application with minor improvements.

copyright Robert M. Slade, 2006   BKTAOSSA.RVW   20061214
rslade@vcn.bc.ca     slade@victoria.tc.ca     rslade@computercrime.org
http://victoria.tc.ca/techrev/rms.htm

Please report problems with the web pages to the maintainer

x
Top