precedence: bulk
Subject: RISKS DIGEST 19.50

RISKS-LIST: Risks-Forum Digest  Sunday 14 December 1997  Volume 19 : Issue 50

  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, caveats, etc. *****

 Contents:
Programmable defibrillator bug (Steve Bellovin)
Vandal posts ransom note on Yahoo (Edupage)
Computerized test failure (Steve Bellovin)
Insanely insulting spelling checker (Martin Bonner)
On Weak RSA-keys produced from Pretty Good Privacy (Jean-Jacques Quisquater)
Retraction on weak RSA-keys produced from PGP (Jean-Jacques Quisquater)
Computer crash impacts Washington DC Metro (Epstein Family)
Risks of new Motorola system (Matthew Healy)
Re: Potential software nightmare for ISS [name withheld]
Mars Pathfinder priority inversion (Bob Rahe)
Automated translation from AltaVista (Seth David Schoen)
Re: Beware of HTML Mail (Martin Minow)
Software Fault Injection (Gary McGraw)
7th USENIX Security Symposium - Conference Program (Jackson Dodd)
Abridged info on RISKS (comp.risks)

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

Date: Wed, 10 Dec 1997 11:20:32 -0500
From: Steve Bellovin <[email protected]>
Subject: Programmable defibrillator bug

The AP reports that a particular brand of implantable defibrillator has a
programming bug -- it can cause the patient's heart to race.  A fix has been
developed, and doctors will be able to use a small radio transmitter to load
in the new code.  Of course, that raises other issues, such as how the code
is authenticated, how well a more distant transmitter can load new code into
someone else's body, etc....

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

Date:   Thu, 11 Dec 1997 11:42:52 -0500
From: Edupage Editors <[email protected]>
Subject: Vandal posts ransom note on Yahoo

A network vandal broke into the Yahoo Web site for several minutes Monday
night to post a note instructing the government to release the prisoner
Kevin Mitnick, who is serving time for having used phones and computers to
break into corporate, government and university computer systems.  Although
the vandal claimed to have implanted a "logic bomb/worm" on the Yahoo site,
no virus was found, and the security breach was discovered and patched
immediately.  [*The New York Times* Cybertimes, 7 Dec 1997; Edupage, 11 Dec
1997]

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

Date: Thu, 11 Dec 1997 18:30:35 -0500
From: Steve Bellovin <[email protected]>
Subject: Computerized test failure

The Graduate Management Admission Test (GMAT) is now entirely computerized
-- candidates take it via an interactive system.  The trouble is, on
Thursday it broke -- "The screens would freeze, the tests wouldn't launch or
start".  The organization that administers that test is trying to expand its
hours so that people can reschedule.

The AP article did note that the computerized system does allow for much
more flexibility in scheduling, and that the paper-based system has its own
outage potentials -- sites have been closed by fires and by the noise from
marching bands at football games...

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

Date: Thu, 11 Dec 1997 09:30:11 -0000
From: Martin Bonner <[email protected]>
Subject: Insanely insulting spelling checker

No, this is not another "<name> becomes <rude-word>" stories...

Cambridge City Council (in England) wrote to a number of residents.
Being careful people, they spell-checked the letter before sending it.
The problem was that the spell checker couldn't see anything wrong with
a letter that began "Dear Sir or Madman...".

The RISKS?  Assuming that once a computer has checked it, it must be OK.

(Reported in Cambridge Evening News, 10th December 1997).
(Note for non-native English speakers, the conventional start to such a
letter would be "Dear Sir or Madam...")

Martin Bonner, Pi Technology Ltd, Milton Hall, Church Lane, Milton,
Cambridge, CB4 6AB  +44 (0)1223 203894  [email protected]

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

Date: Wed, 10 Dec 1997 08:31:46 +0100
From: jjq <[email protected]>
Subject: On Weak RSA-keys produced from Pretty Good Privacy

