The RISKS Digest
Volume 21 Issue 77

Wednesday, 21st November 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

FBI targets suspects' PCs with spy virus
NewsScan
A tell-all that ZD would rather ignore
Declan McCullagh via Monty Solomon
Risks with automated counting of ballot papers: Australia
Chris Maltby
Evolution, Thermodynamics, and Software Bugs
William Colburn
Re: Programming error scrambles election results
Paul Terwilliger
Ralph Barone
Richard Stein
Edward Reid
Bob Dubery
Re: Researchers probe Net's 'dark address space'
Scott Peterson
Fun with automated car washes, or the importance of interface design
Aaron M. Ucko
Re: Feds make record counterfeit software seizure
Denis Haskin
Re: Glitch in iTunes Deletes Drives
Paul Ward
Geyser Admin
Re: Sweden's public radio reportedly bans SETI...
Nick Brown
Re: Telephone Area Code
Patrick O'Beirne
Re: Google freely giving out ...
Rebecca Wright
Re: DoS attack on Mac OS9
David Cake
Info on RISKS (comp.risks)

FBI targets suspects' PCs with spy virus

<"NewsScan" <newsscan@newsscan.com>>
Wed, 21 Nov 2001 07:32:53 -0700

The FBI is working on software that could insert a computer virus into a
suspect's computer capable of reading encrypted data.  The software, known
as "Magic Lantern," installs "keylogging" software that can capture
keystrokes typed on a computer.  The virus can be sent via e-mail.  Once on
the targeted PC, it waits for a suspect to launch the Pretty Good Privacy
encryption program and then logs the passphrase used to start the program,
essentially giving agents access to the keys needed to decrypt files.  The
Magic Lantern software is part of the FBI's "Enhanced Carnivore Project
Plan," which operates under the umbrella project name of Cyber Knight.
Electronic Privacy Information Center attorney David Sobel says privacy
issues arise when keylogging results in "overly broad" searches, since it
would be possible to observe every keystroke typed by the suspect, even if a
court order specified only encryption keys.  The FBI has already used a
less-sophisticated version of the software to build the high-profile
racketeering case against Nicodemo Scarfo, but had to manually turn the
system on and off in order to comply with the court order.  [MSNBC/Wall
Street Journal 21 Nov 2001; NewsScan Daily, 21 November 2001]
  http://interactive.wsj.com/articles/SB10062942834030720.htm (sub req'd)

  [Insertion by e-mail probably works well for Microsoft software, which is
  prone to that kind of attack.  Various reports suggest that Magic Lantern
  can also plant itself by penetrating systems.  Penetrability of supposedly
  secure systems has long been noted here, with further risks resulting from
  a weak system that is directly networked to supposedly more secure systems
  (especially if done with single-sign-on authentication).  This may not be
  a case where one good (LAN-)turn deserves another.  PGN]


A tell-all that ZD would rather ignore

<Monty Solomon <monty@roscom.com>>
Tue, 20 Nov 2001 08:39:52 -0500

Declan McCullagh, Wired News, 20 Nov 2001

If you subscribe to any of Ziff-Davis' computer magazines, you may want to
double-check your credit-card bill next month.  Ziff-Davis Media, which
publishes such popular tech titles such as Yahoo Internet Life and PC
Magazine, accidentally posted the personal information of about 12,500
magazine subscribers on its website.  On 19 Nov 2001, ZD removed the data,
which included hundreds of credit-card numbers, and said its engineers had
taken steps to prevent additional security leaks.
  http://www.wired.com/news/ebiz/0,1272,48525,00.html


Risks with automated counting of ballot papers: Australia

<Chris Maltby <chris@sw.oz.au>>
Tue, 20 Nov 2001 16:00:10 +1100

As RISKS readers may be aware there was a national election in Australia on
10 Nov 2001.  Australian electoral procedures have many features which US
readers in particular would find unusual, but perhaps the most surprising of
all is the method used to elect Senators for each of the states.

