The RISKS Digest
Volume 25 Issue 33

Monday, 15th September 2008

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

Antivirus software in critical systems?
Rob Diamond
Robert P Schaefer
PGN
Re: States throw out costly electronic voting machines
Patrick J Kobly
Re: FAA redundancy — or lack thereof
Mike Martin
Misleading headline: 'Big bang' experiment is hacked
Gabe Goldberg
Change name, get off no-fly list
David Magda
Re: Amos Shapir on Airport Photo ID Checks
Danny Lawrence
iPhone Takes Screenshots of Everything You Do
Brian X. Chen via Monty Solomon
Re: UAL, Automated trading gets spoofed!
Howard Israel
San Francisco officials looking for hidden network device
Gabe Goldberg
PayPal phishes their own customers
Andrew Pam
Re: Risks of better security ...
Chris Adams
Ron Garret on David Bliss
Re: Control-Z vs. Bourne-Again SHell
Philippe Pouliquen
Re: Weird Clock Issue — a single bit error
David Magda
Re: Risks of GPS Devices ...
Sergei Patchkovski
Re: Automated Bill Payments Are a Cinch: Not So Fast
CBFalconer
Sten Carlsen
Erling Kristiansen
Info on RISKS (comp.risks)

Antivirus software in critical systems? (Re: jared, RISKS-25.29)

<Rob Diamond <robd@spin.net.au>>
Mon, 15 Sep 2008 23:14:28 +1000

I've worked in real-time (SCADA) software and related areas for years.  More
and more vendors are using Windoze, for the client UI machines and often for
the servers as well (when *will* they learn ?).  Last year I saw a Denial of
Service attack on some client machines by the anti-virus and configuration
management/license checking software. The user might be in the middle of
dispatching a tech. to a job when the anti-virus software would start up --
the client machine would (almost completely) freeze for several minutes,
until the anti-virus or conf. management software had finished running.
It's incredible that the anti-virus software vendors have no idea about
co-operative multi-tasking — their software grabs the disk by the short
hairs and gets its almost undivided attention until it's finished — while
the shortcomings of the OS task and I/O scheduler are pretty obvious.

