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 19 Issue 15

Thursday 15 May 1997

Contents

o Pentium II math flaw
John Sheehy
o Re: Time-Bomb Ticks In No-Name Pentium...
Henry G. Baker
Joan L Brewer
o Re: US Navy response to USS Vincennes airliner shootdown
Jonathan Thornburg
o Re: Power system loss, despite multiple redundancy
Ray Todd Stevens
o Re: No more fingers in the dike: big flood gates
Nick Brown
Amos Shapir
o Re: Swedish Phreaker
Kurt Fredriksson
o ACM lacks $50
Bertrand Meyer
o Signature scam?
John Elsbury
o Dialing someone who became `road kill' on the Information Superhighway
Paul Robinson
o RISKS of subscribing yourself to an e-mail database service
Steve Andre'
o Choosing and protecting your password: NOT!
Mike Wilson
o Re: Year 2069 problem
Hallam-Baker
o Workshop on safety-critical systems standards
Victoria Stavridou
o FMICS2 Programme and Call for Participation
Diego Latella
o RiskWorld
Mary Bryant
o Info on RISKS (comp.risks)

Pentium II math flaw: excerpted message

John Sheehy <jes@grove.ufl.edu>
Sun, 11 May 1997 18:26:43 -0400 (EDT)
  [The full text of the cited message on the Pentium II bug is at
  http://www.x86.org/secrets/Dan0411.html (PGN Excerpting Service).]

It would appear that there may be a bug in the floating-point unit of the
new Pentium II Processor, as well as the current Pentium Pro Processor. Is
it real? Is it serious? It appears to be real. The observed behavior
contradicts the IEEE Floating Point Specifications, and Intel's printed
documentation. However, I'm not a numerical analyst, and therefore I'm not
qualified to comment on its seriousness or its implications. Instead, I'll
present the facts herein, and leave the determination to you.

The Facts

I received e-mail from "Dan" who asked if I could reproduce what he thought
was a bug in the Pentium Pro processor. I wrote an assembly language program
that checked into the problem. I also ran the test on a Pentium-II processor
that I had recently bought at Fry's Electronics, an Intel Pentium Processor
(P54C), Intel Pentium Processor with MMX Technology (P55C), and an AMD K6.
Sure enough, I came to the same conclusion as Dan: it looks like a bug to
me.

  [John's entire note is Recommended Reading for RISKS Readers (R&R?).  The
  rest of his note is omitted here.  Approximately 140,739,635,839,000
  floating-point numbers are affected.  The Pentium, Pentium with MMX
  Technology, and AMD K6 microprocessors do not appear to have this
  problem.  PGN]


Re: Time-Bomb Ticks In No-Name Pentium... (Kabay, RISKS-19.13)

Henry G. Baker <hbaker@netcom.com>
Sat, 10 May 1997 10:43:03 -0700 (PDT)
> By Alexander Wolfe, EETimes (Via PointCast News and TechWeb, 28 Apr 1997)

I have no doubt that there are bad no-name motherboards out there, but these
kinds of articles are usually the result of clever marketing by someone who
makes 'name' motherboards and wants to spread a little
Fear-Uncertainty-Doubt (FUD).  The idea is to find a single defective
product, and then get someone in the media to make a mountain out of a
molehill.

Such articles usually indicate more that the 'name' motherboard people are
starting to hurt financially, rather than that there are huge numbers of bad
products out there.

I hate to sound so cynical, but you have to ask yourself every time you see
an article like this who stands to gain from it.  The recent FUD fights over
which kind of cellphone harms people the most show how gullible the press
really is.

Henry Baker  ftp://ftp.netcom.com/pub/hb/hbaker/home.html


Re: Time-Bomb Ticks In No-Name Pentium... (Kabay, RISKS-19.13)

Redmond Rose~ <rosarium@nwlink.com>
Mon, 12 May 1997 16:54:05 -0700
This is not a new issue.  Anyone who knows hardware knows that "ripple" on
power supplies are coming dangerously close to the actual clock cycles on
these CPUs.  We are going into an area of instability that is just a matter
of materials.  All semiconductor have this "ripple" element. It's kind of
like when the electrons hit that material, at first they "bounce" around and
create this short and tinny spike in the voltage wave. It's a very well
known electronic effect.  I'm surprised that we are only NOW beginning to
discuss the limitations.

Power supplies always start out as AC. We have to make them DC which is no
easy issue. We use semiconductor to do this and they all have that aspect of
bouncing and rippling at the front edge of the wave transformation.  It may
look like a One and zero to a programmer or square wave but to an analog
engineer it's a slope with major vibrations on the font edge. The spikes are
a physics commodity that we really can't fix yet. When those electrons go
from that on off state they just vibrate and make a mess of our circuits.

Joan L Brewer


Re: US Navy response to USS Vincennes airliner shootdown (RISKS-18.13)

Jonathan Thornburg <bkis@nanaimo.island.net>
Sat, 10 May 1997 12:57:04 -0700
>FROM: Mark Stalzer <stalzer@macaw.hrl.hac.com>, RISKS-19.13:
| ... When the Vincennes downed the Airbus, the Navy admitted they
| did it, held an investigation, axed the skipper, ...
                                 ================

The following newspaper story appears to contradict "axed the skipper":

>[UK] Manchester Guardian Weekly, 29 April 1990, page 8:
> "Gulf skipper honoured"
> by Simon Tisdall in Washington
>
> The captain of the USS Vincennes, the American cruiser which shot down
> an Iranian civilian airliner over the Gulf on July 3, 1988, killing all
> 290 people on board, has been awarded the US armed forces' second highest
> peacetime medal.
>
> Captain Will Rogers received the Legion of Merit "for exceptionally
> meritorious conduct in the performance of outstanding service as
> commanding officer" of the Vincennes in the period from April 1987 to
> May 1989, according to a navy citation issued in the name of President Bush.
>
> The Vincennes' weapons and combat systems officer, Lieutenant-Commander
> Scott Lustig, who was on duty in the ship's combat information centre
> when the airliner was attacked, also won two Navy Commendation Medals.

Jonathan Thornburg <bkis@island.net> (personal E-mail)
U of British Columbia / Physics Dept / <thornbur@theory.physics.ubc.ca>

  [My recollection is that the final resolution was somewhere in between
  Mark and Jonathan, perhaps a virtual axe?  I hope someone can clarify for
  the archives, although the issue is not directly relevant to RISKS.

  (At least Mark's "axed" was not Ebonics, e.g., ``the Navy axed the skipper
  a question.'')  See also RISKS-8.74 and many other back issues of RISKS
  in volumes 7, 8, 9 and 13 for Vincennes-related items.  PGN]


Re: Power system loss, despite multiple redundancy (Sheen, R-19.13)

"Ray Todd Stevens" <raytodd@tima.com>
Mon, 12 May 1997 20:58:51 +0000
In most places by building and electric codes there must be a shut off.
That shut off must shut off all power sources including backup power.  I
remember an incident where a new employee at a local computer center shut
off the power to the center.  The required power switch was one of the
familiar red large buttons on the wall.  It was protected from accidental
access by a plexiglass shield that you had to reach under and up into to
press the shut off.  However, by code it was located next to the main exit
door.  The guy thought it was the door open switch.

Ray Todd Stevens  Senior Consultant  Stevens Services  R.R. # 14 Box 1400
Bedford, IN 47421  (812) 279-9394  Raytodd@tima.com


Re: No more fingers in the dike: big flood gates (RISKS-19.13)

BROWN Nick <Nick.BROWN@coe.fr>
Tue, 13 May 1997 08:41:30 +0200
I strongly suspect that the idea that the computer will get it wrong one
time in 100 000 is likely to be based on an analysis of the application
software.  Even if this is correct (I'll leave aside the standard issues
about who wrote it, who certified it, who decided whether or not to skip an
extra week of testing because the Minister had to come and open the system
next Wednesday, etc), it assumes that the underlying computer system is not
contributing to the overall downtime.  When I read that the Maas estuary has
been cut off from the world because somebody changed the rules for daylight
savings time, or installed a patch to the operating system, or dropped a
paperclip in the keyboard, I'll have a small smile on my face, imagining the
top manager of the port management company phoning the software consultants:
"Remind me again why we didn't need the manual override ?".

Even if all this were optimally arranged in the computer's favour, however,
the numbers seem rather dubious.  According to the newspaper article, the
system analyses fresh data every ten minutes.  Let us therefore suppose that
it takes 144 go/no-go decisions per day.  At that rate we can expect a false
alarm closure once every 22.8 months on average.  (I don't know what the
cost to the Dutch and European economy of closing "part of" the port of
Rotterdam for half a day unnecessarily is, but I hope that one such closure
every two years has been costed in to the system's maintenance budget.)  In
contrast, humans running the system would probably have to make two
decisions per day (each one eleven hours before the next high tide,
presumably), thus having (if they get it wrong one time in a thousand) a
false alarm every 16.4 months; so even by the researchers' own (suspiciously
round) numbers, the computer is only 1.39 times more reliable than the
humans rather than 100 times.

And to return to a favourite hobby-horse of mine: how long is the barrier
designed to last ?  Is the computer system expected to last as long, and if
not, with what (and how) will it be replaced ?  How many changes to the
software will be required per year to take into account land reclamation and
other civil engineering works not yet planned, which change the dynamics of
the water flow in the Dutch deltas ?

Nick Brown, Strasbourg, France


Re: No more fingers in the dike: big flood gates (RISKS-19.13)

<amos@nsof.co.il-nospam>
Tue, 13 May 1997 10:47:46 GMT
Geert Jan van Oldenborgh <gj@ganesha.xs4all.nl> writes:

>...  humans will make a wrong decision every 1000 events, whereas the
>computer is trusted to fail once every 100000 decisions. ...

I wonder if these researchers have taken into account how many 1000's of
decision events went into the design and test of this system??  These
decisions are mostly made by humans!  Even if the design and test phases
were made by computers, what about the decisions made when these were
programmed (remember the Hubble space telescope)?

Someone should point out to the general press that only a *fully debugged*
decision system may be 100 times more reliable than humans (if indeed it
is), but that such an animal doesn't really exist.

Amos Shapir  nSOF Parallel Software, Ltd.  Givat-Hashlosha 48800, Israel
amos@nsof.co.il   +972 3 9388551


Re: Swedish Phreaker (Kennedy, RISKS-19.13)

KURT FREDRIKSSON <kurt.b.fredriksson@molndal.mail.telia.com>
Sun, 11 May 1997 16:45:11 +0200
I can well understand the astonishment caused by the US$345 fine.

The reason, I believe, is that there is a bigger issue involved: What crime
does a person in one country commit when the criminal activity is noticeable
only in an other country.  We don't have a legislation in this area (yet)
and the court couldn't fine the phreaker for more than a minor offence.

There are a number of interesting questions involved, such as
  1  Which law book is applicable?
  1a The law in the country the offending person performed the crime?
  1b The law in the country affected by the crime?
  1c The law in countries used to pass the criminal behaviour?

Quite interesting questions, until (?) we have a common law on earth.

Kurt Fredriksson, KFRE-konsult


ACM lacks $50

Bertrand Meyer <bertrand@eiffel.com>
Tue, 13 May 1997 14:53:46 -0700
Maybe you'll get a few hundred similar messages, but just in case I am the
first: today I sent a message to a colleague X with an address of the form
X@acm.org; the message bounced.  I forwarded it to the contact at my
Internet Service Provider:

> I find the following bounce strange, since acm.org is a very famous and
> widely used host. In fact, whois knows about it:  [...]
> I have no idea what this can be: a problem at acm.org, a problem at
> [the ISP], a problem in-between, some general temporary problem on the
> Internet?

The ISP's answer:

!!! Here's the problem (from the "whois acm.org" output):
!!!>        Domain Name: ACM.ORG
!!!>        Domain Status: On Hold
!!!> They didn't pay their Internic bill, so the domain was shut off for
!!!> non-payment...  Not much anyone (except the holders of the acm.org
!!!> domain name) can do about it, sadly.

So here it is: the oldest computing society in the world, associated in the
minds of many people with names such as von Neumann, Eckert, Mauchly etc.,
gets kicked out of the Internet for failing to pay a yearly fee which,
unless I am mistaken, currently amounts to $50.

The other possible explanation is that Internic is the culprit.  Given some
of what I have read in the press about the management of domain names, that
is not impossible.

Again unless I am mistaken, lots of people, including some very well-known
computer scientists, choose X@acm.org, for some X, as their e-mail address.
In fact a friend Y from Australia just wrote to me that since he would
likely be changing jobs once or twice in the next few months he was using
Y@acm.org as his "permanent" address.

-- Bertrand Meyer, ISE Inc., Santa Barbara, <Bertrand.Meyer@eiffel.com>

  [The ACM HQ folks seem to be off on retreat this week, so I could not
  get an official comment, but my e-mail later in the same day went straight
  through to acm.org.  Perhaps Bertrand expects e-mail to be reliable?
  (What a joke!)  I sometimes get *SEVERAL HUNDRED* transient bounces on a
  single mailing of RISKS, many hard bounces that are only temporary, and
  many more new cases of "address unknown" just since the previous issue.
  It sure makes moderating a newsgroup a lot of fun (not to mention the
  recent day in which I had to field over 40 spam messages as well).  PGN]


Signature scam?

John Elsbury <ubique@ibm.net>
Tue, 13 May 97 22:17:09
I just received a junk e-mail inviting me to submit my signature, on paper,
to an outfit who claim they will turn it into a Truetype Font so that I can
include it in documents.  Payment is, of course, by credit card.  The risks
seem pretty obvious......

John Elsbury (elsbury@ibm.net, jelsbur@clear.co.nz).

  [Several folks remarked on this.  I received four copies of that one
  myself.  But this type (!) of operation has been around a long time.
  Another company was hustling similar stuff early this year.  PGN]


Dialing someone who became `road kill' on the Information Superhighway

