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 24 Issue 64

Thursday 19 April 2007

Contents

BlackBerry suffers widespread outage
Monty Solomon
Turbo Tax Servers Can't Handle E-Filing Load from Procrastinators
Cameron Wilson
RISKS of relying on systems to file taxes late
mahlon
US Daylight Saving Issues, System Libraries vs Program Libraries
William C Bonner
time.windows.com failure
John Pettitt
Philippine Internet voting system challenge
PGN
Why should spam ever go away? The economics.
Sten Carlsen
More on Metro software fire
Taz Daughtrey
Re: Washington DC Metro replacing software that causes fires
Peter Rieden
Re: On "proving NON copyright infringement"
Jim Horning
Norman Gray
Risks of convenience
Jay R. Ashworth
Impossible data requested
John Harper
Re: Surely it can't be this easy?
Al Macintyre
ACM Computer Security Architecture Workshop
Jon A. Solworth
USENIX '07 Registration Now Available
Lionel Garth Jones
REVIEW: "Measuring ITIL", Randy A. Steinberg
Rob Slade
Info on RISKS (comp.risks)

BlackBerry suffers widespread outage

<Monty Solomon <monty@roscom.com>>
Wed, 18 Apr 2007 08:10:05 -0400

The BlackBerry wireless e-mail service from Research In Motion appears to
have suffered a widespread outage starting on the evening of 17 Apr (about
5:15pm PDT).  The outage reportedly persisted into the following morning
throughout North America.  [Source: John Blau, Problem sending and receiving
e-mail from BlackBerry devices appears to be limited to North America, IDG
News Service, 18 Apr 2007; PGN-ed]
http://www.infoworld.com/article/07/04/18/HNblackberryoutage_1.html


Turbo Tax Servers Can't Handle E-Filing Load from Procrastinators

<Cameron Wilson <wilson_c@hq.acm.org>>
Wed, 18 Apr 2007 10:24:25 -0400

Intuit (which makes TurboTax and ProSeries tax software) expected to hear
from the Internal Revenue Service today (the day after taxes were due)
whether any taxpayers who used its e-filing system would be penalized for
submitting late returns.  A flood of last-minute tax filers swamped the
servers of Intuit Inc. on Tuesday, causing hours-long delays in getting
forms sent in electronically to the government.  As the midnight filing
deadline approached, the problem got worse. During times of peak demand,
Intuit was processing 50 to 60 returns per second.  [Source: Lisa Leff,
Associated Press, 18 Apr 2007; PGN-ed]

  "Don't wait until the last minute is the moral of the story."
  [Intuit spokesperson]

Last I checked, the IRS sets a legal deadline, and Intuit's FAQ on e-filing
doesn't say -- maybe your filing will go through at 11:30, maybe it won't,
so file early.  Cameron

Cameron Wilson, Director of Public Policy, Association for Computing Machinery
1100 Seventeenth Street, NW, Suite 507 Washington DC 20036 1-202 659-9712
www.acm.org/usacm


RISKS of relying on systems to file taxes late

<mahlon <doitnow@gmail.com>>
Tue, 17 Apr 2007 23:57:27 -0700

  [I include only the SECOND of two messages from Mahlon.  The first gave a
  detailed account of repeated attempts to file electronically.  PGN]

Update: At 11:54 PM, with just 6 minutes on the clock, TurboTax finally
accepted my tax return.  No doubt now that the East Coast is past the
deadline, the load on the servers abated.  (But not before I made an
emergency run 40 minutes across town to the only post office open this
late!)

In all, I attempted to transmit 27 separate times, receiving many
nonsensical error messages.  The error message that made least sense was
this "no-error" error:

"No error. The transmission was unsuccessful.  Please try again later."

