The RISKS Digest
Volume 21 Issue 53

Thursday, 19th July 2001

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

Dashboard can fire water at sleepy drivers
John Arundel
Polarized sunglasses and car LCD displays don't mix
Henry Baker
Missile defense test radar glitch
PGN
Historical Risk: KORD, and N-1 Engine Failures
Ami Abraham Silberman
Software gives erroneous air navigation reading
Bill Hopkins
Even a fatal error can't kill it
Jim Haynes
Gaffe gives away minister's secrets
Paul Cornish
SSL encryption that isn't
Ron
FBI arrests Russian hacker visiting U.S. for alleged DMCA breach
Declan McCullagh
Savings Bank software upgrade goes awry
Jonathan Kamens
Risk when using "Cut and Paste"
Enrique G. Sauer
Re: The computer is taking over the train
Mark Lomas
Re: Unexpected network congestion: remote consequences of Seti@Home
Eric J. Korpela
Re: "It's public data, so why not a public database"?
Geoff Kuenning
Info on RISKS (comp.risks)

Dashboard can fire water at sleepy drivers

<John Arundel <john@splange.freeserve.co.uk>>
Thu, 19 Jul 2001 16:35:48 +0100

Annova notes an IBM system to stop drivers falling asleep at the wheel. It
asks you questions and if you fail to respond promptly, it shoots a jet of
cold water over you.  http://www.ananova.com/news/story/sm_355015.html

In the time-honoured phrase, "the RISKS are obvious".  I wouldn't like
to imagine the consequences if a driver was unexpectedly soaked with ice
water during a high-speed overtaking manoeuvure on a motorway...

  [FORDing the flood?  CHEVY to the levee?  NOVAcaine mutiny?  PGN]


Polarized sunglasses and car LCD displays don't mix

<Henry Baker <hbaker1@pipeline.com>>
Wed, 18 Jul 2001 19:16:25 -0700

I just got some new (linearly polarized) sunglasses, and got an unpleasant
surprise — I can't read the LCD displays on either my car or my wife's car
without cocking my head to one side!  On my car, I have to cock my head to
one side by about 15 degrees, while with my wife's car I have to cock my
head to the other side by about 40 degrees.

Luckily, the same angle of cocking seems to work for all of the LCD gauges
at the same time.

(I just tested my sunglasses on my laptop, and I have to cock my head left
by 45 degrees to get the brightest image.)

Considering the fact that polarized sunglasses are often better than
unpolarized sunglasses, because they do a better job of filtering out glare
(highly likely to be polarized), we actually have one safety item
interfering with another.

Why can't car manufacturers install LCD's in such a manner that the
polarization is compatible with polarized sunglasses?

Henry Baker <hbaker1@pipeline.com>

  [We all hope you do not go off half-cocked.  This reminds us of the
  problem of pilots on Viagra seeing various colors (including green)
  as blue.  Blue who?  PGN]


Missile defense test radar glitch

<"Peter G. Neumann" <neumann@csl.sri.com>>
Tue, 17 Jul 2001 22:16:19 -0700 (PDT)

The missile defense test on 14 Jul 2001 was declared a success.  However,
the Pentagon initially failed to note that the prototype radar had actually
indicated that the interceptor had missed the dummy warhead.  This omission
was considered unimportant because the glitch was a minor computer
programming error that could easily be fixed in time for the next test.  Is
that reassuring to RISKS readers?

  http://www.latimes.com/news/nationworld/nation/la-071801missile.story


Historical Risk: KORD, and N-1 Engine Failures

<Ami Abraham Silberman <silber@mitre.org>>
Tue, 17 Jul 2001 10:50:19 -0400

The following is forwarded with permission of the author, Patrick Flannery
<flanner@daktel.com>. It originally appeared in sci.space.history

The N-1 was the Soviet equivalent to the U.S. Saturn V, it was to have
launched the first Soviet manned lunar missions. It used a cluster of 32
rocket engines on the first stage. To handle automatic shutdown in case of
emergency or failure, they used an automatic system named KORD.  - Ami
Silberman (silber@hotmail.com)