Even funnier (you have to laugh or you'd cry) was the initial attitude of
the IT outsourcer — "What's the problem ?  *Our* job is to protect the
machines we supply from viruses and manage the software configuration and OS
updates — and that's what we're doing. If the machines are a bit busy for a
while that's the user's problem. Or buy a more powerful machine."
Eventually the problem was reduced, but not completely eliminated, by
reducing run frequency and cutting back on the checks carried out.

Since this was a public utility with over a million customers the risks of
not being able to dispatch a (possibly safety-critical) job while anti-virus
software runs are pretty obvious.

Rob D. <robd@spin.net.au>  +61-412-607-361


Antivirus software in critical systems? (Re: jared/pgn, R-25.29)

<"Schaefer, Robert P \(US SSA\)" <robert.p.schaefer@baesystems.com>>
Mon, 15 Sep 2008 11:07:07 -0400

Virus installation is not needed for the use of the application, but it is
needed for the development of the application.

What may be going on is the way systems are developed today which perhaps
was not so true 10 years ago.  Many critical systems and embedded systems
are Windows based, you can get Windows on a single card computer, or an
industrial PC, etc. The principal driver is familiarity and cost.  For
software development, the critical system is connected to the corporate LAN
and the Internet, for many reasons, particularly file sharing, corporate
configuration management.  Access to the Internet allows access to vendor's
device drivers, documentation and to register third party code.  You can
even test the system on the LAN from your corporate desktop, once you've
walked over to the lab to flip the power-on switch.  (All sorts of risks
internal to the corporation here with visible IP addresses providing access
to embedded and shared devices.)

Corporate policy for responsible corporations is, if your computer is on the
LAN or the Internet, then Virus protection must be installed, no ifs, ands,
or buts.  The sneaker-net still exists where LAN access is not available for
embedded systems in the corporate world, but today the memory device is the
thumb-drive and no longer the floppy disk.


Antivirus software in critical systems? (Re: Schaefer, R-25.33)

<"Peter G. Neumann" <neumann@csl.sri.com>>

There is usually a huge gap between theory and practice.  It clearly
dominates this discussion.

In principle, voting systems and other critical systems should not be
developed on untrustworthy operating systems with unreliable development
tools and flawed software engineering.

Even more important, election systems should not have to rely on easily
compromisible operating systems — especially when there is essentially no
accountability, poor configuration control, poor documentation, and perhaps
even some Internet access for distributing results or even for voting, as
well as unaudited devices for special user needs or for real-time
operational maintenance.

Anyone with access to such an OS can completely compromise elections — in
the development process, in configuration and set-up, and in execution.
More than anything else, we need trustworthy operating systems and
trustworthy application software with thorough accountability.  But that
is still nowhere near enough, considering all of the extrinsic problems
in registration, voter authentication, and so on.

Similar concepts should apply to critical infrastructure systems — many of
which somewhat surprisingly have live direct or indirect Internet
connections.  By contrast, consider gambling systems — which are held to an
enormously higher standard.

Antivirus software should be unnecessary by construction of those systems.
HOWEVER, in practice, Robert implies, well, that's impossible because that's
just the way it is.  That is a terrible state of affairs.


Re: States throw out costly electronic voting machines (RISKS-25.30)

<Patrick J Kobly <patrick@kobly.com>>
Thu, 11 Sep 2008 20:02:35 -0600

One of the frustrating things about this discussion has always been how few
people who comment on the subject are actually aware of the history.

I would suggest that anybody who thinks that open source will be able to
provide the solution to the disaster that is eVoting read about why Jason
Kitcat shut down the GNU.FREE (Free Referenda & Elections Electronically)
project in 2002.

http://www.free-project.org/files/free_software_odyssey.pdf

As an aside, the suggestion that jurisdictions ought to provide existing
equipment to researchers is a non-starter.  Contractual (and legislative)
restrictions on the jurisdictions exclude them from providing access to this
equipment.

Patrick Kobly, 56 388 Sandarac Dr NW, Calgary, Alberta T3K 4E3
http://www.kobly.com 1-403-274-9033

  [The contractual restrictions may get changed sooner than you think,
  at least in certain states.  PGN]


Re: FAA redundancy — or lack thereof (PGN, RISKS-25.31)

<"mike martin" <mke.martn@gmail.com>>
Sun, 14 Sep 2008 09:35:11 +1000

The outage on 26 August in the FAA Flight Planning System was more likely
due to a design deficiency than, as reports claimed, lack of capacity or
redundancy.

I struck a similar issue some years ago with a real-time system that drove a
large number of NCR automatic teller machines. The machines were capable of
processing withdrawal transactions while off-line to the central computer, a
measure intended to provide a degree of customer service in the event of
central computer or communication link failure.

As first implemented, if the central computer went down for any length of
time it was virtually impossible to bring it back up again. Every time we
tried it would collapse under the onslaught of accumulated off-line
transactions in the ATMs that were waiting to be posted.

The subsequent report from Gabe Goldberg suggests that something similar
happened with the FAA system. He quotes FAA spokesman Paul Takemoto:

"Basically, all the flight plans that were in the system were kicked out,"
Takemoto said... The system switched to the FAA's backup flight planning
computer in Salt Lake City, which was quickly overwhelmed by airlines trying
in vain to enter flight plans. "They just kept hitting the 'Enter' button.
So the queues immediately became huge," Takemoto said. "On top of that, it
happened right during a peak time as traffic was building. Salt Lake City
just couldn't keep up." The Georgia computer was fixed in two-and-a-half
hours but it wasn't until the FAA asked airlines to stop filing flight plans
that the backlogs started to clear.

Yes, you _could_ build in sufficient capacity and redundancy to handle the
anomalous peak. Or you could do what we did with the ATM system, and
sequence the start-up so that communication links were brought online
progressively, presenting a load that remained within maximum processing
capacity.

Presumably the next generation flight planning system will be design to
fail-over seamlessly, thus avoiding an accumulation of backlog transactions.
Then this problem will never happen again — until it does.


Misleading headline: 'Big bang' experiment is hacked

<Gabe Goldberg <gabe@gabegold.com>>
Mon, 15 Sep 2008 11:25:53 -0400

After hackers inserted a message onto the CERN website, a spokesman for CERN
(which houses the Large Hadron Collider, LHC) said that "The computer is
used to monitor one of the experiments at the LHC, it's nothing to do with
the LHC accelerator itself or any of the control systems."
  http://news.bbc.co.uk/2/hi/technology/7616622.stm

So the collider wasn't hacked. But was the Web site hacked or was an
experiment control system hacked?  Unless they're experimenting with Web
servers, those are different...

  [Well, the monitoring system is only a Collide-O-Scope, so perhaps what
  you see is only an apparition anyway?]


Change name, get off no-fly list

<David Magda <dmagda@ee.ryerson.ca>>
Fri, 12 Sep 2008 09:19:48 -0400

And this illustrates just how completely useless no-fly lists are:

  The U.S. Department of Homeland Security wrote a letter to Labbé in 2004,
  saying he had been placed on their watch list after falling victim to
  identity theft. At the time, the department said there was no way for his
  name to be removed.

  Although Labbé wrote letters to the U.S. department, his efforts were in
  vain, prompting him to legally change his name.  "So now, my official
  name is François Mario Labbé," he said.

  "Then you have to change everything: driver's license, social insurance,
  medicare, credit card--everything."

  Although it's not a big change from Mario Labbé, he said it's been enough
  to foil the U.S. customs computers.

http://www.cbc.ca/canada/montreal/story/2008/09/11/nofly-name.html
http://www.boingboing.net/2008/09/12/canadian-man-changes.html


Re: Amos Shapir on Airport Photo ID Checks (RISKS-25.32)

<"Danny Lawrence" <dantemann@gmail.com>>
Mon, 15 Sep 2008 10:08:26 -0400

> The newly formed U.S. TSA has a serious problem: they have to supply
> Security, but they have no idea how (and it seems that they are unaware
> that nobody else does, either).  But they do know that Security causes
> Harassment, and they do know how to do Harassment.  So the obvious logic
> is, the more Harassment they'd do, the more Security will be produced. QED

Another problem is the blind reliance on "The Rules" without understanding
why "The Rules" are there and what they are supposed to prevent.  Case in
point, a woman with pierced nipples tries to board a plane, and sets off the
metal detector.  The TSA screeners insist that she must pass through the
metal detector without setting it off, instead of noting the nipple rings
and realizing that they aren't a threat.

Admittedly in this case the TSA admitted that its "procedures were faulty",
but didn't seem to think that the screeners did any thing wrong.

http://cbs2.com/local/nipples.piercings.rings.2.686169.html

  [The rules can also be questioned, For example, confiscating a toothpaste
  tube that is 90% empty because the label says 5 ounces seems rather silly.
  But I suppose rules of that kind are intended to prevent screeners from
  using any intelligence.  PGN]


iPhone Takes Screenshots of Everything You Do (Brian X. Chen)

<Monty Solomon <monty@roscom.com>>
Sat, 13 Sep 2008 22:03:37 -0400

iPhone Takes Screenshots of Everything You Do
By Brian X. Chen September 11, 2008 | 1:26:34 PM

Your iPhone is watching you.

If you've got an iPhone, pretty much everything you have done on your
handset has been temporarily stored as a screenshot that hackers or
forensics experts could eventually recover, according to a renowned
iPhone hacker who exposed the security flaw in a webcast Thursday. ...

http://blog.wired.com/gadgets/2008/09/hacker-says-sec.html


Re: UAL, Automated trading gets spoofed! (Re: RISKS-25.32)

<Howard Israel>
Mon, 15 Sep 2008 10:47:15 -0400

"As Tribune Co. and Google Inc. pointed fingers at each other over the
glitch that cratered UAL's stock [on 8 Sep 2008,] blame spread to the
computers that robotically troll the Web for news stories and execute stock
trades automatically."  [Source: Shira Ovide and Jessica E. Vascellaro, UAL
Story Blame Is Placed on Computer, *The Wall Street Journal*, 10 Sep 2008;
PGN-ed]
http://online.wsj.com/article/SB122100794359017593.html?mod=3Dhpp_us_whats_news


