The RISKS Digest
Volume 21 Issue 27

Thursday, 15th March 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

Stockholm power outage hits high-tech companies
Ulf Lindqvist
New USB Army 'Land Warrior' tech connects the next cybertoys
Bob Frankston
In Japan, do trains check for drivers?
Joyce K Scrivner
UCITA implements DoS and DDoS Vulnerabilities
Warren Pearce
Moon-landing-hoax hoax
Dave Stringer-Calvert
Mistaking list for scalar context brings cops
Jamie McCarthy
Fairfax, VA Police records public
Dan Graifer
Risks of would-be copper thieves
Gregory Soo
Yahoo! Mail translates attachments
Bob Frankston
More on Bibliofind
Lenny Foner
Re: Air Gaps
M.S. Jaffe
Re: Smart bombs miss again
Dave Aronson
Randy Davis
Re: NAVSTAR
PGN
Re: SETI@Home felled by a single point of failure
George C. Kaplan
Mary Schafrik
Re: When will they EVER learn?
Gideon Sheps
Re: Palm passwords aren't...
Peter Houppermans
Don't risk missing the Parnas Symposium at ICSE 2001!
David Weiss
Info on RISKS (comp.risks)

Stockholm power outage hits high-tech companies

<Ulf Lindqvist <ulf@sdl.sri.com>>
Mon, 12 Mar 2001 10:58:49 -0800 (PST)