What KORD was designed to do, and what KORD did, in detail: KORD was
designed to shut down a maximum of four motors on the first stage- i.e. two
malfunctioning motors, and the two motors 180 degrees opposite of them; and
increase burn time of the affected stage to compensate; if more than four
motors needed to be shut down, then KORD shuts all motors down.(On the
second stage KORD would shut down a maximum of two motors of the eight, in
the same way. On the third, four engined stage, only the defective motor was
shut down, and the other three gimbaled to compensate.)  This would have
been good for an on-pad abort during motor startup, and could have saved the
rocket.....But:

Flight #1 Feb.21,1969- Within seconds of liftoff, two of the first stage
motors (#12&24) were shut down erroneously by KORD; the flight continued,
but at 66 seconds a Lox line ruptured, starting a fire, and KORD shut the
stage down at 70 seconds, and fired the escape tower on the spacecraft
successfully! Go KORD! KORD had begun to work it's "special" magic....

Flight #2 July 3rd, 1969- Day of The Big Fireworks- Almost immediately on
ignition, motor #8 eats something-a bolt, welding slag, temperature sensor-
stories vary; the result doesn't- turbopump blades come flying out of the
housing like bullets, and sever electrical lines, and fuel and oxidizer
lines on nearby engines, starting a large fire in the base of the first
stage. At only a few hundred feet altitude, KORD attempts to shut down all
motors...and is 29/30ths successful in this endeavor, leaving one motor
running, to neatly tip the booster 90 degrees before impact on, and
destruction of, it's launch pad. The escape tower is again fired
successfully! Go KORD! Some stories state that another N-1, on the other
pad, gets caught in the ensuing explosion's shock waves, and has to be
scrapped.

Flight #3 June 27,1971- With preternatural cunning, the Soviets have decided
that it might be wise to PLAN for having the N-1 fail, and have programmed
in a maneuver to get it clear of the launch pad immediately after liftoff-
this maneuver is performed- and promptly overstresses the airframe, and
control system, causing the rocket to fall apart in midair, and crash- but
it does NOT crash on the launchpad- Success! KORD dutifully shuts down the
first stage motors... a while after the third stage, and lunar spacecraft
assembly, have already fallen off. The escape tower? Comrade, it was a
mock-up. Boom.

Flight #4 Nov.23, 1973-With an augmented control system to allow it to do
the pad clearing maneuver before it explodes, the N-1 once again vaults
skyward....and keeps on going! Fifty seconds- all systems go!! 70
seconds-still go!!! 90 seconds- shut down of the center six motors, as
planned!!!! 95 seconds- the center six motors are now on fire!!!!! 110
seconds-Boom.  But the escape system worked! Go KORD!  Later it is
discovered that if KORD had shut down the first stage motors when the
trouble started, and fired the second stage at that time, then the mission
would have reached orbit. Go KORD!  This then, was the apex of Soviet 1960's
electronic...or at least electric, design- a safety system that both causes,
and worsens, disasters.  Who says we can learn nothing from Soviet
spacecraft design? The KGB wants to know, comrade...who specifically said
that; and what's their address?

The MITRE Corporation;W078 - C2 Systems Architecture and Integration
12 Christopher Way;Eatontown;New Jersey;07724 (732)578-6645


Software gives erroneous air navigation reading

<"Bill Hopkins" <whopkins@wmi.com>>
Mon, 16 Jul 2001 19:32:50 -0400

AVweb (www.avweb.com), a news service for general aviation, reported July 9
that the FAA has issued an Emergency Airworthiness Directive (AD) on one
model of Apollo NAV/COM (a combined navigation and communication radio) with
a specific DSP Software Version Number, because its bearing indication was
found to be off by as much as 14 degrees.  The Emergency AD prohibits any
flight in an aircraft equipped with the radio until it is marked "Use
... for navigation prohibited."

The navigation function relies on special ground stations that (simplifying
a bunch) transmit a signal that varies the phase of the modulation with
azimuth, allowing the radio to infer its bearing from a station within a
degree or two.  An aircraft flying a circle around a station sees the
modulation change smoothly.

For many aircraft, this is the primary navigation system when flying by
instruments, in clouds.  Fifty miles out and 14 degrees off could put you in
conflict with FAA airspace rules (bad, takes explaining) or mountains
(worse, takes a funeral).  In comparison, suddenly not being able to fly by
instruments doesn't look so bad.

The AD text suggests that some stations do not adhere to the nominal 30 Hz
modulation frequency, but the DSP software depends on the assumption that
they do.  I would guess that bench-testing was done only with nominal
generated signals, and certification flight testing (if needed) only with
stations that happened to be nominal.  So, no problems showed up until a
technician happened to test a new installation in the presence of a
non-standard signal.

Risks: assuming, testing within assumptions, having software in the gauges,
etc.

Bill Hopkins (whopkins@cacdsp.com)

  [We need a too-fazed commit with 14 degrees of separation.  PGN]


Even a fatal error can't kill it

<<jhaynes@alumni.uark.edu>>
Mon, 16 Jul 2001 23:58:01 -0500 (CDT)

or "night of the living dead"

I just made an airline reservation using the web page.  When I got all the
way to the end, having put in the credit card information, it said "Fatal
error in backend" and gave an error number and dumped me out.  So I
assumed (foolish assumption) that the thing had failed and started all
over.  The second time everything worked as it should.  Then I read my
email and found I had email confirmations for both of the reservations.

So I called the airline and got connected to a tech support person and he
said yep, I've got two reservations on the same flight and he would cancel
one of them and they would issue a refund to my credit card for it.  He
said the software is supposed to catch cases of the same person making two
reservations on the same flight but in this case that didn't work either.

For me, this is a case of deja vu all over again.  Some ten or more years
ago I reported using an online banking money transfer system where I put
in all the data and then the computer voice said "system error, session
terminated"  So I put the transaction in a few more times over the space
of a few days, until I got the normal "data accepted, thank you" message.
And soon after got a call from the bank about the account being way
overdrawn, because in fact each of the transactions had gone through.

No doubt there are other systems out there which have the possibility of
completing a transaction and then telling the user that there has been a
fatal error.  Maybe a whole lot of them.


Gaffe gives away minister's secrets

<Paul Cornish <paul.cornish@psion.net>>
Tue, 17 Jul 2001 10:03:53 +0000

A series of government initiatives have been accidentally made public after
the "wrong" version of a speech by cabinet minister Stephen Byers was
released.  Civil servants unintentionally circulated an electronic copy to
interested bodies which can be opened to reveal which passages have been
removed or added during drafting.  For more information see
The Guardian Newspaper, Society Section, Thursday July 12, 2001.
  http://www.guardian.co.uk/Archive/Article/0,4273,4220335,00.htm

Paul Cornish <Paul.cornish@psion.net>


SSL encryption that isn't

<Ron <ron1@stop.mail-abuse.org>>
Tue, 19 Jun 2001 10:02:51 -0400

If you submit your information to an SSL protected web page you're
protected, right?  Not always.

Check the EAA (Experimental Aircraft Association) web page that lets you
join online.  You can find it at
  https://secure.eaa.org/EaaJoin/securejoin.html

It looks good, and the browser indicates that it's 128-bit encryption.  It
inspires confidence until you look at the page source.  Here's a couple of
relevant lines [NOTE: I've modified the Email address to avoid spambots]:
  form METHOD="POST" ACTION="..\send_email.asp"
  input type="hidden" name="EMAILTO" value="joineaa@example.com"
It certainly appears that this 128-bit encrypted SSL form proceeds
to send out your sensitive information via Email in cleartext.  I
verified this by modifying the form to send mail to me.  I then tried
it.  Sure enough, the entire form is sent in clear, including credit
card number.

  [ADDED NOTE, 17 Jul 2001: I notified the site owner at the same time I
  mailed RISKS.  The site is still unchanged.  Ron]


FBI arrests Russian hacker visiting U.S. for alleged DMCA breach

<Declan McCullagh <declan@well.com>>
Tue, 17 Jul 2001 10:57:48 -0400

Russian Adobe Hacker Busted
By Declan McCullagh (declan@wired.com), 17 Jul 2001
http://www.wired.com/news/politics/0,1283,45298,00.html

LAS VEGAS — FBI agents have arrested a Russian programmer for giving away
software that removes the restrictions on encrypted Adobe Acrobat files.
Dmitry Sklyarov, a lead programmer for Russian software company ElcomSoft,
was visiting the United States for the annual Defcon hacker convention,
where he gave a talk on the often-flawed security of e-books.  This would be
the second known prosecution under the criminal sections of the
controversial Digital Millennium Copyright Act, (DMCA) which took effect
last year and makes it a crime to "manufacture" products that circumvent
copy protection safeguards.  [...]

POLITECH — Declan McCullagh's politics and technology mailing list
You may redistribute this message freely if you include this notice.
To subscribe, visit http://www.politechbot.com/info/subscribe.html
This message is archived at http://www.politechbot.com/


Savings Bank software upgrade goes awry

<Jonathan Kamens <jik@kamens.brookline.ma.us>>
Mon, 16 Jul 2001 23:05:46 -0400

My bank, Peoples Federal Savings Bank in Brighton, Massachusetts, "upgraded"
its computer software on the weekend of June 9.  No explanation of the
purpose of this upgrade or description of the changes customers might see as
a result of it was distributed, either before or after the upgrade).  The
only notice given was a few signs posted at the bank, stating that the bank
would be closed over the weekend for the upgrade.

To say that the upgrade went poorly would, from my point of view, be a huge
understatement.  Here's some of what went wrong (but, alas, not all of it;
I'm omitting some of the minor screw-ups):

* All customers' telephone-banking (TB) PINs were reset as part of the upgrade.
  As I noted previously, customers were not informed about this in advance.

* The new, default TB PIN chosen for all customers is the last four digits of
  the primary account holder's social security number.  I'm sure I don't have
  to go into how monumentally stupid this is from a security point of view,
  especially considering that many Massachusetts residents have their social
  security numbers on their driver's licenses.

* Since the upgrade, the TB system tells you to enter the last four digits of
  your SSN as your PIN if this is your first time using the system, or your the
  PIN you've selected otherwise.  However:

  * It doesn't make it clear to previous customers of the bank that "the
    system" means the new TB system after the upgrade, i.e., that PINs set in
    the old TB system were no longer valid.  You just had to figure that out by
    trial and error.

  * The system doesn't force you to change your PIN from the default to
    something else.  So the "if this is your first time using the system"
    prompt is completely wrong, since the PIN will remain the default until you
    navigate about three levels deep in obscure menus to change it.  And I'm
    sure I don't have to go into how monumentally stupid it is from a security
    point of view that the system doesn't make people change the default PIN.

* When you requested a transfer in the old TB system and it read the
  information back to you for confirmation before performing the transfer, it
  read the amount of the transfer first, followed by the account numbers.  This
  is logical, considering that (a) the amount of the transfer is the item most
  likely to have been entered incorrectly and (b) the account numbers have
  already been verified as valid by the system.  The new system, on the other
  hand, reads both the "from" and "to" account numbers first, v-e-r-y
  s-l-o-w-l-y, before reading the amount of the transfer.

* The old TB system's transfer confirmation numbers were eight digits long,
  which was already pushing it.  The new system's confirmation numbers are ten
  digits long.  There is no excuse for forcing people to write down random
  strings of ten digits which could just as easily have been half that length
  if the UI had been designed properly.

* I can no longer access my money market account from SUM ATM machines (see
  www.sum-atm.com) run by banks other than Peoples.  Before the upgrade, my
  money market account was accessible as my "savings" account from these ATMs.

* Before the upgrade my money market account was also accessible as a "savings"
  account from Peoples ATMs.  Now, however, People's ATMs think that my money
  market account is a "checking" account, which means that I have two checking
  accounts.  Therefore, when I need to access my money market account, I select
  "checking" and get a menu to choose which checking account I want.  The menu
  looks like this:

	1. CHECKING
	2. CHECKING

  That makes it intuitively obvious which one to select, eh?  I had to figure
  out through trial and error that "1" is my old checking account and "2" is my
  money market account.

* That same menu screen tells me to press Enter after using the keypad to
  indicate which account I want to access.  But Enter doesn't work — it gives
  the low "error beep."  I had to figure out by trial and error that when they
  say "Enter", what they really mean is "the unlabeled button at the bottom of
  the column of buttons to the right of the screen."

* When I made a deposit shortly after the conversion, the printed receipt for
  the deposit showed the same amount for both "balance" and "available
  balance," even though the deposit I had just made was supposed to show up
  immediately in "available balance" (that's how the system behaved before the
  upgrade).  I complained to the bank about this through their Web site (well,
  actually, I complained to the bank about *all* the problems listed above, but
  this is the only one about which they responded), and I got back a pointless
  E-mail message from the bank's Operations Officer describing to me how the
  system was supposed to work (which is what I had just described to him in my
  complaint).  I wrote back to him and emphasized again that the system was
  *not* working that way, and he never responded.

  However, two days later when I made another deposit, *no* balances showed up
  on the receipt.  Shortly after that, when I made another deposit, the
  balances were back and the "available balance" correctly reflected the
  deposit I had just made.  So it would seem that the bank is capable of
  correcting these problems, albeit not acknowledging and apologizing for them.

* When my first statement after the upgrade arrived, I saw that I had been
  charged a $.75 ATM fee, even though I had only used Peoples and SUM ATMs all
  month, and those are supposed to be free.  When I called the bank about this,
  I was informed that "everyone was charge 75 cents because the upgrade messed
  everything up," and that the 75 cents would be credited back to my account in
  my next statement.  We'll see.

* Before the upgrade, they sent out a final statement under the old system with
  a closing date of June 8.  No interest was paid on that statement.  After the
  upgrade, the next statement they sent out closed on June 30.  The interest
  paid out in that statement correctly covered the period of the previous
  statement (i.e., they paid about 30 days of interest instead of 22).
  However, the average daily balance used to calculate the interest payment
  took into account only daily balances from June 9 through June 30.

  In other words, the bank underpaid interest to any customers whose average
  daily balance was higher June 1-8 than it was June 9-30.  Of course,
  conversely, the bank paid extra interest to customers whose averages were
  lower before the upgrade, but that doesn't help the customers who were
  underpaid.

As I'm sure you can imagine, after this debacle I'm not too keen on continuing
to patronize Peoples.  However, my fear is that when I look for alternatives,
I'm going to discover that there isn't anybody better.

Jonathan Kamens


Risk when using "Cut and Paste"

<enrique.g.sauer@lmco.com (esauer)>
Wed, 18 Jul 2001 10:30:48 +0000 (GMT)

I just became aware of a serious security risk involving the combined use of
WinWord and Excel in Office 2000.

While writing a report in WinWord, I incorporated a graph generated via
Excel via "cut and paste". Later on, using a different computer, I decided
to edit the title of the graph by double clicking on it. To my dismay, the
*entire* content of the Excel file which was not residing in the computer
where I was doing the editing, became available to me.

Say you have the unclassified "Graph 1" in sheet 1 of an Excel file and the
classified "Graph 2" in sheet 2 of the same file. When you incorporate Graph
1 in the unclassified portion of your report you are inadvertently making
Graph 2 available to the user.

To avoid this problem use "paste special", you will not be able to edit your
graphs by double clicking on it, but you will avoid potentially embarrassing
situations.


Re: The computer is taking over the train (Cohen, RISKS-21.51)

<"Mark Lomas" <mark.lomas@tmalomas.com>>
Tue, 17 Jul 2001 12:39:15 +0100

I am reminded of a journey on Thameslink (for those outside the UK, this
company runs trains between Bedford and Brighton via London).  The driver
decided to brake suddenly - I don't know why, however I remember his
subsequent announcement to passengers: "You may be wondering why we have to
wait here.  This train is fitted with a safety system which prevents the
driver from accelerating following sudden braking.  The computer will give
me back control of the train in another minute".

This is probably a sensible (but not infallible) safety precaution.

Mark Lomas <r21.51@absent-minded.com>


Re: Unexpected network congestion: remote consequences of Seti@Home

<"Eric J. Korpela" <korpela@ellie.ssl.berkeley.edu>>
Tue, 19 Jun 2001 18:39:47 -0700 (PDT)

> The article closes by saying the problem was "solved" by increasing the
> number of available NAT addresses, although of course that didn't fix the
> problem, merely caused it to 'go away'. A real solution would be to have the
> screen-saver software implement incremental backoff and other mechanisms
> designed to gracefully handle a complete loss of remote server access.
>
> One would hope that the authors of the next generation of distributed
> computation applications take heed of the lessons of the current batch.

One of the risks of developing any software is that problems experienced by
users will be associated with the design of the software, not the failure of
other components.  The GUI version of SETI@home, upon connection failure,
retries the connection twice at 45 second intervals.  After the third
failure the program waits 60 minutes before retrying.  The UNIX version
waits 60 minutes between connection failures.  Apart from this report, I am
unaware of any TCP/IP implementation that is unable to support 3 connection
attempts per hour.

That each computer involved ended up with 10 NAT translations meant that the
router was maintaining NAT translation for failed connections for 120
minutes or more.  The router apparently releases translations promptly when
connections succeed, but maintains them when connections fail.  I'm not sure
that the SETI@home software could have anticipated that.

There is another possibility.  Many SETI@home users use "work unit" caching
software to contact the server.  We don't have much control over the coding
standards used by developers of third party software that interacts with
SETI@home.

Eric Korpela <SETI@home>


Re: "It's public data, so why not a public database"?

<Geoff Kuenning <geoff@cs.hmc.edu>>
Tue, 17 Jul 2001 14:21:52 -0700

In the recent flap over 2600/1600 Pennsylvania Avenue, some readers
have pointed out:

> this kind of database provides publicly available information, so what are
> the risks, and why are we running this in RISKS in the first place?

PGN's relevance criteria did not slip up on this one.  It has often been
noted in RISKS that a difference in quality is a difference in kind.

In the current example, accessing the information in the databases once
required physical travel to a number of different locations, laborious
removal of heavy books from shelves, and endless page-turning to locate the
desired data.  These physical barriers served to winnow out all but the most
motivated people, mostly those who had a legitimate need.

Placing the same information online, in an easily correlated fashion, has
many advantages for legitimate users, not the least of which is the
elimination of the necessity of breathing dust.  But it also provides new
opportunities to the illegitimate.  It is suddenly easy to produce lists of
property owned by the wealthy, the elderly, or the vulnerable.  I am not a
criminal, so my creativity in this area is limited.  But I recognize that
there are new RISKS caused simply by changing the method of access to the
database.

The foregoing is not intended to be an immovable argument against placing
such databases online.  We must weigh the advantages against the drawbacks.
But it is incorrect to claim that there are no RISKS issues.  — Geoff
Kuenning geoff@cs.hmc.edu http://www.cs.hmc.edu/~geoff/

In any large population, there are some people who aren't very bright.
That's not their fault, it's just in their genes.  As an engineer, I have a
responsibility to design things that won't kill off the slower ones, just as
I have a responsibility to design things that won't harm my neighbor's dog.

Please report problems with the web pages to the maintainer

x
Top