Paul Robinson <foryou@erols.com>
Fri, 09 May 1997 00:05:50 -0400
At another place, I work for another company answering Technical Support
telephone calls for an Internet Service Provider.  We allow people to
register for the service by loading an automated installer program, which
then, when finished installing the software, allows them to dial into the
registration server to choose their username and password.

I got a call from a woman who is not a user of the service, but a victim.
In order to explain the entire situation I have to give almost the full
number, however I have changed the number here - and not giving out her area
code - in order to protect her privacy.  The woman called, not because she
is trying to use the service, but because people trying to use the service
are calling her!  Or rather, their computers are calling her, virtually any
hour of the day or night.  The woman's number would be something like
701-8001 in this example. Apparently, people's computers are calling this
woman's number instead of our registration server.

This doesn't make any sense, because in order to register for the service, a
user's computer will connect to the registration server by dialing a
toll-free number.  For the purposes of this demonstration, I'll pretend the
registration server's number is 800-123-4567.  Had her number been the same
as the last 7 digits of the number I could understand that it's somehow
missing the 1-800, but her number is completely different from the number of
the registration server even without the area code.

The software to set up registration is fairly telephone savvy, allowing
people to pick things like whether they have tone or pulse, if they dial a
number such as "9" to get an outside line, or if they have to disable call
waiting.  If they select "disable call waiting", it is smart enough to give
them the *70 code and even allowing them to change it if, for example, they
have pulse dial.