San Francisco officials looking for hidden network device

<Gabe Goldberg <gabe@gabegold.com>>
Fri, 12 Sep 2008 15:09:45 -0400

As Deep Throat (Woodstein's, not the movie star) almost said,
"Follow the packets..."

San Francisco officials are trying to find a device on the city's computer
network that was allegedly left there by an IT worker who was jailed for
refusing to divulge passwords to the city network, the IDG News Service
reported on Thursday.

San Francisco network administrator Terry Childs was arrested in July on
four felony charges of taking control of the city's computer network and
locking administrators out. He remains in jail on $5 million bail despite
giving up the passwords to the mayor in a secret jail cell meeting a week
later.

The device, which appears to be a router providing remote access to the
city's fiber Wide Area Network, was discovered on August 28, the report
says.

However, officials didn't know where the device was located and didn't have
the user name and password to access it. When they tried to log in, a
message was displayed that said the system was the "personal property of
Terry S. Childs," according to a screenshot officials filed with the court.

http://news.cnet.com/8301-1009_3-10039650-83.html

  [Earlier items on this case in RISKS-25.24-25).  PGN]


PayPal phishes their own customers

<Andrew Pam <xanni@glasswings.com.au>>
Mon, 15 Sep 2008 12:25:35 +0930

... Your monthly account statement is available anytime; just log in to your
account at https://SECURE.UNINITIALIZED.REAL.ERROR.COM/au/HISTORY. To
correct any errors, please contact us through our Help Centre at
https://SECURE.UNINITIALIZED.REAL.ERROR.COM/au/HELP.