A preferential voting system is used (a complete order of preference must be
shown) and those candidates who receive a quota (a proportion based on the
number of positions to be filled) are elected. Any votes surplus to quotas
are redistributed at reduced value, and least preferred candidates are
excluded until all positions are filled. The interested can refer to
http://www.aec.gov.au/pubs/factfiles/factsheet7.htm or the truly masochistic
to the legislation which specifies the counting method.
 http://scaleplus.law.gov.au/html/pasteact/0/57/0/PA003450.htm

In a normal half-senate election, 6 senators are elected, meaning that a the
quota value is about 14.3% — within the bounds of possibility for smaller
parties.

With a trend toward an increased number of candidates, a simplification was
introduced in the late 1980s whereby political parties could nominate a
preference "ticket" and the voter can choose the party ticket by voting in
boxes above a thick line which divides the ballot paper. Alternatively the
voter can number all the squares below the line (65 in all in the recent
election in New South Wales).  Since its introduction, the number of voters
using the above the line method has grown at each election and was above 95%
in 2001.

The increase in ticket voting has made feasible the automated "scrutiny" or
determination of the result, and the Electoral Act was amended before the
1998 election to permit this. All that is needed is for the 3-5% of below
the line papers to have their order of preference captured, the total number
of voters who selected each of the tickets and then the legislated method
can be applied and the result determined "instantly" instead of taking
several weeks by the manual method. The taxpayer wins if the time taken to
input the ballots is shorter than the time taken by the manual procedure...

But the risk is in the accountability. In a manual election, each of the
candidates is entitled to appoint an observer (scrutineer) who may check for
irregularities in the process.  It may be mind numbingly boring, but it is
feasible.

The automatic system is much more difficult. The legislation permits the
scrutineer access only to a record of:
 * the preferences on the ballot-papers ... stored in the computer; and
 * the ballot-papers that ... are transferred at each count; and
 * the progress of the count of the votes, at each count.

Note that the source code of the software which determines the result nor
its operating environment are explicitly not available for scrutiny, meaning
that each scrutineer must be able to reproduce the process independently to
sufficient accuracy to detect errors or fraud (refer to the legislation link
above).  Also the scrutineer(s) must attempt to observe the accuracy of
hundreds of data entry staff as they enter the ballots at full speed.

As the result can be affected by cascading differences triggered by tiny
numbers of votes changing the order of exclusions, it's probably only a
matter of time before there is a very interesting case in the Court of
Disputed Returns.


Evolution, Thermodynamics, and Software Bugs

<"Schlake ( William Colburn )" <schlake@nmt.edu>>
Mon, 19 Nov 2001 13:25:00 -0700

