Subject: RISKS DIGEST 17.46

Subject: RISKS DIGEST 17.46

RISKS-LIST: Risks-Forum Digest Monday 20 November 1995 Volume 17 : Issue 46

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

***** See last item for further information, disclaimers, etc. *****

Contents:
Village telephones cut due to "computer error" (Gordon Frank)
Software failure in credit-card system authentication (Adrian Howard)
Robotic justice? (George C. Kaplan)
Robotic justice hoax! (George C. Kaplan)
Software Pirate Nabbed in L.A. [Captain Blood] (Edupage)
AOL Alerts Users to "Trojan Horse" (Edupage)
A well-managed risk (Andrew Koenig)
The little math error (1 in 1000) (Paul Bissex)
Compendium of Commercial Fly-By-Wire Problems (Peter Ladkin)
X-31 crash follow up (Martin Gomez and Andy Fuller via Steven Weller)
Encryption vs. cryptanalysis difficulty scaling (Steve Witham)
Faster computers *will* make security safer! (Adam=aba)
Re: Writing solid code (Barton C. Massey, Peter da Silva, Roger E. Wolff)
ABRIDGED info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: Wed, 15 Nov 1995 15:59:43 +0200 (WET)
From: Gordon Frank <[email protected]>
Subject: Village telephones cut due to "computer error"

The following article was pointed out to me by one of my students,
Elpidoforos Economou (Source: Alitheia newspaper, Cyprus, 13 Nov 1995)

On Thursday 9 November a whole village (population 3000) had its telephones
disconnected for nonpayment of their bills. According to the newspaper
report, a "computer error" showing all subscribers in the village to be in
default was to blame. Reconnection took place when the problem was
discovered a few hours later.

------------------------------

Date: Thu, 16 Nov 1995 11:12:38 +0000 (GMT)
From: "Adrian Howard" <[email protected]>
Subject: Software failure in credit-card system authentication

[The following culled from a brief article in the Nov 4th Guardian (UK
broadsheet)]:

The UK's two largest credit authorisation systems (Barclay's PDQ and
NatWest's Streamline) failed on Saturday Oct 28th leaving retailers
unable to verify customers cards.

In Barclay's case more than 40% of transactions failed due to "a bug
in the system's software". For NatWest the problem was a huge
backlog of calls [reason unstated in article] which delayed card
authentication.

Both systems had contingency systems which allow retailers to
telephone in authentication requests. However, due to the volume of
sales, the lines rapidly became jammed.

Comments:

1) It looks like the phone based contingency system was setup with the
failure of small parts of the network in mind, rather than the failure of
the system as a whole. I wonder if this was an oversite, or a deliberate
cost/risk decision.

2) To me the most interesting comment was on the use of final resort manual
"zip-zap" machines used for recording card details. According to Barclay's
many retailers had forgotten how to process paper-based transactions! Over
reliance on tech strikes again (along with improper training).

Adrian [email protected] +44 (0)1273 678367
http://www.cogs.susx.ac.uk/users/adrianh/

------------------------------

Date: Mon, 13 Nov 1995 17:38:36 -0800
From: "George C. Kaplan" <[email protected]>
Subject: Robotic justice?

A jaw-dropping item in the "Legal Grounds" column by Reynolds Holding in the
13 Nov 1995 *San Francisco Chronicle*:

A group of researchers at New York University Law School have been working
on something called the "Solomon Project" to develop software to decide
legal cases without bothering with juries.

Quoting Holding:

- Attorneys enter all admissible evidence into Solomon under
the supervision of a judge. All the lawyers, clients, and
witnesses take lie-detector tests to make sure they're
telling the truth.

- When the facts are in dispute, Solomon participates in
depositions, listening to witnesses and judging their
credibility with -- yikes -- "voice stress analysis and
the inputs from polygraph telemetry."

- After asking a few questions, Solomon searches through
its massive library of laws, ethical rules and factual
precedents. Then it makes a decision and, if necessary,
issues an opinion and sentence.

Oh, and the decision can't be appealed.

Gee, where do I start? Are polygraph (so-called "lie-detector") results
admissible in court? How about voice-stress analysis? Can it be
fair to non-native English speakers? No appeals!?

A comment at the end of the column by trial consultant Karen Koonan
sums it up: "It's pretty scary."

George C. Kaplan [email protected] 1-510-643-5651

------------------------------

Date: Wed, 15 Nov 1995 08:44:42 -0800
From: "George C. Kaplan" <[email protected]>
Subject: Robotic justice hoax!