That's when it hit me.  Consider the registration server's number with a
cancel call waiting code, only don't put in the star, and you get 70-1-800-1
which is the woman's number.  (The rest of the 800 number, which in this
fictitious example is 234-567, would be ignored by the dial switch.)  The
*70 code for cancel call waiting, followed by the 1-800 number being dialed,
only the star key got lost!  As a result, some people are using the cancel
call waiting code but somehow the star is not included.

The woman felt a little better when I explained to her why she was getting
these calls, and I said we would look into the problem and try to fix it.
But it's interesting how a small and tiny error can cause someone major
headaches.  Or in this case, some poor woman whose number matches a
misdialed call waiting code and a computer 1-800 number becomes, in effect,
'road kill' on the 'information superhighway'.

Paul Robinson <foryou@erols.com> (formerly PAUL@TDR.COM)


RISKS of subscribing yourself to an e-mail database service

"Steve Andre'" <steve@cyberspace.org>
Mon, 5 May 1997 14:01:35 -0400
In catching up on my overbloated mailbox last week, I found a message from
one of the larger e-mail address database companies.  I'd registered myself
there, and found an old friend through their system.  This message was a
newsletter; the usual kind of thing, talking about itself and attempting to
be useful.

One little article talked about how I'd "never have to use my password
again" with regard to their site.  My ears went up; I continued on.  It said
that with the simple URL included, I wouldn't have to enter my password any
more.  No password?