(Re: Programming error scrambles election results (RISKS-21.74)

There is an interesting paper I recently read.  It shows that biological
evolution is just like debugging.  Selective pressure, such as poison
(debugging), on a biological system will kill as few members as possible to
keep the system stable.  Software bugs are the same way.  Debugging is a
selective pressure (selected by the debugger to meet their expectations) and
will remove as few software bugs as possible.

See "Murphy's law, the fitness of evolving species, and the limits of
software reliabilty", at:
  http://www.ftp.cl.cam.ac.uk/ftp/users/rja14/babtr.pdf

The authors webpage is at:
  http://www.cl.cam.ac.uk/~rja14/


Re: Programming error scrambles election results (RISKS-21.75)

<Paul Terwilliger <pault@gsinet.net>>
Mon, 19 Nov 2001 15:56:13 -0500

Both Mr. Marson and Mr. Kos, in their comments about the San Bernardino
election problem, make a common mistake.

There is programming, and there is programming.

"Programming" an election is not writing software.  It is akin to
programming a VCR.  In other words, entering data to describe the layout of
the ballot.  Sometimes vendors do this, sometimes county employees do.

(Even though I do not know which particular vendor's equipment was used, all
are alike in this regard.)

Does this make testing unnecessary?  Of course not.  But let's make sure we
understand where the failure was.

Paul Terwilliger, Sequoia Voting Systems, Inc.


Re: Programming error scrambles election results (Marson, RISKS-21.74)

<"Barone, Ralph" <Ralph.Barone@BCHydro.bc.ca>>
Mon, 19 Nov 2001 14:08:47 -0800

I believe that in order to truly test a piece of software, at least two
testers are needed.  The first would be somebody with a complete enough
understanding of the problem that he/she could have coded the program
themselves.  This person would review the code for logical errors,
robustness of algorithms, etc...  The second tester would be a person with
minimal knowledge of the system (representative of the least trained person
ever likely to operate the system).  This person will unwittingly test all
the user interface and data checking assumptions made by the original
programmer.


Re: Programming error scrambles election results (Marson, RISKS-21.74)

<Richard Stein <rstein@sgi.com>>
Mon, 19 Nov 2001 16:13:00 -0800

If you want to know the cost of quality, prepare to purchase it!

A 'real' software test engineer, one who is exceptionally knowledgeable of
the fundamental technology mechanisms residing at the core of modern
products (like threads, synchronization, scheduling, signals, process
tracing, message passing, VM, etc.) is mighty, mighty rare and plenty
expensive.

Certain cultural and educational barriers forestall the creation of many.
Peer ostracism, managerial indifference, and professional lassitude often
conspire against this career choice.

The best folks prefer product engineering (aka 'development'). Hell, a good
test engineer must continuously author and develop test assets well ahead of
any product engineering activity.  In the past 7 years, I have authored in
excess of 400Kstatements of PERL/C/C++ comprising thousands of individual
functional test assets and dozens of reliability evaluations.  I know kernel
hacks who have struggled for months to find a 1 line race condition fix
arising from a wimpy program.

Creating non-deterministic product evaluations that compel races, corrupt
data, generate deadlock, cause resource leakage, panic, coredump, or other
fatal conditions is more of an art than a method.  No matter how stupid or
non-sensical an input, a product must remain deterministic and
self-consistent (this is the famous user-is-an-idiot postulate).

Deterministic evaluations consume substantial test engineering cycles: all
those inputs, a little product logic, and assertions of output takes many
keystrokes.  Such exhaustive measurement is often the only means to show
program feature and function correctness.  What I'd give to out-think Alan
Turing on this issue!

Many for-profit organizations do not really understand that test engineers
author intellectual property too: IP the customer does not purchase, but
what they experience as a consequence of test asset quality ; If the test
assets stink, the product stinks.

That's what test engineers do — function as editors (as in newspaper
publications) to raise product IP quality.  To be successful, test engineers
must embody the worst customers in the world, and the best friend a product
can have.  The only acceptable customer feedback is a purchase, not a
complaint.

How does proactive test engineering compare to a 'nuclear' customer support
hotline post-release?  Its hard to query corpses — especially dot-bombs.
If management believes any warm body will suffice to successfully and
thoroughly evaluate 1Mline+ C++ software toxic wastedumps, dig up a corpse
from a cemetery and apply a space-heater, but don't hire a button pusher.

We all know its far cheaper to fix bugs in the system before release, and
even easier/cheaper when in the earliest SDLC phases.  But testing and other
means to ensure quality are often short-changed because of disciplinary
failure and organizational, ethical lapses — covert institutionalized
violence.

Richard M. Stein, StudioCentral Test Engineering Contractor  650-933-7391


Re: Programming error scrambles election results (RISKS-21.75)

<Edward Reid <edward@paleo.org>>
Tue, 20 Nov 2001 10:50:03 -0500

Takes a lot more than understanding the problem, etc.. The person who really
understands the problem is generally only going to enter expected, correct
data for the problem domain. The programmer tends to be limited by the
expectations of the program, the skilled user by the expectations of the
problem domain. Good testing is a different skill. If you want a program to
be ready for prime time, get it tested by someone skilled in testing. Of
course the tester must know something about the problem domain, and testing
by both the programmer and the skilled user are valuable too.  But testing
is a skill in itself.