My earlier message reported an item in the "Legal Grounds" column in the
S.F. Chronicle about the "Solomon Project" from New York University Law
School. This is a grand and implausible scheme to decide legal cases by
computer without bothering with a jury.

A couple of calls to NYU revealed:

- Joseph Bonuso, supposedly the director of the project, is not listed
in any NYU directories.

- The Law School Dean's office states that the Solomon project is using
NYU's name, but has nothing to do with NYU, and "is being investigated."

Looks as if it's a hoax.

George C. Kaplan [email protected] 1-510-643-5651

------------------------------

Date: Fri, 17 Nov 1995 02:26:00 -0500 (EST)
From: Educom <[email protected]>
Subject: Software Pirate Nabbed in L.A. [Captain Blood] (Edupage, 16 Nov 1995)

A big-time software pirate was arrested in Los Angeles last week and charged
with two felony counts of fraud and trademark violations. Authorities
seized an estimated $1 million in illegally copied software, high-speed
duplicating equipment and $15,000 in cash. Thomas Nick Alefantes, who calls
himself "Captain Blood," allegedly sold his wares through advertising in
trade publications and a mail order business. (Wall Street Journal 15 Nov
95 B10)

------------------------------

Date: Fri, 17 Nov 1995 02:26:00 -0500 (EST)
From: Educom <[email protected]>
Subject: AOL Alerts Users to "Trojan Horse" (Edupage, 16 November 1995)

America Online issued a warning to its users about a destructive file
attached to an e-mail message that has been circulating through its service
and also over the Internet. The message itself is okay, but trying to run
an attached "Trojan Horse" file called AOLGold or "install.exe" could crash
a hard drive. (Atlanta Journal-Constitution 16 Nov 95 F7)

------------------------------

Date: Wed, 15 Nov 1995 10:43:18 EST
From: Andrew Koenig <[email protected]>
Subject: A well-managed risk

This note is intended as a break from the usual horror stories.

I just returned from Tokyo as a passenger on a non-stop flight from there to
Newark. Twelve hours in the air in a Boeing 747-400.

Along the way I got a look at the flight plan and chatted with one of the
flight crew about it. On this particular flight, we were filed with a
destination of Detroit and with Cleveland as our alternate (All airline
operations must state a primary and alternate airport; the alternate must be
forecast to have weather substantially better than what is nominally
required for landing. There must be enough fuel on board to fly to the
primary airport, do a missed approach there, fly to the alternate, and land
with 45 minutes of fuel still on board), with the intention of revising the
flight plan enroute to have a destination of Newark and an alternate of
Boston.

Why the revision? Because the fuel consumption estimates on which the
flight plan is based have 10% padding. On a 12-hour flight, that means an
extra 1.2 hours of fuel on board. That's a lot. So they plan to land in
Detroit, which is an hour or so closer than Newark. Then, when they're over
central Canada somewhere, they check again how much fuel they really have.
If it's what they expect, the 10% padding is now a much smaller amount and,
as expected, they have enough to continue to Newark. If, on the other hand,
they can't prove that nothing is wrong, then they have a safe place to land
with plenty of fuel on board.

I think that's a nice example of risk management and foresight.

Andrew Koenig [email protected]

------------------------------

Date: Mon, 13 Nov 1995 22:58:42 +0500
From: Paul Bissex <[email protected]>
Subject: The little math error (1 in 1000) (RISKS-17.44)