The example URL for their site was standard HTML hieroglyphics, *with my
password right in the example URL*.  It suggested that if I bookmarked it I
could use this and not have to worry about my password ever again.

...After climbing back into my chair, it occurred to me that they really
hadn't a clue about things:

 - They sent my password IN CLEAR TEXT over a completely unencrypted
   communications protocol.

 - They *knew what my password was*.  It wasn't stored in any safe
   form--it's quite probably in raw ASCII in their database along with
   the other information about me.

The RISKS here as I see them:

1) Don't make the assumption as I did (but won't any more) that when ou
   offer a service a password they'll know how to take care of it.

2) That the entity you're using will understand proper security measures in
   general.


Choosing and protecting your password: NOT!

"Mike Wilson, ICL Medical Portfolio" <mrw@oasis.icl.co.uk>
Wed, 14 May 1997 11:23:50 +0100 (BST)
I overheard this in my local Blockbuster video store:

    Assistant: "John, tell me your password so I can log you on".
    John: (shouting halfway across the store) "One Two Three".

I suggested John change his password ASAP. What's the betting it is now 321?

Mike Wilson Reading, Berkshire, UK REA03 mrw@oasis.icl.co.uk
at home: mrw@plexus.demon.co.uk  http://www.plexus.demon.co.uk

  [I'd bet it is STILL 123.  THEY probably don't care.  It's YOUR information
  (credit card, rental records, etc.) being protected, not THEIRS.  PGN]