is the title of a paper presented at ICICS '97 (Beijing, Nov. 11-14, 1997)
by Y. Sakai, K. Sakurai and I. Ishizuka, pp. 314-324, LNCS 1334,
Springer-Verlag.  (Don't forget to read the paper just before this one :-).

>From the abstract:
"... Our obtained results show that bad primes are generated in PGP and
induced weak keys can be easily breakable via P + 1 factoring method.
For instance, in the case of RSA-key with 512-bit, we could attack
1. 0.3% users' systems with only 15 hours single PC-computations
  (very weak keys!!),
2. 2% users' systems with 50 days single PC-computations (weak keys?)."

Notice that they only claim a possible problem for key length around 512 bits.

I'm sure that many other commercial implementations have such similar
deficiencies.

My questions:

1. Any public evaluation of this paper? Other estimations?. This paper
  was accepted at a good conference (good panel of cryptographers,
  not a proof :-) and there was no comment (contradiction) after the
  talk. It seems they are some controversy about that results. Where?
  I think it is very good for any product to be submitted to
  public scrutiny especially if we are speaking about our (your) privacy.

2. Why do we trust some systems and implementations?
  And how to improve our methodology of tests?
  And how to convince somebody that indeed we used a good
  generation method for our keys.
  In the case of encryption there is really a general problem.
  You want I use YOUR (maybe insecure) public key for encrypting MY
  private message: please convince me FIRST you did correctly the key
  generation. Any convincing solution?

Jean-Jacques Quisquater, http://www.dice.ucl.ac.be/crypto

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

Date: Sun, 14 Dec 1997 16:01:18 +0100
From: jjq <[email protected]>
Subject: Retraction on weak RSA-keys produced from PGP

The main result of this paper is not correct at all!
See the retraction of the main author in sci.crypt.research.

A correct estimate is given by Bob Silverman in a report
accessible at RSA Labs (www.rsa.com/rsalabs):
"The requirement for strong primes in RSA encryption" (May 1997).
Very interesting paper (see the remarks about the EMV generation).

In few words, the table p.4 means:

- suppose one million of users choose a RSA key of 512 bits
 (two factors of 256 bits, chosen randomly) then, if each user
 is using 50.000 hours of serial computation (not fully precise what
 Bob means by hours) for breaking his own key using the (P-1)
 algorithm, ONLY one key will be likely broken.

- suppose one billion of users (China!) choose a RSA key by the
 same method, then, using 500 hours of serial computation for each
 key,   ONLY 7 keys will be likely broken.

It is implicit from these results that it is correct to use more than
2 factors for RSA if modulus with more than 512 bits are used:

- suppose one million of users choose a RSA key of 512 bits with 3
 factors then, using 50.000 hours for each key, around 1000 keys
 will be likely broken (using the Canfield, Erdos, Pomerance
 approximation for the number of smooth numbers) ;

- BUT suppose one million of users choose a RSA key of 1024 bits with
 4 factors then, using 50.000 hours of computation for each key, no
 key at all will be likely broken.

Let us remark that this computing power will be better used to factorize
some chosen modulus (here the results are randomly obtained): however
you need cooperation between the users.

In fact, it is possible to imagine a new LOTTERY (no needed cooperation
between users: maybe a new idea of challenge for RSA, inc :-)
- publish many modulus to factorize with a given level of security;
- the users choose randomly the modulus they want to factorize, using
 some algorithm;
- after a given time, the winners are given by the first factorizations.

Jean-Jacques Quisquater,
http://www.dice.ucl.ac.be/crypto

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

Date: Sat, 13 Dec 1997 13:48:57 -0500
From: Epstein Family <[email protected]>
Subject: Computer crash impacts Washington DC Metro

According to the 17 Dec 1997 *Washington Post*, a computer failure caused
20-minute delays on Metro's Red Line.  It goes on to say "The problem
occurred when workers in Metro's downtown central control room tried to add
an accessory to the main computer that monitors trains' positions.  The
computer crashed and came back on line only when the accessory was detached,
Metro officials said."  No indication what the "accessory" was or why it
caused a crash.

There was no indication that there were any safety-related issues associated
with the computer failure.

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

Date: Thu, 11 Dec 1997 14:17:02 -0500
From: [email protected] (Matthew D. Healy)
Subject: Risks of new Motorola system

Front page of {USA Today} for Wed, 10 December 1997:

Pager Lets You Locate Your Car, Unlock And Start It

According to the story, Motorola has a new system that can use paging
systems to:

  o unlock a car for somebody who locked their keys in the car
  o locate a car in a large parking lot
  o remotely disable a car so it cannot be started

According to the story, finance companies are especially keen on the idea --
they'd be able to disable the cars of customers who fail to make their loan
payments.

I don't think I need spell out the potential problems for RISKS readers.
I've had enough fun over the years convincing this or that creditor that
their records were in error; having my car disabled while I was fighting
their collection department could really be lots of fun...

[email protected]           http://ycmi.med.yale.edu/~healy/

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

Date: Wed, 10 Dec 1997 14:14:23 -0800 (PST)
From: [identity withheld by request]
Subject: Re: Potential software nightmare for ISS (Gross, RISKS-19.49)

This is a note on Philip Gross' well-justified concern over the
International Space Station software. The *Aviation Week* article he cites
concludes with a telling quote: "'Most people would not have given us a
snowball's chance in Hell to finally pull this thing off, but now we are
actually headed toward the pad to launch it,' [Randy] Brinkley [NASA's ISS
program manager] said."