Glad to see mention of this -- but it's 2,000 *times* the current level of
tapping rather than 2,000% thereof (Freeh's "correction" notwithstanding).

------------------------------

Date: Sun, 12 Nov 1995 21:45:56 +0100
From: [email protected]
Subject: Compendium of Commercial Fly-By-Wire Problems

[The following message was inadvertently appended to RISKS-17.45, but
you may not have seen it if your mail reader truncates digests after the
normal digest terminator. Thus, it is replicated here, to make sure it
gets noted and properly indexed. Sorry, Peter. Perhaps this was a
serendipitous test to see if anyone reads RISKS to the end these days.
Just a few of our long-time contributors did remark on it. PGN]

There has been much recent discussion in RISKS of accidents and incidents
involving the commercial fly-by-wire aircraft, the Airbus
A319/320/321/330/340 series and the Boeing B777. I've collected the RISKS
discussions since September 1993, along with synopses and a little
commentary, in a hypertext compendium, entitled `Incidents and Accidents
with Fly-by-Wire Commercial Airplanes', accessible through my home page

http://www.techfak.uni-bielefeld.de/~ladkin/

I intend that more RISKS and other discussion will appear as time goes by.
Comments, additions and corrections welcome. If you have technical material
that really should be linked, please let me know.

Peter Ladkin

------------------------------

Date: Thu, 16 Nov 1995 17:42:09 -0800
From: [email protected] (Steven Weller)
Subject: X-31 crash follow up (Martin Gomez and Andy Fuller)

I forwarded the X-31 crash info to a friend (Martin Gomez
[email protected]) who copied me the following correspondence.
Steven Weller +1 415 390 9732 [email protected]

A friend forwarded your note on the X-31 crash, and it made me grind my
teeth a little, so I thought I'd reply directly to you.

I am a private pilot, and I design flight control software for a living.
Based on this experience, please allow me to disagree with a couple of
points you made. 1) "It is apparent to me that this crash is the result of
a bug in the flight control software and sensor hardware of the X-31
aircraft. The computer was unable to compensate for a loss of the airspeed
indicator."

That is a non-sequitur. A "bug" is not the same as a missing feature.
Microsoft Word 6.0 can't do my taxes for me, but that's not a bug. To me, a
bug is when the computer does something other than what the designer
intended. If the designer intended the computer to detect and compensate for
the loss of a sensor, then you're right, it was a bug. My understanding,
from talking to engineers on the X-31 project at Dryden, is that the flight
computer was NOT meant to detect such failures. It therefore acted
correctly, in the sense that it did what it was designed to do. Obviously,
it would have been nice if it could detect that the airspeed sensor had
failed, but it's inability to do that is not a "bug" as you suggest.

"(a reading of zero is pretty impossible while the aircraft is flying)"

That's certainly true, but I don't think that's what happened to the X-31.
First of all, this aircraft had a Kiel tube, not a pitot tube. No, I don't
know the difference either! Assuming they work under the same principle
(the measurement of dynamic pressure) then, like pitot tubes, they are
subject to the same two forms of icing: 1) the total pressure port gets
clogged, or 2) the static pressure port gets clogged. You may already know
all this, but ...

In case 1, the airspeed reading will not change as the airspeed changes.
The air in the pitot tube (or Kiel tube, presumably) gets trapped. As the
ALTITUDE changes, though, the static pressure will change, and the airspeed
reading will decrease as the altitude decreases. In case 2, the indication
will react correctly to changes in airspeed, but changes in altitude will
have an odd effect: going lower will cause the airspeed to read higher, and
vice-versa.

I heard that case 1 is what occurred to the X-31 that day. The pitot side
iced up at altitude, and as the aircraft descended to return to base, the
reading decreased, with the results you mentioned.

"We need to understand these differences before we use computers to take
over the job of a human."

That's true, too. I assume your article (I'm unaware of the context, since
it was forwarded) is a warning to software designers to be careful what they
assume, etc. You must realize, though, that "it was a software problem" is
the perennial cry of the hardware engineer who asked for the wrong software,
and got what he asked for.

This is the reason that my company hired a pilot to design flight control
software...I usually know what the computer "should" do. In most cases,
though, software designers have to assume the specs they are given are
valid, and take all failure modes into account. Is it a software problem
that the X-31 can't land vertically? Or that it carries less than one hour
of fuel? If a pilot crashes the remaining X-31 because he tried to land it
vertically, or to fly coast-to-coast, that's not a software problem, so
neither is failure to detect a sensor error.

Martin Gomez

[Guilty as charged. I agree with you, the X-31 crashed because of a
SYSTEM DESIGN error, not a software bug. It would have taken more than a
software change to prevent the loss of control.

I have some flight experience (1.5 hours solo before marriage and a house
changed financial priority) and I have spent a couple of years writing
flight navigation and autopilot software, as well as flight simulator
software. I believe that my private pilot training had a significant
impact on my ability to write autopilot code. I'm glad to hear that
companies are recognizing that pilots write better flight control software
(and this hopefully will extend to other disciplines, as well).

I didn't think through the complete implications of pitot tube icing
(although I did remember that often the effect of clogging the dynamic
pressure sensor is to cause airspeed indication to remain constant). It
is an interesting point that IAS would gradually decrease as the altitude
decreased. This would make for an interesting control problem. My copy
of the Private Pilot Manual (Jeppesen Sanderson, 1990) notes a third
possibility: If the pitot tube is blocked and its drain hole remains open,
the airspeed reading will drop to zero (usually gradually). This failure
mode may or may not be applicable to a Kiel tube.

The root problem remains: an instrument critical to the operation of the
aircraft can fail in a way that is not detected by the system. Clogged
airspeed indicators are a common problem, and they appear to cause
catastrophic failure of the X-31. I see a recurring problem of software
designers (and system designers) getting inadequate requirements
specifications.

The real point is that we are "pushing the envelope" in using computers to
control complex systems. When the systems are dynamic (like flight
control) they are difficult to specify and difficult to test. We learn
from our mistakes. Some mistakes have bigger consequences than others:
our X-31 pilot was pretty lucky! Presumably, the next spec for the X-31
flight control system will have a line that reads: "failure of the
airspeed indicator shall not cause loss of control of the aircraft", or
"failure of ANY sensor shall not cause loss of control of the aircraft"
(although I would NOT like to be on the team that had to test that latter
requirement!).

Andrew C. Fuller, E-Systems, ECI Div. Box 12248, St. Petersburg, FL 33733
(813)381-2000 x3194 [email protected] Fax:(813)381-3329

------------------------------

Date: Fri, 17 Nov 95 13:15:34 EST
From: [email protected] (Steve Witham)
Subject: Encryption vs. Cryptanalysis difficulty scaling

Re: Faster computers will never make security safer! (Re: Palme, 17.45)

If you ignore issues other than the encryption (& assume it's RSA, say), and
ignore what quantum computers might be able to do, then the difficulty of
encrypting goes up with something like the cube of the size of the key, but
the difficulty of cracking goes up with something like the exponential of
the size of the key.

That's the whole reason encryption can work. If cracking were only a
constant factor harder than encryption then the safety margin would never be
enough. It has to actually scale differently--and (with the qualifications
above) as far as we know it does.

The question of building encryption into all communications involves another
scaling issue though: the speed and cost of communications vs. processors.
For quite a while we've had 10Mbps ethernets while processors kept getting
faster. If this were to continue, pretty soon we'd all be happy to let the
processor spend a small part of its time encrypting all traffic. But if
communication speed/cost catches up again then we'll still be tempted to
send at least some things in the clear.

--Steve

------------------------------

Date: Thu, 16 Nov 95 12:04:01 GMT
From: [email protected]
Subject: Faster computers *will* make security safer! (Re: Palme, RISKS-17.45)

> The problem is that CPU time becomes less costly at the same ratio
> for the encrypter as for the encryption breaker.

This assumption is wrong.

Quite clearly an encryption algorithm that is as cheap to break as to
encrypt is worthless -- encryption systems are by definition designed
to be harder to break than to encrypt.

However Jacob was comparing *ratios*, and a less intuitive though
demonstrable fact is that while increasing CPU speeds helps both
encryptor and breaker, the performance boost helps the encryptor
*more* than the breaker. This is because the encrypt and break
functions are of different complexity.

For example the RSA public key cipher used for key exchange, when
small public exponents are used the encryption process is of O(n^2),
and decryption O(n^3), but the time to break is a function running in
super polynomial time involving factoring a product of two large
primes.

So, some estimates of time to break (factor RSA modulus using GNFS)
(extracted from a post Bruce Schneier's made on cypherpunks):

# of bits mips-years required to factor

1024 3*10^11
2048 3*10^20

And (real figures - PGP) encrypt and decrypt for the same key sizes
(100Mhz R4600 based Indy workstation ($5000 workstation)):

# of bits encrypt decrypt

1024 0.06 s 1.2 s
2048 0.11 s 7.7 s

So say for arguments sake that a particular encryption system was
using 1024 bit keys, and that CPU speed increased by 10 fold.

Now the encryptor could use 2048 bit keys in place of 1024 bit keys,
with the same (or slightly better) real time response.

The breaker however is faced with a 10^9 increase in MIPs-years
required to break, and only a 10 fold increase in CPU to speed the
attack. The breaker is 10^8 times worse off, and the encryptor is
marginally better off.

As CPU speeds increase, the code breaker loses.

Adam

------------------------------

Date: 13 Nov 1995 20:40:48 GMT
From: [email protected] (Barton C. Massey)
Subject: Re: Writing solid code (Beatty, RISKS 17.45)

In RISKS-17.45, Derek Lee Beatty comments about Microsoft Press's
_Writing_Solid_Code_, specifically its claim that. "assertions that check
for programming errors [...] can be removed from the shipped versions for
better performance." His comment is that this idea is "neither new nor so
entertaining to RISKS readers, but it's sound advice."

Ouch. Hopefully most RISKS readers reacted immediately to this statement.
[See the next two messages. PGN]

I'm fond of the saying that "When your program's internal state becomes
invalid, the *best* thing that can happen is that it crashes immediately."
Programmers make mistakes; failing an internal assertion will prevent a
mistake from propagating through a program execution and leading to
undetected severe execution errors. For example:

+ I'd rather have my bank's software crash than lose
track of all my money.
+ I'd rather have my hospital heart-rate monitor crash
than report that my heart is still beating when it has,
in fact, stopped.
+ I'd rather have my word-processor crash than silently
change my boss's name from "Bud" to "Bug" in my document.

In addition, failed assertions typically can cause a program to "crash
gracefully", yielding information useful in fixing the bug, and cleaning up
enough internal state to prevent major disasters: buffers can be flushed,
files can be closed, etc.

There are probably a few assertions which belong only in development code,
because they are so expensive to check that they make the product unusable.
In my experience, this is surely *not* the common case. If this is "the
Microsoft way," please choose an alternate route.

Bart Massey [email protected]

------------------------------

Date: 14 Nov 1995 22:47:50 GMT
From: [email protected] (Peter da Silva)
Subject: Re: Writing solid code (Beatty, RISKS 17.45)

Derek Lee Beatty's support of Microsoft's code development is amazingly
naive. Remove assertions that check for programming errors? Rigorous testing
can not prove a program bug free, and removing these tests just makes the
bug harder to find. The bug, when it finally manifests, may end up being
blamed on a completely separate product...

This is of course to Microsoft's advantage. It lets them make claims like
"there are no bugs in Microsoft products that the majority of users want
fixed"... like the way Microsoft Project for Windows crashes under NT 3.5,
or the way the POSIX subsystem in NT hangs unexpectedly...

(no, I haven't reported these to Microsoft. Why should I? They're not going
to fix it... we're going to have to upgrade to 3.51 just to get around this
bug, for all that Bill Gates claimed "A bug fix is the worst possible reason
to release an upgrade" or words to that effect).

Suns maze of patches might be tough to figure out, but at least they admit
they've got bugs and do their best to fix them. Bill Gates, ruler of the
free world, remains in his state of denial.

(on another tack, the Java interpreter runs with no security enabled, for
performance reasons. All the security is implemented in theorem provers
and other test mechanisms prior to execution. This is much like the old
Burroughs boxes, where the compiler guaranteed that no operation that
violated the security policy was generated. It's much easier to do that
than check the output of an untrusted compiler. I would much rather they
implemented strict runtime checks at the interpreter level at the cost of
some performance.)

Peter da Silva, Bailey Network Management, 1601 Industrial Boulevard,
Sugar Land, TX 77487-5013 +1 713 274 5180 (NIC: PJD2)

------------------------------

Date: Sat, 18 Nov 1995 17:56:01 +0100 (MET)
From: [email protected]
Subject: Re: Writing solid code (Beatty, RISKS 17.45)

So now the book and Dekek Lee Beatty go hand in hand giving bad advice.

Solid code keeps the checks for programming errors! You can never ever
guarantee that no programming errors are going to surface in a production
version. Keeping the code that checks for "programming errors" is going to
catch lots of errors earlier on.

Moreover it is going to catch errors that aren't programming errors.
Continuing with an inconsistent internal data representation is a bad idea.
Whatever the cause.

Off course you might remove some of the 'code to find bug xyz'. The internal
consistency checks (This pointer shouldn't be "NULL", this "switch" needs no
"default") should remain.

Roger

------------------------------

Date: 6 September 1995 (LAST-MODIFIED)
From: [email protected]
Subject: ABRIDGED info on RISKS (comp.risks)

The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks.
SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on
your system, if possible and convenient for you. BITNET folks may use a
LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. [...]
DIRECT REQUESTS to <[email protected]> (majordomo) with one-line,
SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:]
INFO [for further information]

CONTRIBUTIONS: to [email protected], with appropriate, substantive Subject:
line, otherwise they may be ignored. Must be relevant, sound, in good taste,
objective, cogent, coherent, concise, and nonrepetitious. Diversity is
welcome, but not personal attacks. [...]
ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
Relevant contributions may appear in the RISKS section of regular issues
of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.

RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks

RISKS ARCHIVES: "ftp unix.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>
cd risks<CR> or cwd risks<CR>, depending on your particular FTP. [...]
[Back issues are in the subdirectory corresponding to the volume number.]
Individual issues can be accessed using a URL of the form
http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]
ftp://unix.sri.com/risks [if your browser accepts URLs.]

------------------------------

End of RISKS-FORUM Digest 17.46
************************