Re: Year 2069 problem (Shostack, RISKS-19.13)

Hallam-Baker <hallam@ai.mit.edu>
Wed, 14 May 1997 13:41:42 -0400
If you are thinking that far out, there is the 2106 problem.  Sometime in
January 2106 the UNIX epoch ends.  This is because 2^32 seconds from 1970 is
2106.  Some UNIX systems are even worse off, they use a signed integer for
time meaning that they fail in 2038.

The sliding window approach is the one I adopted back in 1983 when I last
worried about the millennium bug. The software in question was being asked
to do long range forecasts. The database formats were pretty much cast in
stone. The cost of the hack was a couple of days of my time, the cost of the
perpetual solution probably a man year of effort. It would be better use of
my time to port the database to a new platform altogether which is what I
suggested. This cause problems as the client did not like my benchmarks that
revealed that their mainframe database was using bubblesort and that the
database schema could be converted to dBase3 format.

Phill

  [The Unix expiration (Mon Jan 18 22:14:07 2038 EST) has
  been noted previously in RISKS-16.71,77,78,79,84.  PGN]

ADDED LATER BY Phill:

It's an easy fix to convert to use unsigned integers for time and this can
be automated.  Thus, the 70-odd year extension is not too difficult to
obtain.  But changing the word size is a very different matter.

Some of the cobol Y2K firms spend their time simply eking out an extra 60
years by making the MSB of the field a hex digit rather than a decimal. It's
cheesy, however.

HTTP has a deca-millennium bug which cause the cache scheme to fail in
9999. I don't think we need worry too much about this.


Workshop on safety-critical systems standards

Victoria Stavridou <victoria@dcs.qmw.ac.uk>
Thu, 15 May 1997 14:52:07 +0100
                   ISESS 97 WORKSHOP ON COMPUTER RELATED
                            STANDARDS AND SAFETY
            Conference webpage :  http://nssc.llnl.gov/SESI/ses97
   Workshop webpage : http://www.dcs.qmw.ac.uk/~victoria/isess97prog.html

Draft Programme [breaks and breakouts omitted for RISKS]
Monday June 2nd, 1997
 * 13:30 V. Stavridou, Introduction.
 * 13:45 D. Lawrence, Keynote address.
 * 14:15 H. Daniel, Software, Safety, Security: Separate Communities!
         Common Concerns?
 * 14:45 H. Gecht, Software Safety Standards in a Quality of Service Framework.
 * 15:15 Panel: Software vs System and Sector Specific vs Generic Safety
          Standards.