Re: Programming error scrambles election results (Kos, RISKS-21.75)

<"Bob Dubery" <bdubery@netcare.co.za>>
Tue, 20 Nov 2001 07:37:47 +0200

> nobody (not even I! ;) can be relied on to find their own bugs.

And also there is less chance of them LEARNING from their bugs - so the
"method" behind the bug tends to propagate.

I had been arguing about the existence of a bug with two programmers from
another dept in the IT organisation that I work for.

Eventually I got to take a peek at the code in which - according to me - the
bug had to exist. I found it in minutes. The programmer concerned had
written code that ignored a lock in the database with the result that
updates were sometimes "lost" if two instances of the code were running
simultaneously.

When I showed the programmer (a junior person) who wrote the code the bug
and explained it she quickly grasped the flaw in her logic and went off to
check several other bits of work she'd done to see if she had reproduced the
bug. She now also understands a particular aspect of her job and the
language she works with better than she used to.

A test in a multi-user scenario and/or a code review would have quickly
uncovered a bug that caused some acrimony and a loss of money - and would
have resulted in a programmer who had had improved their craft.

One of the RISKs of not having code reviews and good test procedures in
place is that inexperienced junior programmers will become poorly
experienced senior programmers and the bugs will propagate.


Re: Researchers probe Net's 'dark address space' (Poulsen, R-21.75)

<Scott Peterson <scottp4@mindspring.com>>
Mon, 19 Nov 2001 14:29:19 -0800

I'd suggest that a large part of this is due to explicit blocking of IP
ranges by system administrators.  This could either be local blocks or
published lists like MAPS or SPEWS.  Getting on SPEWS, for example will
make about 30% of the Internet unreachable if you get listed.

Also, for cable modems, I'd think a  large part of this is the arrogance,
unresponsiveness and incompetence of the administrators of the cable
networks, especially @home.  They've gotten into lots of local block lists
because they won't shut off abusers or even respond to complaints.


Fun with automated car washes, or the importance of interface design

<"Aaron M. Ucko" <amu@alum.mit.edu>>
19 Nov 2001 21:53:57 -0500

My wife and I had an unexpected adventure when we went to get our car washed
at a gas station the other day.  (I am withholding the name of the chain to
protect the not-so-innocent, and because it is probably not the only culprit
anyway.)

First, some background: the system is fully automated, and offers three
levels of operation.  (The cheapest doesn't even dry the car, and the most
expensive includes tire scrubbing and other frills.)  Because we had
recently gotten the car used, we decided to go for "The Works."  Also, the
station offers a discount with the purchase of 8 gallons or more of gas; in
order to get this discount, you need to buy a code for the machine with your
gas.

Anyway, the first problem we encountered came about when ordering: the
display at the pump told us to press 1, 2, or 3 to select a cycle, but did
not specify which was which.  Assuming that it went from cheapest to most
expensive, we pressed 3, only to be told that we had selected the basic
cycle.  Fortunately, it asked for confirmation, so we went back and selected
1 instead.