[Link to image of the "no-error" error:
http://farm1.static.flickr.com/218/463746848_7b53305130_o.png ]

Recommendations to Intuit:

1. Size your servers and network for peak volume plus contingency.
2. Provide meaningful error messages so your stressed-out users don't have
   to guess what's going on.
3. If the user is preparing a return during an expected high-volume period,
   provide a warning at the beginning of the process that servers may be
   busy, and to file a preemptive extension while the local post office
   before the local post office closes.

  [Perhaps quite counter to popular opinion, but not counter-INTUIT-ively,
  the IRS announced that it would accept Intuit's overly delayed returns.
  (Only fitting, in that the IRS has had its own series of computer
  difficulties!)  An interesting RISKS question is raised, namely has the
  definition of MIDNIGHT on tax-due-day been adequately specified? relative
  to the time zone of the server from which the return is filed? or the
  location of the filer?  What if you are filing from your laptop in Hawaii
  via your home or office system in NY?  PGN]


US Daylight Saving Issues, System Libraries vs Program Libraries

<William C Bonner <wbonner@wimsworld.com>>
Sun, 15 Apr 2007 12:33:25 -0700

I have a Windows program written in C++ using Microsoft Foundation Class
structures. It gathers data and stores it in XML format. I store associated
time stamps for the data using ISO8601 date format, and store the dates in
UCT. (I use the ATL classs ATL::CTime for most of my time manipulation
stuff, including the FormatGmt() method.)

I do not run my own date arithmetic. I only use the library calls for
switching between local time and UCT. I use standard library calls for
getting the time.

In running log files from the past few weeks I've noticed that the times
seem to be an hour off from what I remember the time would have been when
the data was taken.

Things are more complicated, because I'm teleworking from a location that is
two hours away from where the data was originally taken. (The office is in
Dallas TX, I'm in Seattle WA.)

I have no idea if the various patches I've applied to the systems I've been
using have been applied only to the operating system, the C Run time
libraries, or only half, and making sure that they are only applied once and
not multiple times.

I think that this US DST switch is going to continually bite us in small
ways for several years. The only solution I see is to operate computers on
UCT without any time zone translation enabled, which isn't really a viable
solution.


time.windows.com failure

<John Pettitt <jpp@cloudview.com>>
Mon, 16 Apr 2007 11:05:48 -0700

time.windows.com - the system Microsoft windows machines use to set their
clocks is currently reporting seemingly random times up to 150 seconds off.
It is correctly reporting stratum 16 "unsynchronized" so if the windows time
client is well written it shouldn't be a problem ....


Philippine Internet voting system challenge

<"Peter G. Neumann" <neumann@csl.sri.com>>
Thu, 19 Apr 2007 9:57:57 PDT

Local and foreign computer hackers will be invited to break into an
Internet-based voting system that will be pilot-tested by the country's
Commission on Elections (Comelec) 10 to 30 Jul 2007 for 26,853 registered
absentee voters in Singapore.  The results of the polls, which will use
survey questions, will be non-binding, which means it will not affect
official elections results.

Comelec commissioner Florentino Tuason Jr. told local reporters they have
already asked the help of the International Foundation for Electoral System
(IFES), a Washington-based IFES non-profit organization, in getting
professional hackers to test the security of the Internet voting system.
"When Scytl presented the system, everybody was impressed on the security
features.  It is covered by international patent and it has been declared
secured by no less than Switzerland and everyone in the global community
should respect that decision," Tuason told reporters in a conference
Tuesday.  Scytl's computerized voting system is also being used in countries
such as the U.S., Switzerland, and Belgium.

The Comelec has earlier batted for the full implementation of the Internet
voting system in Singapore but Senator Richard Gordon succeeded in stopping
it.  Gordon wanted a computerized casting and counting system to be deployed
instead in selected provinces in the country. The Comelec had to back off,
however, because it lacked enough time to prepare for this type of system.
[Source: Geoffrey Ramos, Hackers Invited To Break Into Philippine Internet
Voting System, *All Headline News*, Manila, Philippines (AHN), 17 Apr 2007;
thanks to Paul Lambert for spotting this one]
  http://www.allheadlinenews.com/articles/7007075062


Why should spam ever go away? The economics.

<Sten Carlsen <stenc@s-carlsen.dk>>
Wed, 18 Apr 2007 22:51:48 +0200

So, why would spam go away?

The economics of spam will eventually decide whether spam will go away
or not. If somebody can make money from it, it will stay.

I tried to grasp the total picture of the economics of spam in the following
text. I am sure I missed something.

Who gains at the present situation:

* spammers get paid by crooks and businesses
* backbone providers get to sell more bandwidth
* BOTnet providers get paid for their BOTnets
* ISPs can sell extended security packages and filtering services
* Spam-filter companies make their living off the spam
* politicians can get new laws accepted that will give them more control
* virus writers get paid for writing BOTnet creating viruses and trojans

Who loses at the present situation:

* users have to pay more for their connections
* ISPs have to pay more for their backbone
* software companies have to use substantial resources to make security
  updates
* companies, whose employees waste time to sort through loads of spam
  before work can be done

IF spam should go away, who gains:

* users should get cheaper prices
* ISPs would have cheaper backbones because of less traffic
* software companies would have less incentive to make safe software
* companies, whose employees no longer waste time to sort through loads of
* spam before work can be done

IF spam should go away, who loses:

* back bone providers will lose about half their market
* BOTnet providers will lose most of their market, leaving only virus and
  attack parts
* virus writers would lose their main source of income
* ISPs would lose the market for filtering services
* spam-filter companies would lose their whole market
* spammers would lose their income
* politicians would have less excuse for controlling the Internet
* some businesses would have to find more expensive advertising channels

So, why do you think spam would ever go away. Who would want it to go away?

Sten Carlsen


More on Metro software fire (Epstein, RISKS-24.63)

<"Daughtrey, H. Taz" <DAUGHTHT@CS.JMU.EDU>>
Mon, 16 Apr 2007 18:47:35 -0400

I have yet to discover the exact nature of the software "designed to monitor
the flow of electricity" and would appreciate any more details.

Follow-up coverage indicated the problem software was in the newest model
(6000-series) cars, as well as older (2000- and 3000 series) cars that
Alstom was contracted to refurbish. Metro operates a total of 190 cars with
the monitoring software package that malfunctioned. Officials had replaced
the software with an older version in about 150 cars by Friday, April
13. The previous version of software was to be reinstalled in about 40
additional rail cars during offpeak hours Friday night and Saturday
morning. Reverting to the old software takes about 20 minutes for each rail
car, and all fixes were to be paid for by Alstom.
http://washingtontimes.com/metro/20070412-104206-9871r.htm

An extensive December 2006 audit report by the Washington Metropolitan Area
Transit Authority identified deficiencies in Alstom's software quality
processes, but none seem to relate specifically to this problem.
http://www.wmata.com/about/parp_docs/Internal_Audit_Rail_Car_Report_010307.pdf


Re: Washington DC Metro replacing software that causes fires

<"Rieden, Peter \(UK\)" <Peter.Rieden@baesystems.com>>
Mon, 16 Apr 2007 17:07:51 +0100

The "Software causing hardware problems" phenomenon can be a troubling
one. It has been a fundamental tenet of modern systems engineering that the
advantage of software-based systems over hard-wired ones is that additional
functionality can be added at much lower cost, especially in the basic
qualification of the hardware elements. For example consider a mission
computer in a modern military fast jet. This would be initially integrated
onto the aeroplane and in the process it would be tested for all the usual
things - shock, bump, thermal environment, EMC etc etc.  Some time later it
is decided to integrate a new type of sensor array into the starboard
tachyon emitter, and this requires a small amount of additional code in the
mission computer to enable the sensor to be controlled from the existing
pilot controls and to direct the sensor output to the cockpit displays (and
over the sub-ether JTIDS net back to Starfleet HQ).

Now obviously the upgraded mission computer software would have to go
through the normal integration test/qualification process - everyone can see
that. And equally obviously the physical clearances on the mission computer
*hardware* could just be read across, because we haven't changed anything,
have we? After all, we only changed the software. Well unfortunately this
isn't true. Firstly this sensor presents primarily hi-resolution, rapidly
changing video images, so the video processor in the MC is now running at
five times the utilisation that it was with the previous software, and thus
runs hotter. This influences the thermal environment inside the MC and
knocks onto the cooling requirements of other internal sub-systems so that
now the numeric processor overheats and fails after 10 minutes. There are
some people who spot this one, so whilst it's rare it's not unheard of to
consider whether the thermal qualification of the equipment should be
revisited as part of the design process.

But what about the EMC qualification? We've changed nothing *outside* the
box and the new sensor is only communicating over the existing Mil-Std-1553
databus, so this [expensive] testing surely doesn't need repeating. Or does
it? The MC was designed with upgrade capacity in all major respects, and one
of these is I/O - there are a number of unused interfaces or a variety of
types in the I/O subsystem. But that's not a problem because they're all
clamped low in the software. So when an unintended coding error
inadvertently unclamps one of the inputs (a high impedance one) and admits
external signals the condition is not checked in testing. This signal is
then picked up by an adjacent small-signal navigation input which IS used,
and corrupts its data - something that isn't discovered until the system
enters service and is illuminated by Klingon sensor beams.

Of course this is a purely hypothetical case, and has certainly never
happened on any major military fast jet programme in the western world.  Not
ever. No sir, absolutely not! The very idea! But it is perhaps worth
remembering that software changes the characteristics of hardware, so when
designing ANY software change the qualification of the hardware (and the
required test cases) should ALWAYS at least be formally reviewed and
repeated where necessary.

PDR


Re: On "proving NON copyright infringement" (Reinke, RISKS-24.63)

<"Horning, Jim" <Jim.Horning@sparta.com>>
Mon, 16 Apr 2007 12:16:22 -0700

The idea of a digital notary was patented some time ago, and a company
(Surety Technologies, Inc.) started to provide the service.  But it was not
a great commercial success.

http://www.interesting-people.org/archives/interesting-people/199403/msg00100.html
http://www.math.columbia.edu/~bayer/papers/Timestamp_BHS93.pdf
http://www.sciencenews.org/pages/pdfs/data/1995/147-09/14709-15.pdf
http://www.oasis-open.org/committees/dss/ipr.php

  [Also noted by Jeremy Epstein.  PGN]


Re: On "proving NON copyright infringement" (Re: Reinke, R-24.63)

<Norman Gray <norman@astro.gla.ac.uk>>
Wed, 18 Apr 2007 11:45:50 +0100

Ferdinand Reinke suggests a digital notary service, and describes a number
of cases, and a number of keypairs.  There might be a simpler orp
protocol.

1. I want to notarise my wonderful protocol document, before showing it to
   the venture capitalists.  So I send an SHA1 sum of it to the notary.

2. The notary publishes it on a webpage (or a newsgroup or a mailing list),
   along with the list of all the similar sums they've seen today, or this
   week, or this month.  They let the Internet back it up; I'll certainly
   hold on to a copy.

3. At the same interval as the notary publishes that list, they publish its
   checksum in some suitable newspaper of record.

In fact, you could do step 3 yourself, and short-circuit the whole process,
but where's the VC fun in that?

In fact, something like this has been running since 1995, at
<http://www.itconsult.co.uk/stamper/stampinf.htm>.  It's concerned with the
slightly more elaborate problem of corroborating when a document was PGP
signed, and publishes its summaries to comp.security.pgp.announce (the only
thing there apart from spam, as far as I can see).

I fear a single chequebook may continue to be sufficient...

All the best,

Norman Gray : http://nxg.me.uk  eurovotech.org : University of Leicester, UK


Risks of convenience

<"Jay R. Ashworth" <jra@baylink.com>>
Tue, 17 Apr 2007 15:23:58 -0400

It is said that 'security is inversely proportional to convenience', and a
recent contribution to RISKS illustrates this proposition quite well.

In 24.63, David Brunberg, writing on the British crushed car fiasco, says:
> As has been reported elsewhere,
> http://www.cs.cmu.edu/afs/cs.cmu.edu/user/wbardwel/public/nfalist/rip/index.html
> the NFRTR has been in deplorable condition for some time.
> Many registration documents have been lost by ATFE, and some were even
> willfully destroyed by ATFE contract employees in a well documented
> case.

My apologies for the wrapped URL... but lets take a closer look *at* that
URL, shall we?  Oh, my: it seems to be an Andrew File System path, exposed
via the campus's CS department webserver.

Convenient?  Certainly.

But making the individual components of a) CMU's internal DNS and b) the
pathnames of files on individual machines in that domain visible to the
general public at large is a decision that, perhaps, could use some
additional review?

We know now not only that user's internal id, but also the name of his
machine, and several details of his internal directory structure, which
might leak useful information to the outside world.

In this *particular* case, of course, the machine is the central CS machine,
and the file in a user's public subdirectory.  But students or staff at that
university might well be able to take advantage of their knowledge of
internal conventions on such issues...

There's a second possible layer of the same problem in the fact that AFS
uses DNS for it's second address layer, if in fact that's wired into the
protocol -- I'm not that familiar with AFS.

But all these versions of this problem imply a certain requirement for
administrative and architectural care -- designing a network where these
requirements won't leak information useful to a Bad Guy, if possible -- and
possibly also user training -- if you can't tighten things all the way, then
your users will have to exercise due care.

Similar examples exists where @aol.com e-mail addresses are generally usable
for attempting to contact someone via AIM, and where SMS addresses are
generally the same as the voice number for a cellphone; these are both
instances where some circumstances would make it useful for those namespaces
to be disjoint...

Certainly readers can discern other similar namespace overloading situations
for themselves, and intuit the potential problems...

Jay R. Ashworth, Ashworth & Associates, St Petersburg FL USA
+1 727 647 1274  http://baylink.pitas.com  jra@baylink.com


Impossible data requested (... Citizenship No., CJB, RISKS-24.63)

<John Harper <John.Harper@mcs.vuw.ac.nz>>
Mon, 16 Apr 2007 11:52:03 +1200 (NZST)

This sort of thing happens in North as well as South America.  One reason I
closed my US bank account was that I couldn't use its web site because it
insisted on being told my 5-digit zip code. New Zealand and Australia use 4
digits, and UK uses varying numbers of letters and digits, and also a blank
space in the middle. The obvious conclusion was that the bank didn't want
its non-US customers. (The bank wasn't the same one I had opened an account
at in Evanston, IL, when living there for a few months, but was the one that
took over the one that took that one over.)

New Zealand's provinces were abolished in November 1876, but many North
American web sites ask for my state or province. I know which one Wellington
was in, and I duly tell the inquirers, but what do they do with data 130
years out of date?

John Harper, Statistics and Computer Science, Victoria University,
PO Box 600, Wellington 6140, New Zealand   (+64)(4)463 5341


Re: Surely it can't be this easy? (Lee, RISKS-24.63)

<Al Macintyre <macwheel99@sigecom.net>>
Sun, 15 Apr 2007 13:58:58 -0500

I was staying at a major hotel chain, returned to my room to find that the
key card would not work.  I was retrying it, jiggling door etc. when another
guest came to the door.  He had just checked in, my stuff was still in the
room from me getting there earlier.  We went to front desk together to get
this straightened out.

Turns out, the hotel key card system is on a different computer than the
hotel reservations and guest billing system.  They check us in, write down
our # on the little envelope the key card goes in, then in the door security
system, rescramble that door password & the computer writes it onto the
magnetic strip given to latest guest.  When transcribing guest room # from
billing computer to envelope, or into the door security system, in the words
of the desk clerk "Mistakes happen ALL THE TIME."

In our case, they had intended to give the new guest some other room than
the one for me.  There are other combinations of what can go wrong with the
system.  So when you get into your room, be sure to lock yourself in ...
you could be taking a shower, in bed, along comes another guest.

In wee hours, the front desk not attended, you have to ring the bell a lot.
Seems to me the computer systems accessible to some crook who would not ring
the bell.

When I got back home, I told co-workers about this.  It had been on a
business trip.  Co-workers who travel more often than me told me that this
sort of thing is not unusual.


ACM Computer Security Architecture Workshop

<"Jon A. Solworth" <solworth@rites.uic.edu>>
Wed, 18 Apr 2007 23:15:54 -0500

The First ACM Computer Security Architecture Workshop (CSAW, pronounced
SEE-SAW) will be held 2 Nov 2007 at George Mason University in Fairfax,
Virginia, in conjunction with the 2007 ACM Conference on Computers and
Communications.  Papers on system security architectures, their interfaces,
implementations, and implications are due by 17 Jun 2007.  See the website
for details:
  http://www.rites.uic.edu/csaw


USENIX '07 Registration Now Available

<Lionel Garth Jones <lgj@usenix.org>>
Fri, 13 Apr 2007 15:36:00 -0700

2007 USENIX Annual Technical Conference
June 17-22, 2006, Santa Clara, CA
Early Bird Registration Deadline: June 1, 2007
http://www.usenix.org/usenix07/proga

Jeff Chase, Duke University
Srinivasan Seshan, Carnegie Mellon University
USENIX '07 Program Co-Chairs
usenix07chairs@usenix.org


REVIEW: "Measuring ITIL", Randy A. Steinberg

<Rob Slade <rmslade@shaw.ca>>
Tue, 17 Apr 2007 13:12:15 -0800

BKMSITIL.RVW   20070119

"Measuring ITIL", Randy A. Steinberg, 2006, 1-4120-9392-9
%A   Randy A. Steinberg RandyASteinberg@aol.com
%C   Suite 6E, 2333 Government Street, Victoria, BC   V8T 4P4
%D   2006
%G   1-4120-9392-9
%I   Trafford Publishing
%O   888-232-4444 FAX 250-383-6804 sales@trafford.Com
%O  http://www.amazon.com/exec/obidos/ASIN/1412093929/robsladesinterne
  http://www.amazon.co.uk/exec/obidos/ASIN/1412093929/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/1412093929/robsladesin03-20
%O   Audience s- Tech 1 Writing 1 (see revfaq.htm for explanation)
%P   154 p.
%T   "Measuring ITIL"

Chapter one is supposed to be an introduction to the book.  Unfortunately,
it jumps right in without bothering to define some basics (such as what ITSM
is, and why we should want to measure it).  (It probably stands for
Information Technology Services Management, since ITIL, the Information
Technology Infrastructure Library is about that topic.)  Purportedly an
overview of metrics, chapter two is actually an exhortation to measure
things.  Aspects of a metrics model framework are listed in chapter three,
although the details don't do much to explain any overall structure or
operation.

Chapter four is a set of tables of incident response metrics.
Unfortunately, the material is cyclically self-referential, without ever
explaining real details.  Similar non-definitions are given for various
management areas in subsequent chapters: problems in five, change in six,
release in seven, configuration in eight, service desk (no management) in
nine, service levels in ten, availability in eleven, capacity in twelve,
service continuity in thirteen, IT financials in fourteen, and IT workforce
in fifteen.  (If you are well familiar with ITIL you will recognize the
structure, but the book does not explain it.)

Chapter sixteen suggests that if you have very few sources of metrics, then
you should collect and display a few metrics.  Chapter seventeen describes
the DICE (Duration, Integrity, Commitment, Effort) model that attempts to
predict the likelihood of success of an ITIL (the first time the Information
Technology Infrastructure Library is materially mentioned in the book,
despite the title) implementation.  Unfortunately, the text stops short of
really explaining how to use the model, or calculate the parameters you are
to enter.  There is a tiny bit more information on the ITSM Metrics Model
Tool, in chapter eighteen, but unfortunately the detail is on the output
side, rather than input.  Chapter nineteen outlines a full program
(including an enormous staff) for using the metrics, but, since everything
is based on measurements that have not been fully explained, it is hard to
say how useful all of this is.

If you are fully versed in ITIL, this book might help you decide how to
measure your operations.  Mind you, if you are completely familiar with
ITIL, and are using it, you probably already have your own metrics in hand.

copyright Robert M. Slade, 2007   BKMSITIL.RVW   20070119
rslade@vcn.bc.ca     slade@victoria.tc.ca     rslade@computercrime.org
http://victoria.tc.ca/techrev/rms.htm

Please report problems with the web pages to the maintainer

Top