Tuesday June 3rd, 1997
 * 8:30 R. Bell, Presentation on 1508
 * 9:00 V. Stavridou, UK DefStan 00-56 Update
 * 9:30 Panel: Evaluation, Proliferation and Harmonisation of Emerging
        Standards, R. Brill, Chair
 * 11:00 J. Gill, How to Execute and Effective Software Safety Program
         across the IPT
 * 11:30 M. Joseph, Role of Software Development Assurance in the
         Development of the US Oceaninc Automation System
 * 13:30 J. Halvorsen, Software Safety = Safe Medical Products
 * 14:00 J. Voas, Software Fault Injection: A Crystal Ball for Software
         Risk Assessment
 * 14:30 Panel: Testing Safety Related Computing Systems in Existing and
         Emerging Standards, H. Hecht, Chair

Victoria Stavridou, CS, Queen Mary and Westfield College, University of London,
London E1 4NS, United Kingdom  (+44) 171 975 5242 victoria@dcs.qmw.ac.uk


FMICS2 Programme and Call for Participation

Diego Latella <latella@sting.cnuce.cnr.it>
Thu, 15 May 97 11:23:53 +0200
                Second International Workshop  on
       Formal Methods for Industrial Critical Systems
 ERCIM - FMICS; UNIVERSITY OF BOLOGNA; CNR - AREA RICERCA PISA
        CNR/CNUCE CNR/IEI; CPR/PDCC; SASIB Railways
                          CESENA (Italy)
                          4-5 July 1997
      PRELIMINARY PROGRAMME AND CALL FOR PARTICIPATION

The Second International Workshop on Formal Methods for Industrial Critical
Systems will take place in Cesena, close to Bologna (Italy) as a Satellite
Workshop to the 24th International Colloquium on Automata, Languages, and
Programming, ICALP '97.

The aim of these workshops is to provide a forum mainly for, but not limited
to, researchers of ERCIM Sites, interested in the development and use of
Formal Methods in the Industry.  In particular, these workshops should bring
together scientists active in the area of formal methods and willing to
exchange their experience in the industrial usage of these methods. They
also aim at promoting research and development for the improvement of formal
methods and tools with respect to their usage in/interest of industry.
Please notice that the workshop will be held in conjunction with the Second
International Workshop on Advanced Intelligent Networks (AIN'97)

WORKSHOP http://fdt.cnuce.cnr.it/~latella/FMICS/WS/Cesena97/workshop.html
REGISTRATION http://www.cs.unibo.it/icalp97/Icalp_registration.html
HOW TO REACH Cesena http://poseidon.csr.unibo.it/ain/


RiskWorld

"Mary Bryant" <bryant@usit.net>
Tue, 13 May 1997 18:31:32 -5
The full text of the two-volume Presidential/Congressional Commission on
Risk Assessment and Risk Management final report is available at
http://www.riskworld.com, the Internet address of the on-line publication
RiskWorld.  The commission's long-awaited report is expected to have a major
impact on how the federal government uses risk assessment and risk
management in regulatory programs.

To access the report's HTML or PDF versions and other information relating
to the commission, including its mandate, a list of commission members, the
draft report, and seven supporting reports, open http://www.riskworld.com,
click on "front page," and click again in the box labeled "Commission on
Risk Assessment and Risk Management."

Launched in November 1995, RiskWorld provides on-line news and views on risk
assessment and risk management.  Examples of current postings in RiskWorld
include:

--the testimony of Harvard Center for Risk Analysis Director John Graham
before the National Transportation Safety Board on the results of his most
recent cost-benefit analysis of vehicle air bags that found serious problems
with passenger-side air bags,

--abstracts from the combined 1996 Society for Risk Analysis and
International Society of Exposure Analysis Annual Meeting and from the
SRA-Europe 1996 Annual Meeting,

--job openings in the risk community,
--a calendar of risk-related events,
--a listing of risk-related courses and workshops, and
--a listing of risk-related web sites.

To request information or to contribute suggestions or information  to
RiskWorld, please contact RiskWorld Editor Lorraine Abbott by e-mail
abbott@usit.net, telephone (423) 691-0176, or fax (423) 691-0229.

Please report problems with the web pages to the maintainer

Top