Next, we drove up to the car wash (which involved waiting in line for a
little while, waited for the previous driver to finish, punched in our code
(for "The Works"), and drove into the machine.  It started to wash our car,
but then stopped in the middle of the cycle — with a little barrier
effectively preventing us from driving out the other side.  (We could
probably have driven over it if we had pressed hard enough on the gas, but
it didn't seem like a great idea.)  The machine appeared to be completely
dead; the screen which normally displays something like "enter," "exit," or
"washing" was blank.

Experimentally, we backed up slightly, at which point the machine told us to
drive forward again; when we were back in the target position, it started
all over — with a basic cycle, which it at least finished properly.  At
that point, we drove out unhindered and went to complain to the management.
We convinced them to give us a new code for "The Works", and returned to the
back of the car-wash line.

When we got back inside the machine, it stopped at the same point as before.
This time, we just gave up and waited for something to happen; after a few
minutes, the attendant came out (at the behest of the driver behind us), and
motioned that we should again drive backwards for a moment and then back
forwards to the target position.  This maneuver again caused the machine to
restart — this time with what appeared to be a "deluxe" cycle.  Since that
cycle included the remainder of the things we wanted, we decided that it was
good enough and that we had wasted enough time there, and so simply drove
off.

Our hypothesis is that both times, the drivers behind us had confused the
machine by entering their codes before we were done — an action which the
interface allows, and even appears to encourage[1] — and that each time we
backed up, it restarted with the cycle the next driver had ordered.

The risks?
  * Poorly presented menus can lead to undesired selections.
  * Badly designed machines can trap their users.  (Note that in this
    case, a Big Red Button would not have sufficed, since it was not
    entirely clear that the machine might not suddenly restart and
    injure whoever got out of the car to push it.)
  * Systems that prompt for input before they are ready for it can
    fail unpleasantly.

[1] After telling one driver to enter, it immediately prompts for another code.

Aaron M. Ucko, KB1CJC <amu@mit.edu> (finger amu@monk.mit.edu)

  [Nonatomic transactions can be quite explosive.  PGN]


Re: Feds make record counterfeit software seizure (RISKS-21.75)

<Denis Haskin <Denis@HaskinFerguson.net>>
Mon, 19 Nov 2001 17:24:49 -0500

Um, perhaps I'm being naive, but it's not clear to me what the "risks to the
public in computers and related systems" is in this case.  Sure, there's a
risk that consumers may be buying software that's not legit, but is there an
allegation that the software is flawed in some way?  Isn't this sort of like
buying a Rolex on a NY street corner?


Re: Glitch in iTunes Deletes Drives (Solomon, RISKS-21.74)

<pasward@styx.uwaterloo.ca>
12 Nov 2001 12:20:39 -0500

NO!  The problem was _NOT_ that some "bleary-eyed coder" missed a couple of
quotes.  The problem was that Apple's process for reviewing software prior
to shipping to catch the _inevitable_ syntactically correct but semantically
flawed code was broken.  And broken badly if such a obvious error could
slide through undetected.

paulward (DrGS)


Re: Glitch in iTunes Deletes Drives (RISKS-21.74)

<Geyser News Server Admin <news-admin@geysers.org>>
Mon, 12 Nov 2001 11:39:04 -0800

Before the Mac haters out there take any glee from this incident, a
clarification is important.

What was left out was the reason why the quotes are important-- On the Mac,
file and directory and disk names can and do contain spaces. With the new
Unix-based OSX, long-time mac users are discovering the hard way that spaces
are used as delimiters in scripts and in parsing, so filenames containing
spaces can have unintended results. Most Unix code samples and docs assume
that no one ever puts spaces in their file names, so the samples never show
quotes being used, and some docs don't mention this need either.

Just about every programmer making the Mac switch from OS 9 to 10 finds
this out the hard way, just not as publicly and catastrophically.

The risk-- changing the underlying behavior of familiar software, and
not being aware of all the assumptions behind that underlying behavior.


Re: Sweden's public radio reportedly bans SETI... (RISKS-21.74)

<BROWN Nick <Nick.BROWN@coe.int>>
Mon, 12 Nov 2001 09:15:43 +0100

I agree that it's unlikely that the US military needs extra Swedish PC
computing power to plot missile trajectories, but the Swedes have been here
before.  In the mid-90s the Swedish parliament and other government offices
acquired Lotus Notes, and one factor in their choice was the "secure"
encryption it provided.  Until they found out that the CIA had a master key.
So the line between "conspiracy theory" and "justifiable paranoia" is
perhaps blurred in this case.

There is also the RISK that in running any code from SETI@home, you are
trusting SETI's site not to be hackable by someone who might want to run
some other code on your computer.  If someone put a replacement client in
there which trashed your hard disk at a given date/time, I suspect the
worldwide damage would put the "ILoveYou" worm to shame.


Re: Telephone Area Code (Hecht, RISKS-21.74)

<"Patrick O'Beirne" <pobeirne@sysmod.com>>
Mon, 12 Nov 2001 09:16:35 +0000

> I can't find a way, in the *import* function, to define these numbers as
> "text" so that Excel will leave them alone upon import.  Sigh.

Text Import Wizard step 1 - choose fixed/delimited
Step 2 - column breaks
Step 3 is where you set the column format - choose Text for IP addresses

http://www.sysmod.com/spreads.htm
Patrick O'Beirne B.Sc. M.A. FICS


Re: Google freely giving out ... (Re: Ziglar, RISKS-21.75)

<Rebecca Wright <rwright@research.att.com>>
Tue, 20 Nov 2001 17:37:45 -0500 (EST)

Listings can (at least now) be removed using a form found at
http://www.google.com/help/pbremoval.html, which was linked to from the
"More phonebook listings" on my Google telephone listing.  This form itself
is not without risks.  First, they require (off-line) authentication only
for removal of business sites, so individuals can have their listings
removed by others even if they would prefer to have their listings remain.
Second, your communication with Google about your phone listing can actually
help them establish its correctness (and they ask for your e-mail address
too), so depending on your trust level in Google to handle your personal
information, you might consider it better to remain silent than to
voluntarily give them verified information about yourself.

  [RISKS received a Google-plex of e-mail on this subject.
  This information is widely available on the Internet, on CD-ROM,
  etc.  Thanks to all who responded.  PGN]


Re: DoS attack on Mac OS9 (Gat, RISKS-21.73)

<David Cake <dave@difference.com.au>>
Mon, 12 Nov 2001 13:31:52 +0800

>Sure, you can change passwords if you have physical access to the machine.
>You can also boot any Mac with a MacOS 9 CD and completely circumvent all
>protection.

Firmware security can make it much more difficult to boot from a MacOS 9 CD
(or any other bootable CD), and avoids some similar simple methods of
circumventing password authentication (booting in single user
mode). Firmware security is a recent, and poorly documented, addition to the
Macintosh that is not present on all models, and on many machines will
require a firmware update. It is a significant protection against the
casual, Macintosh capable but not truly expert, attacker, and is thus
probably a good idea for situations such as unattended kiosks or laboratory
machines. It cannot, however, be completely relied on.

There are two methods to bypass firmware security.  One is a reasonable and
prudent method - if you change the RAM in the machine, it also resets the
firmware security. Perhaps there will be unintended consequences from those
are unaware of this poorly documented side effect, but it is necessary that
there be some means of disabling the feature to prevent machines being
rendered unbootable, and it is appropriate that it be some feature that
requires access to the internals of the machine for a reasonable amount of
time. If you are in a situation where firmware security is an issue, you
should also be implementing physical security (Apple generally makes it easy
to secure access to the case with a padlock or similar on most models).

Unfortunately, there exists a weakness in the implementation of the firmware
security that enables the dedicated attacker to discover the Open Firmware
password and thus bypass this protection, and a program to exploit this
vulnerability is available.
http://www.securemac.com/openfirmwarepasswordprotection.php

Luckily, it runs only under Mac OS 9, so Mac OS X machines are relatively
safe (it does not run under Classic), but this cannot be relied upon, as the
same underlying vulnerability exists and it is simply a matter of someone
writing code to exploit it.

Apple does appear to be gradually increasing the amount of
security, and  definitely appear to be treating security on Mac OS X
as a serious issue. Unfortunately, there are still some weaknesses
that have been discovered.

David Cake (Macintosh and Unix consultant), Difference Engineering

Please report problems with the web pages to the maintainer

x
Top