This strikes me as reminiscent of the narrow definition of "success" that
preceded the Challenger explosion. As Richard Feynman stated, NASA was
playing " ... a kind of Russian roulette .... [The shuttle] flies [with
O-ring erosion] and nothing happens. Then it is suggested, therefore, that
the risk is no longer so high for the next flights." Feynman was stunned by
NASA's ability to take a nonlinear event -- the erosion of a material by a
hot gas -- and translate it into binary terms, into a "linear rule of
thumb," as James Gleick put it in his text on Feynman, GENIUS.

The point here is that "going to the launch pad" is not equal to success,
because getting the asset on orbit is not the end.  Structural integrity
cannot overcome weakness in 3.5M LOC, especially when that much code means
that the astronauts themselves are there to do experiments, not to "fly" the
ISS. We are watching the establishment of an autonomous unit in space with
the humans serving as back-up to the back-up to the back-up.  Structural
integrity AND bad code is equal to disaster.

I would concur with Peter Gross' concern that a few months of testing is not
enough, that NASA is testing its material far more than its code -- which is
surprising considering the rigor that NASA's contractor brings to its
shuttle software: each of the last three releases (each 420K LOC) had one
(1) error each, with the last eleven releases having a total of 17 errors. I
wonder if the 3.5M LOC for the ISS will have a handful of errors in its
releases?

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

Date: Wed, 10 Dec 1997 10:30:01 EST
From: [email protected] (Bob Rahe)
Subject: Mars Pathfinder priority inversion (Jones, RISKS-19.49)

In RISKS-19.49, Mike Jones <[email protected]> writes a fascinating account
of "What really happened on Mars Rover Pathfinder".  It's just that kind of
behind-the-scenes articles that make RISKS so great.  But, near the end he
talks about the 3 authors from CMU who had written a paper in 1990 that he
says had first identified the priority inversion problem and proposed a
solution.

Not to take anything from those authors but that exact type of problem was
addressed in at least one mainframe operating system way back in the early
1970s.  The Burroughs MCP (Master Control Program) that ran (and still runs
as the Unisys A-Series MCP) their mainframe systems, had a locking scheme
that could produce exactly that kind of problem.  A lock procured by a
low-priority task which then get's pre-empted by a medium- priority task,
could lock out a high priority task.  Their solution at the time (and still
is the last time I looked) was to bump the priority of any task procuring a
global system lock such as the one mentioned in the article.  Simply, if
priorities ran from 0 (low) to 99 (high), procuring a lock under their
algorithm would add 100 to the priority of the locking program.  When the
lock was released the priority would be dropped back by the same amount.

While not as elegant a solution, in my opinion, it certainly was adequate
for the problem given that these were not 'real-time' systems, and was
certainly an enduring solution.

Another example of there apparently being nothing new in software as well as
under the sun?

Bob Rahe, Delaware Tech&Comm Coll., Computer Center, Dover, Delaware
Internet: [email protected]

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

Date: Thu, 11 Dec 1997 20:59:48 -0800
From: Seth David Schoen <[email protected]>
Subject: Automated translation from AltaVista

DEC's AltaVista has integrated a very impressive automated translation
system with their search engine.  You'll be given the option to translate
pages when you search with AltaVista.

I tried translating documents from English to Spanish and back, and several
similar experiments.  Amazingly, although the grammar comes out very poorly,
the sense of the documents is almost always intelligible.