The error.com domain does not belong to PayPal.

Andrew Pam  Serious Cybernetics  http://www.sericyb.com.au/


Re: Risks of better security ... (Garret, RISKS-25.32)

<Chris Adams <chris@improbable.org>>
Thu, 11 Sep 2008 19:21:39 -0400

> The fact that the process started on an insecure page and ended on a
> secure one didn't seem relevant.

I'm a bit surprised that this is considered risks-worthy: this is how web
security should work. It allowed a legitimate user access to a network
resource without distracting away from the actual task they wanted to
perform. It didn't provide a password which had not previously been sent to
the remote server, would not have blindly continued had the x509 checks not
passed, etc.

The drawback appears to be that Ron's Keychain didn't have one of the extra
confirmation options enabled. Password managers have various permutations on
this theme but with the exception of locking when the system is suspended to
disk they're largely false security: if someone untrusted gets physical
access to your computer they might not be able to login to etrade
immediately but they can still trivially install malware, a physical
keyboard sniffer, etc.

Usability is a security feature and I think this is the right balance: more
prompts would lead many users to either disable them entirely or blindly hit
okay, even when they get the one legitimate warning in the flood of
false-positives. The major security improvement I'd make would be adding a
password generator into the browser to make the use of site-specific
passwords even easier.


Re: Risks of better security ... (Garret, RISKS-25.32)

<Ron Garret <ron@flownet.com>>
Thu, 11 Sep 2008 14:57:49 -0700

[In response to a message from David Bliss <david@dbsi.org>, interstitiated
here to simplify reading.  PGN]

>> I find myself at a loss to suggest how this particular risk might have
>> been avoided.

> Really?  How about "prohibit the provision of features to 'remember'
> passwords, the entire point of which being to verify the identity of
> *people*, not *software*"?

Prohibit?  How?

> Or at the very least refuse to use such features.  I do.

This "feature" is enabled by default on OS X.  I was not aware of its
existence until this incident.  As soon as I figured out what had happened I
disabled it (which was in itself a non-trivial exercise).

> I don't think the web designers are the ones guilty of idiocy.

Indeed not.  I never meant to imply that they were.

> (yes, yes, I know you thought you understood how that "feature" worked and
> thought it would prompt you for a different password before helping
> itself.  Surely someone of your experience should know better than to have
> any faith in any software, ever?)

Please read:
  http://cm.bell-labs.com/who/ken/trust.html
and then explain to me how you propose to get along in today's world without
some faith in some software sometimes.


Re: Control-Z vs. Bourne-Again SHell (jidanni/chau, RISKS-25.31-32)

<Philippe Pouliquen <philippe@alpha.ece.jhu.edu>>
Fri, 12 Sep 2008 08:44:56 -0400 (EDT)

jidanni@jidanni.org wrote that
  $ sleep 55; launch_rocket
causes the "launch_rocket" application to run immediately if Ctrl-C is used
during the sleep period, and that replacing the ";" with "&&" cures the
problem.

However, David Chau replied that the "&&" has its own problem with respect
to stopping the sleep command (if the intent is to temporarily halt the
count-down sequence).

It seems to me that this problem can be solved by putting the two commands
into a shell script, so that the Ctrl-C or the Ctrl-Z applies to the script
as a whole, not the individual commands.

This can also be performed on the command-line with:

$ ( sleep 55 ; launch_rocket )

The caveat is that I only tested this on a FreeBSD and on a Linux system,
and that job-control may be somewhat operating-system dependent...

To go a little further, I use the following script for playing music (I have
stripped out the code comments in the interest of brevity):

   for song in *.mp3
   do
     /usr/local/bin/mpg123 "${song}" &
     trap "kill $! ; sleep 1" SIGQUIT
     wait
   done

With the above code, Ctrl-C stops playback completely, Ctrl-Z pauses
playback (fg resumes) and Ctrl-\ (SIGQUIT on FreeBSD) skips to the next
song.  Note that the "sleep 1" after the kill is a hack to allow the sound
card buffer to drain, otherwise the next mpg123 may abort if the sound
resources appear to be already in use.

  [Similar comment noted by Michael Loftis.  PGN]


Re: Weird Clock Issue — a single bit error (Greenwald, RISKS-25.32)

<David Magda <dmagda@ee.ryerson.ca>>
Sat, 13 Sep 2008 11:40:19 -0400

> I have a battery operated clock that syncs via radio signal reception with
> the atomic clock in Boulder ...  It currently shows the correct time (as
> of writing: 9:05 PM EDT) but shows the date as Saturday September 27th
> 2008 instead of the correct date of Monday August 18, 2008!