As reported in various Swedish media, including *Dagens Nyheter*
(http://www.dn.se/), Mar 12, 2001:

A fire in a tunnel containing power cables caused a long-lasting
blackout for 50,000 people and a large number of high-tech companies
in several Stockholm suburbs. The incident happened on Sunday
morning, and utility company officials hoped that customers
would have power again late Monday evening.

The largest employer in the area, Ericsson, told 11,000 employees to stay at
home Monday as their workplace had no power. IBM did the same thing for
their 2,000 employees.

The blackout also caused problems with other depending services, such as
water, heating, landline phones, mobile phones, pagers, Internet traffic and
servers, and public transportation. Police and fire departments have been
busy with burglaries (no lights or alarms working), fires (caused by candles
and even indoor BBQs) and black traffic lights.

A spokesperson for the utility company Birka Energi says: "The cable damage
is total. We cannot handle it with normal rerouting, because all the cables
were destroyed."

All the cables in one tunnel, that is.  Did anyone mention eggs and baskets?

Ulf Lindqvist, System Design Lab, SRI International, 333 Ravenswood Ave,
Menlo Park CA 94025-3493, USA +1 650 859-2351 http://www.sdl.sri.com/

  [Egg-sell-ent time.  That's what's called tunnel vision.  PGN]


New USB Army 'Land Warrior' tech connects the next cybertoys

<"Bob Frankston" <rmf2gOther@bobf.Frankston.com>>
Thu, 8 Mar 2001 13:50:14 -0500

Apparently TransDimsensions is a defense contractor that is using a version
of USB (Universal Serial Bus) (and Bluetooth) as the basis for the
"Soldier-of-the-future" project. I can understand that some of the promised
peripherals are "cool" and even useful. But one of the major lessons of the
Internet is the power of the "end-to-end" approach that puts the onus on the
end points to provide reliability. Bus architectures like USB provide a
reliable and synchronous transport that is the basis for brittle designs
that have little resilience. Unlike the Internet where each participant
takes responsibility for quenching failures, in USB creates dependencies in
which failures propagate.  Of course USB also has the problem of not having
an addressing structure for peer connectivity beyond a very local scale.

The problem is that stories about the soldier of the future are very glitzy
and that it is easy to claim one needs a reliable networking technology such
as USB rather than an imperfect one like IP. But that's like saying that you
can't risk exposing children to germs because they might get sick. It works
fine until the children are deployed (become adults). At that point they
have no survivability.

http://www.zdnet.com/anchordesk/stories/story/0,10738,2693677,00.html


In Japan, do trains check for drivers?

<"Scrivner, Joyce K" <joyce.scrivner@unisys.com>>
Wed, 14 Mar 2001 19:24:28 -0600

I thought checking for a driver on computerized trains was routine.  They
must not have deadman switches on Japan's bullet trains (Shinkansen).  A
driver left his seat to search for his misplaced hat — because the company
rules state that he must have his hat on at all times.  Fortunately, (1) the
train was going in the neighborhood of 15 miles per hour at the time, and
(2) there were no passengers at the time.  Drivers have now been informed
that if they misplace their hat, they should continue to the next station.
[Source: Bullet Train Left Driverless in Hat Search, Reuters, 14 Mar 2001]


UCITA implements DoS and DDoS Vulnerabilities

<"Pearce, Warren, CTR" <Warren.Pearce-contractor@jntf.osd.mil>>
Thu, 8 Mar 2001 07:48:08 -0700

Ed Foster's "The Gripe Line" Column in the 5 Mar 2001 issue of *Infoworld*
(www.infoworld.com) raises a pair of interesting Denial of Service (DoS) and
Distributed Denial of Service (DDoS) attack vulnerabilities.  He says:

  Foremost among the perils posed by UCITA is the "electronic self help"
  section that allows software publishers to equip their programs with
  remote disabling capabilities.

Think about this in terms of a DoS vulnerability. The vendor may say that
the capability is disabled for software bought with a Commercial bulk
license.  For example, Microsoft has indicated that they disable this
"feature" for their bulk license sales.  However, how can a DoD/Commercial
user with a very critical application be sure that the process that disabled
the remote disabling capability can't be circumvented?  Consider the
motivation an adversary would have for software used in critical DoD
applications.

In another section of his Column, Ed commented (*Italics* added by Warren
Pearce):

  A perfect example is the service agreement posted by Juno in January,
  particularly the section in which Juno claims the right to use its
  customers' computers during their downtime to run its own "Computational
  Software".  Juno's service agreement states, "In connection with
  downloading and running the Computational Software, Juno may require you
  to leave your computer turned on at all times. ... *You expressly permit
  and authorize Juno to initiate a telephone connection from your computer
  to Juno's central computers, ... and you agree that, as between you and
  Juno, you shall be responsible for any costs and expenses resulting from
  the foregoing."* ... As has been widely reported, in February Juno
  announced its Virtual Supercomputer Project, which will harness its
  customers' unused CPU cycles to sell as a *distributed computing service.*

Think about *distributed computing service* as *distributed DDoS service*.
Consider *"You expressly permit and authorize Juno to initiate a telephone
connection from your computer to Juno's central computers"* and you have
only one telephone line to your house. This indicates that Juno can occupy
this line at their volition? Hope you don't need to make a 911 call!!!  The
user *shall be responsible for any costs and expenses.* The lawyers and Juno
will have fun after the DDoS attack.

W. Warren Pearce, CISSP, TRW System Security Engineer, Joint National Test
Facility, Schriever AFB, CO. 80912   1-719-567-8736


Moon-landing-hoax hoax

<Dave Stringer-Calvert <dave_sc@csl.sri.com>>
Wed, 07 Mar 2001 17:28:02 -0800

Someone hacked a NASA Web site and replaced it with a conspiracy theory
about the moon landings being faked.

http://www.zdnet.co.uk/news/2001/9/ns-21426.html


Mistaking list for scalar context brings cops

<Jamie McCarthy <jamie@mccarthy.vg>>
Wed, 14 Mar 2001 09:46:41 -0500

A high-school sophomore last week was called to his private school's office
and asked to explain some suspicious text on his Web site.  What was
intended to be a quote from /usr/games/fortune was instead the *first line*
from its output.  The school staff was very alarmed because the full output
would have been:

   I put the shotgun in an Adidas bag and padded it out with four
   pairs of tennis socks, not my style at all, but that was what I
   was aiming for:  If they think you're crude, go technical; if they
   think you're technical, go crude.  I'm a very technical boy.  So I
   decided to get as crude as possible.  These days, though, you have
   to be pretty technical before you can even aspire to crudeness.
   - Johnny Mnemonic, by William Gibson

Using a variable in list context on the left side of a perl expression
puts the right side into the same context, and many operators behave
differently in different contexts.  These two statements are not
equivalent:

   my $f  = `fortune`; # returns fortune as scalar, stores in $f
   my($f) = `fortune`; # returns each line of fortune as one element
                       # in a list, stores first line in $f

Only the line about the shotgun in the Adidas bag made it to this kid's Web
page, and the school went into crisis mode.  They called the police just to
be on the safe side.

http://slashdot.org/article.pl?sid=01/03/13/208259

Everything was eventually explained to their satisfaction, but the cops
still talked to this sophomore and his father for a couple of hours and
they're keeping his name on file... again, "just in case."

The risk is, I think, being a private high-school student a week after a
high-profile school shooting, and having a Web site.

Jamie McCarthy  jamie@mccarthy.vg  http://jamie.mccarthy.vg/


Fairfax, VA Police records public

<Dan Graifer <dan@ad-co.com>>
Mon, 12 Mar 2001 13:26:46 -0500

The "Dr. Gridlock" column in the March 12, 2001 Washington Post (a regular
column devoted to traffic issues in the DC Metro area)

	http://washingtonpost.com/wp-dyn/articles/A55582-2001Mar11.html

points out that that Fairfax County police are posting their arrest records
online.  Everything from speeding tickets to homicide.  It also notes that
these are never updated to indicate the disposition of the cases, nor is
that information available elsewhere.

Besides the URL provided:
	http://www.co.fairfax.va.us/ps/police/reports/Arrest.txt

going up one level yielded a directory of what appears to be all the crime
reports as MSWord documents.  Note that this information has always been
publicly available, but you used to have to go to the police station to
browse it.

The risks of this have been discussed before.  I'd sure hate to be
mistakenly arrested. "no really, that case was dismissed...".  Sure hope
that server is secure too...

Daniel A. Graifer <Dan@AD-CO.com>  Home/Office: (703)425-6091
Andrew Davidson & Company, 520 Broadway 8th FL, NY 10012  (212)274-9075


Risks of would-be copper thieves (Re: SETI, RISKS-21.26)

<"Gregory Soo hotmail" <grsoo@hotmail.com>>
Sat, 10 Mar 2001 20:52:55 -0500

Another copper-theft attempt shut down the Rogers@Home cable Internet
service in Canada on 8Mar2001 for over 12 hours, although the thieves wound
up only with fiber-optic cable carrying Internet traffic to a U.S. backbone.
Over 300,000 Ontario subscribers were affected, because of an outdated
backup system and a single-point vulnerability.  [Source: Vito Pilieci, *The
Ottawa Citizen*, 10Mar2001, Rogers@Home: First cut is the deepest.  Rogers
admits 'rather outdated' network vulnerable to bumbling thieves; PGN-ed
http://www.ottawacitizen.com/hightech/010310/5075158.html]

  [Coppers, robbers, backups, backbones, backhoes, back to basics.  PGN]


Yahoo! Mail translates attachments

<"Bob Frankston" <rmf2gOther@bobf.Frankston.com>>
Tue, 6 Mar 2001 20:50:38 -0500

I thought the RISKS readers would find this ZDNet item excerpt entertaining:

  BugNet, with testing help from KeyLabs, has validated a quirk in the
  Yahoo! Mail online attachment viewer that translates certain words when
  they are displayed in a browser.  Even though these word conversions will
  hardly be noticed by most Yahoo! Mail users, it has caused some confusion
  with others, and it is probably good that you be aware of what is going on.
  http://www.zdnet.com/zdhelp/stories/main/0,5594,2631218,00.html

    [Unfortunately, the two-paragraph item contains no examples.  PGN]


More on Bibliofind (RISKS-21.26)

<Lenny Foner <foner@media.mit.edu>>
Mon, 5 Mar 2001 18:02:42 -0500 (EST)

Mere moments after sending my previous message, this landed in my mailbox.
It still doesn't answer the question of why they were retaining any of this
information in the first place; I've asked them why, but don't expect a
response, since they'll presumably be deluged.

(Given that there seemed to have been no way, for example, to add or
subtract a credit card [because there was no way to discover that Bibliofind
knew about me as a particular user -at all-; it remembered my state on a
couple of forms as I filled them out, but presumably forgot all about me as
soon as the final form was submitted], and since not all booksellers accept
all cards, one might have thought that Bibliofind wasn't keeping any of this
information.  This seems a great example of a site just hoovering up info
for some ill-defined later purpose that they didn't need at all.  When, oh
when, will such sites learn that this behavior only serves as (a) a cracker
target or (b) a way to waste money answering subpoenas?)

- - - Begin forwarded message - - -

Date: Mon, 05 Mar 2001 12:03:02 -0500
From: info@bibliofind.com
To: info2@bibliofind.com
Subject: Important Information from Bibliofind

Dear Bibliofind Customer:

Bibliofind has just learned of a security violation on its site that
compromised the security of credit-card information used on Bibliofind's
servers from last October through February 2001.

We have no information at this time to suggest that your credit card has
been misused, but we wanted to notify you as a precautionary measure.  We
have been in contact with the federal law enforcement authorities on this
matter, and we have also notified the appropriate credit card companies, so
that they can take the necessary steps to protect the interests of any
cardholders who may be affected.

If you have specific questions about your credit-card account, please
contact the issuer of your credit card.

To ensure this doesn't happen again, we have removed all customer
credit-card information, physical addresses, and phone numbers from
Bibliofind's servers.  We expect to bring the Bibliofind system back into
operation shortly.

We apologize for any inconvenience this may cause you.  You can contact us
with questions at info@bibliofind.com.

Sincerely,

Bibliofind


Re: Air Gaps (Schneier, RISKS 21.26)

<"M.S. Jaffe" <jaffem@pr.erau.edu>>
Tue, 13 Mar 2001 21:34:50 -0700

> ... Nonetheless, the intruder can still access the back-end server as a
> regular client. The intruder can still break into the internal system by
> exploiting any vulnerabilities above the transport layer. ...

Mr. Schneier is, of course, quite correct. And, as far as I am concerned,
his observation, above, should be printed on almost every computer security
product marketed today --- something like the Surgeon General's warning on
tobacco products.  It is also worth remembering that even *real* air gaps
cannot totally prevent the leakage of sensitive information (or, in theory,
going the other direction, possible attacks).  An air gap might reduce
covert channel bandwidth dramatically, but it cannot reduce that bandwidth
to zero.

... Matt               http://backoff.pr.erau.edu/jaffem


Re: Smart bombs miss again (Lord Wodehouse, RISKS-21.26)

<Dave Aronson at bigfoot dot com or att dot net <postmaster@airnsun.dcfido.org>>
Tue, 13 Mar 2001 08:50:45 -0500

 > The military rely on ["smart weapons"] more and more, and
 > yet they are shown to be more limited and often less usable.
 > Extending this on to the smart guns and systems for soldiers,
 > I see the fighting forces becoming less effective.

And not only soldiers.  Though the "smarts" are of a different variety (user
authentication versus targeting), the probable faults of so-called "smart
guns" are a hot topic within the gun control debate.  Even setting aside the
question of civilians, would you want police (who are more often shot with
their own guns than any other, in the USA), never mind the military, armed
with such technology?  Some designs deactivate the gun if the battery dies;
soldiers may maintain their weapons well (even in peacetime, for fear of
discipline), but police (at least here in the USA) are infamous for not
doing so.  Many designs are even susceptible to jamming signals easily
generated with a handheld device (which of course will be a hot item, so to
speak, among criminals).  Some require punching in a code in order to
activate the gun... and of course the keypads (another point of failure)
have to be small (to fit) and difficult to depress (to avoid false presses
during normal handling), so the chances of fumbling under the stress of
having your life in immediate danger are greatly magnified.  The list of
risks goes on....


Re: Smart bombs miss again (Lord Wodehouse, RISKS-21.26)

<Randy Davis>
Tue, 6 Mar 2001 00:31:54 -0500

> "Pentagon officials have admitted that most of the bombs dropped by US
> and British warplanes on Iraq last Friday missed their targets."
> [...]
> Yet again I find myself writing to RISKS to point out that these
> computer-game type weapons are almost always oversold on their abilities

Independent of whether the weapons are being oversold, I find myself writing
to RISKS yet again to point out the meaninglessness of the statistics cited.
Consider first of all the word "most," used presumably because it sounds
impressive. If you read the BBC article you discover that what they mean:
"bombs hit fewer than 50% of the targeted radars." So if 49% of the bombs
hit, "most" of them missed.

Now consider "fewer than 50%" as a bomb hit rate. Is that great, ok, or
terrible? Right, you don't know.

Third, it's a doubly meaningless statistic. One relevant point is, compared
to what? The comment in 21.26 claimed in passing that they "have been little
more effective than plain dumb bombs." Really? What's the accuracy of plain
dumb bombs? Is it 49%? No doubt some folks in the audience actually know the
answer to that and can supply it, but the BBC report didn't say and neither
did the Risks posting.

The second half of the meaninglessness is that accuracy isn't measured as
hit or miss; bombs (and missiles) don't have to hit the target to be
effective.  Sometimes 2000 pounds of explosive going off in even the general
neighborhood is quite enough.

One standard measure is "circular error probable," a circle within which 50%
of the bombs would fall. The relevant statistic is the size of that
circle. One source indicates that in WWII, "more than half the bombs dropped
missed their targets by well over 1000 yards"
(http://www-cgsc.army.mil/usaf/Pubs/Enemysytem.htm), i.e., they fell more
than _half a mile_ from the target. How much better is conventional bombing
now, and how do the smart bombs compare? That would be an interesting set of
numbers.

In the absence of the relevant numbers and relevant comparison points, the
widely repeated "more than 50%" is simply meaningless, no matter how
melodramatic it sounds.

Randall Davis


Re: NAVSTAR (Paul, RISKS-21.26)

<Peter Neumann <neumann@csl.sri.com>>
Mon, 5 Mar 2001 20:28:50 -0500

I have been informed that *The Washington Post* article says, "An FBI
spokesman said that the stolen software was unclassified."  PGN


Re: SETI@Home felled by a single point of failure (Pack, RISKS-21.26)

<"George C. Kaplan" <gckaplan@ack.Berkeley.EDU>>
Mon, 12 Mar 2001 17:10:38 -0800

If there had been a (lower speed) backup link we could have applied
rate limits to the SETI@Home traffic, to keep it from swamping the
link.  Granted, this may have been almost indistinguishable from
blocking the SETI@Home data server altogether, but it would have
allowed other SSL net traffic to get through.

> LBNL and SSL are cut off from the 'Net altogether until this SPF is
> repaired.

This is only partly true.  The severed cable connected LBNL to the UC
Berkeley campus.  LBNL has other connections to the Internet, so they were
not completely cut off.  SSL and the Lawrence Hall of Science are
administratively and topologically part of UC Berkeley, even thought LBNL
lies between them and the rest of campus.  They *were* completely cut off
from the net for about 5 days.

> ... drop-out rate may increase as people simply give up instead of
> checking the home page for an explanation for their lack of progress.

I don't have any information on drop-outs, but the data volume has returned
to normal levels since the cable was repaired, so I'd guess the impact was
minimal.  The disruption to the everyday business of SSL and LHS was
undoubtedly much worse than the overall effect on the SETI@Home data
processing.

There were some interesting side effects.  SETI@Home has a LOT of users.
Even though only a tiny fraction went to the trouble of looking up contact
information for UC Berkeley, we were getting a steady stream of e-mail
queries asking why SETI@Home was off the air.  We redirected their Web
server traffic to that status page in order to cut down on the number of
queries.

The redirection had the intended effect.  However, we used one of our
standard Web page templates for the status page.  The template includes some
links to our own Web pages, such as the one for job listings in our
department.  So that's why we saw a big increase (an order of magnitude) in
the number of employment inquiries during the outage.

George C. Kaplan, Communication & Network Services, University of California
  at Berkeley  1-510-643-0496  gckaplan@ack.berkeley.edu


Re: SETI@Home felled by a single point of failure (Pack, RISKS-21.26)

<Mary Schafrik <mschafrik@cintechsolutions.com>>
Tue, 6 Mar 2001 13:30:41 -0500

Even if they had a backup line, it's very likely that it was bundled in the
same cable as the primary line.  Even if you order service from several
vendors, they usually use the same physical bundles into your building.


Re: When will they EVER learn? (Kuenning, RISKS-21.25)

<Gideon Sheps <gbs@asiabondportal.com>>
Tue, 06 Mar 2001 15:42:04 +0800

We had the other side of this problem at our site.

We generate and e-mail an initial random string password to ensure that a
user has at least supplied us with one piece of valid, somewhat traceable,
information.

Since we have no choice but to send it back in e-mail we did NOT include the
login name, which the user has chosen themselves, in that e-mail.

Thus, if the e-mail was seen (we figure there is more chance of it been seen
on the office printer than by a sniffer) at least one essential element was
still missing.

Well, what happened next was that customer service started getting e-mail
and calls from users who could not recall what login name they had selected!

I should add that the password is generated and e-mailed immediately, and
will normally arrive in someone's inbox no more than a minute after they
complete the sign up.

We have also had to gradually reduce the efficacy of the random string, as
customer service requested we eliminate numbers and mixed case because of
the number of calls they fielded because of "shiftkeyanemia".

Our site only serves professional bond traders, investment managers, bankers
and such. Not the general public.


Re: Palm passwords aren't... (Bellefeuille, RISKS-21.26)

<Peter Houppermans <Peter.Houppermans@paconsulting.com>>
Tue, 6 Mar 2001 13:35:56 -0000

Re: Passwords don't protect Palm data, security firm warns (Yves Bellefeuille)

Neither do they on a Psion Series 3 or 5 if you have left the serial link
on.  If the device is locked by password it is still possible to access the
device in full if the serial link has been left online.  And I don't think
I'd need to point at the obvious risk of storing your data on removable
media which are not subject to the password lock if plugged into another
machine ;-).

However, there is hope here: you can always protect the individual files by
running a crypto program over it - whilst accepting that PDA security could
be improved.  I use a Psion Series 5MX with an RSA based freeware program
("crypto" - http://salvis.com) which works and integrates well.  Is it safe?
I wouldn't think so, but it will protect the information that little bit
longer from casual disclosure.

Peter Houppermans <peter.houppermans@paconsulting.com>


Don't risk missing the Parnas Symposium at ICSE 2001!

<David Weiss <weiss@avaya.com>>
Wed, 7 Mar 2001 17:47:28 -0500

  [Dave Parnas is one of our most distinguished participants with respect to
  his efforts to prevent risks.  His positions on the Strategic Defense
  Initiative were noted in our very first issue RISKS-1.01, and he made
  numerous contributions throughout the early RISKS volumes, including 1.02,
  1.06, 1.08, 1.28, 1.35, 1.36, and 1.37.  This birthday celebration falls
  in the midst of the IEEE Security and Privacy Symposium, but I hope many
  of you will be at ICSE 2001 and able to attend.  PGN]

Dan Hoffman and I are organizing a Symposium at ICSE 2001
recognizing Dave Parnas's work and in honor of his 60th birthday.

  David L. Parnas Symposium, A special event at the
  International Conference on Software Engineering ICSE 2001
  Tuesday 15 May 2001, Toronto, Canada
  http://www.islandnet.com/~dlps

This symposium is being held in recognition of Parnas's work and in honor of
his 60th birthday.  It is an opportunity for everyone in the software
engineering community to celebrate his contributions and to think hard about
where we are today and where we are going.

  The symposium program includes
         * keynotes by Fred Brooks and Jon Bentley
         * invited talks by Jo Atlee, Paul Clements, and Jim Waldo
         * a short presentation by Parnas
         * a panel on software engineering education

Each symposium attendee will receive a copy of the book
  Software Fundamentals: Collected Papers by David L. Parnas,
  a new book from Addison-Wesley.

Dave Weiss

Please report problems with the web pages to the maintainer

x
Top