The risk is presented in AltaVista's own press release: "As this technology
matures, it may become unnecessary to offer Web sites in multiple languages."
(http://www.altavista.digital.com/av/content/pr120997.htm).  So risks lie in:

(1) Trusting machine translation as reliable and for more than it's worth
-- as an adequate means of reaching intended audiences.  One can accidentally
lose substantial and significant shades of meaning.  (Try "web site" from
English to Portugese to English; you get "leather-strap place".)

(2) Marginalizing less-common languages.  Many web sites of international
organizations are presently given in some uncommon languages; if they
decide that this translation service or a successor is "adequate", they
may drop support of smaller languages AltaVista won't translate for them.

  Seth David Schoen L&S '01 (undeclared) / [email protected]

[NOTE ADDED LATER:
Try "http://babelfish.altavista.digital.com/cgi-bin/translate?" directly
(rather than clicking the "Translate" link from a web page they've found).
It was configured slightly differently when I first tried it, so I wasn't
sure how the URL was going to turn out.]

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

Date: Tue, 9 Dec 1997 15:26:54 -0800
From: Martin Minow <[email protected]>
Subject: Re: Beware of HTML Mail (Brazil, RISKS-19.49)

Another interesting "risk" in the applet spam described by Tom Brazil
is the way the applet was configured:
>> <applet code=XXX codebase=YYY name=ZZZ width=2 height=2>
This tells the Java interpreter to run the applet in a 2x2 pixel screen
area, which will be easy for the viewer to miss. So the applet can do it's
thing while the viewer reads the rest of the display (presumably in HTML).

It might prove interesting to use a Java decompiler to determine precisely
what this applet actually does, and whether it calls any classes that are
not protected by the Java security "sandbox."  Sun's 100% pure test program
can be downloaded from their website for a first-pass check.

Martin Minow    [email protected]

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

Date: Wed, 10 Dec 1997 08:21:12 -0500 (EST)
From: Gary McGraw <[email protected]>
Subject: Software Fault Injection

We are pleased to announce the publication of a new software engineering
book:

   Software Fault Injection: Inoculating Programs Against Errors
   by Jeff Voas and Gary McGraw (Reliable Software Technologies)
            ISBN: 0-471-18381-4, John Wiley & Sons, 1997

Fault injection is a useful tool in developing high quality, reliable
code.  Its ability to reveal how software systems behave under
experimentally controlled anomalous circumstances makes it an ideal
crystal ball for predicting how badly good software can behave.  This
complete, how-to guide to a revolutionary new approach to software
analysis gets developers, programmers, and managers up to speed on
cutting-edge fault injection techniques. Fault injection is useful in
multiple domains including:

o Testing     - predicting where faults are most likely to hide
o Safety      - simulating failures in real software environments and
               estimating worst-case scenarios
o Law         - predicting the level of liability incurred by a piece of code
o Security    - uncovering potential security vulnerabilities during the
               development cycle
o Reuse       - obtaining a more accurate read on crucial maintenance and
               reuse issues
o Engineering - seamlessly introducing fault-injection into your
               software process

For more information, see <http://www.rstcorp.com/fault-injection.html>.

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

Date: Thu, 11 Dec 1997 18:01:53 GMT
From: [email protected] (Jackson Dodd)
Subject: 7th USENIX Security Symposium - Conference Program

7th USENIX Security Symposium
January 26-29, 1998
San Antonio, Texas

Sponsored by USENIX, the Advanced Computing Systems Association
In cooperation with the CERT Coordination Center

For more information about this event, visit the Security Symposium
Website:  http://www.usenix.org/events/sec98/

=======================================================
Early registration discount deadline:  January 5, 1998
=======================================================

Are you responsible for your company's security?  Are you looking
for real-world implementations for security issues?  If you are,
plan to attend the 7th USENIX Security Symposium January 26-29 in
San Antonio.

You can learn about the newest tools in tutorials, hear the latest solutions
offered by researchers, meet and talk with some of the leading lights in the
security community, and share problems and solutions with your peers.
Speakers include Bill Cheswick, Carl Ellison, Dan Geer, Arjen Lenstra,
Alfred Menezes, Clifford Neuman, JoAnn Perry, Marcus Ranum, Jon Rochlis, Avi
Rubin, Shabbir Safdar, Bruce Schneier.

Be sure to sign up for tutorials early--they often fill up fast.  Topics
include:

* Java, NT, and Web Security
* Cryptography
* Certification
* How to Handle Incidents
* What Every Hacker Already Knows

USENIX is the Advanced Computing Systems Association.  Its members are the
computer technologists responsible for many of the innovations in computing
we enjoy today.  To find out more about USENIX, visit its web site:
http://www.usenix.org.

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

Date: 1 Apr 1997 (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)
if possible and convenient for you.  Or use Bitnet LISTSERV.  Alternatively,
(via majordomo) DIRECT REQUESTS to <[email protected]> with one-line,
  SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or
  INFO     [for unabridged version of RISKS information]
=> The INFO file (submissions, default disclaimers, archive sites, .mil/.uk
subscribers, copyright policy, PRIVACY digests, etc.) is also obtainable from
http://www.CSL.sri.com/risksinfo.html  ftp://www.CSL.sri.com/pub/risks.info
The full info file will appear now and then in future issues.  *** All
contributors are assumed to have read the full info file for guidelines. ***
=> SUBMISSIONS: to [email protected] with meaningful SUBJECT: line.
=> ARCHIVES are available: ftp://ftp.sri.com/risks or
ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks
  [volume-summary issues are in risks-*.00]
  [back volumes have their own subdirectories, e.g., "cd 18" for volume 18]
or http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., VoLume, ISsue].
The ftp.sri.com site risks directory also contains the most recent
PostScript copy of PGN's comprehensive historical summary of one liners:
  get illustrative.PS

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

End of RISKS-FORUM Digest 19.50
************************

You are viewing proxied material from gopher.quux.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.