If you want to know the time, use a clock:
  http://www.radiocontrolledclock.com/radconwalclo1.html

If you want to the know the date, use a calendar:
  http://www.calendars.com/

Which day it is only changes once a day, so you only have to check in the
morning and not have to worry about it changing until midnight. :) Ditto for
day of the week.

  [Well, a caveat is needed.  The date changes somewhere on the planet every
  hour (and in some places on the half-hour).  PGN]


Re: Risks of GPS Devices ... (Brader, RISKS-25.32)

<"Sergei Patchkovski" <serguei.patchkovskii@sympatico.ca>>
Fri, 12 Sep 2008 17:24:03 +0000

>   When you are directed to press a key, you should press and quickly
>   release the key.  (You may need to [hold it] down for a period of time
>   to start a secondary function, when the instructions tell you to do so.)
      [Bracketed PGN correction to simplify the discussion.]

Given the right circumstances, this may be the right design choice to make,
odd as it sounds. A similar approach is often taken on wrist-mounted dive
computers — a short press of a button would activate a more common function
-- such as switching between the current and maximum depth display, or
advancing to the next page of the dive log. A two-second sustained push
would activate a less common function — such as setting the oxygen content
or the surface altitude.

The rationale is simple — making an externally-protruding push button
waterproof is not easy, especially if they have to operate at a few bar
external pressure in a salt-water environment. Having too many of those
buttons may significantly increase the chances the device will leak and ruin
your dive (or worse).


Re: Automated Bill Payments Are a Cinch: Not So Fast (RISKS-25.32)

<CBFalconer <cbfalconer@yahoo.com>>
Thu, 11 Sep 2008 20:36:24 -0400

I have a simpler, and, I believe, safer system.  My bank (and others) allow
you to set up delayed payments from your account, or regular at stated
intervals.  These create checks from me to an organization, identified with
my account number, etc.  This handles everything without any fuss, except
the telephone, which doesn't allow you to set up a constant monthly payment.
The other outlays go on one of two credit cards.  So, each month, I only
need to set payments to the credit cards and the phone co.  I pay the credit
cards off entirely, so they don't have any interest involved.


Re: Automated Bill Payments Are a Cinch: Not So Fast (RISKS-25.32)

<Sten Carlsen <sten@s-carlsen.dk>>
Sat, 13 Sep 2008 13:40:26 +0200

In Denmark the normal function of this system is different:

After the setup of this agreement:

Every month the bank will send you (paper or electronic form) a list of
payments that have been reported by those covered by the agreement and will
be due during the next month.

When this is received you have about 10 days to protest any payment to the
bank; if you do, the payment will not be made and you have to settle the
matter with the other party by other means.

In my case the agreement with the bank is such that if the bank makes an
error, the bank will pay to correct it, if I make the error, I have to take
the consequences. Seems reasonable to me.

Example: you have an account with your hairdresser (usually not big
amounts), one month he has reported to your bank that he wants 20,000.00$
from you. If you sleep and do not read your statement, he will be paid; if
you notice that this is wrong and ask the bank to stop the payment, he is
not paid but you will have to go down there and ask him what ... he is
thinking.

This is a simplified version, there are of course more details to it than
this but this is how it works. This has been available from before online
banking was even possible in roughly the same shape.

The risks of this are not so big specially compared with who takes the
penalty if errors occur. We very rarely hear that this goes wrong.


Re: Automated Bill Payments Are a Cinch: Not So Fast (RISKS-25.32)

<Erling Kristiansen <erling.kristiansen@xs4all.nl>>
Sat, 13 Sep 2008 19:18:10 +0200

An automatic payment scheme like the one described has been in operation in
The Netherlands for many year, to almost everybody's satisfaction.  There
was some reluctance in the beginning, but it subsided rather quickly.

I think the key to success is that you have one month to ask your bank to
undo the transaction, no questions asked. You need not give a reason, you
need not prove that anybody made a mistake.  You may, of course, have to
fight it out later with the company that charged you, if they think you owe
them money.  You can file the cancel request through on-line banking, or go
to your bank branch.

I barely hear about any mishaps or incidents with the scheme. If people know
that transactions can be reversed, the incentive for wrong-doing is greatly
reduced.

An additional advantage is that you avoid the mistakes you might make if you
do the transfer yourself. I recently typed the wrong account number on a
rather large transfer. The bank said they could not reverse the transaction,
and I had to rely on the good will of the erroneous recipient. To my great
relief, he returned the money promptly.

Please report problems with the web pages to the maintainer

x
Top