The RISKS Digest
Volume 22 Issue 74

Wednesday, 28th May 2003

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…


Soyuz landing problem caused by software?
Steve Bellovin
The "no-fly" list
Steve Bellovin
Scientific American article "Self-Repairing Computers"
Charles Lamb
Microsoft Pulls XP Update
Dave Aronson
Modern Computers, Unsafe at any speed?
Len Spyker
Privacy advocates doubt Pentagon promises on spying
'Kingpin' cracker arrested in Thailand
Ex-student fined more than $500,000 for stock fraud on Net
Safe-cracking via telephone
Lee Hasiuk
Re: OpenBSD ... protects against buffer-overflow ...
Crispin Cowan
Dag-Erling Smorgrav
Comment on BMW/MSFT failure reported in Risks 22.73
John Opie
Spam's cure could be worse than the disease
Spam limiting
Harry Hochheiser
Re: more spelling-checker follies?
Anna Shefl
REVIEW: "Protected Internet, Intranet, and Virtual Private Networks", Alexander Moldovyan et al.
Rob Slade
Survivable and Self-Regenerative Systems: workshop
Doug Maughan
Info on RISKS (comp.risks)

Soyuz landing problem caused by software?

<Steve Bellovin <>>
Mon, 05 May 2003 21:41:08 -0400

In an article by James Oberg — a well-respected space programanalyst --
MSNBC reports that the cause of the Soyuz module landing far off target was
a software glitch.  (

To achieve the proper landing profile, the craft is supposed to fly with the
top of its heat shield tilted forward, to provide a bit of aerodynamic lift.
Steering is done by rotating the capsule — the center of mass is
off-center, whcih means that rotating the Soyuz will steer it.

This scheme means that the Soyuz needs to know which way is up.  The Soyuz
lost track of either its orientation or its position, and switched to a
backup mode.  In the backup setting, the craft just rotates at a constant
speed, which stabilizes the spacecraft, but at the cost of path control.

Other suggestions are human error — perhaps "one of the Americans" hit the
backup mode button.  The American astronauts deny this.

They did know what was going on; however, they had enough confidence in the
backup system that they chose to accept the off-target landing rather than
try to recover manually.

Steve Bellovin, (me)

The "no-fly" list

<Steve Bellovin <>>
Fri, 25 Apr 2003 23:03:58 -0400

The 22 Apr 2003 *Wall Street Journal* had a long article on the U.S.
"no-fly" list — a list of about 300 people that the U.S. government regards
as too dangerous to allow on airplanes.  Apart from anything else, the
article discussed the many ways this system is producing false positives and
(one would assume) the chance of false negatives.

The article is too long to summarize; among the problems cited are the
difficulties of transliteration from Arabic (they show five different
renderings of one name) and use of computer systems designed for different
purposes.  For example, some of the systems used hunts for matches based on
the first few letters of a surname — ideal for helping someone check in
quickly, but not good for checking against a "no fly" list.  Nor are the
error recovery processes good; there are some people who will *always* run
afoul of this on certain airlines, but they seem incapable of recording that
they've checked out particular individuals the previous time.

Steve Bellovin,

Scientific American article "Self-Repairing Computers"

<Charles Lamb <>>
Thu, 22 May 2003 17:02:40 -0400

There is an article in the June 2003 issue of "Scientific American" titled
"Self-Repairing Computers" by Armando Fox and David Patterson.  The article
seems to me to just be rehash of decades old programming practices such as
audit trails, system snapshots, and robust software.  These practices were
often found in mainframe computer software but seem to have been abandoned
when PCs came along.  I suspect this is because mainframe computer time was
so much more expensive than PC time that it was worth using more wisely.

Microsoft pulls XP update

<Dave Aronson <>>
Wed, 28 May 2003 14:06:19 -0400

Microsoft Corp. said on 27 May 2003 that it has withdrawn a security update
for its Windows XP software after discovering that it switched off Internet
connections for some of the 600,000 users who downloaded and installed it.

Source: Reuters.  More details at

Yet another RISK of being an "early adopter" — especially where a company
has a "wait for release x.1" reputation....

David J. Aronson, Unemployed Software Engineer near Washington DC

Modern Computers, Unsafe at any speed?

<"Len Spyker" <>>
Sun, 25 May 2003 10:25:02 +0800

Periodically we see new emphasis placed on the notion that computers need
specific hardware support in order to be secure. So it's odd that when a
topic like stack buffer overflows gains common awareness we (the computer
commumity) can always point to a long ago hardware architecture that solved
this problem.

It is not like we don't know how to make computers safe. Maybe some of us
have buckled to commercial greed, or be unwilling to accept that hardware
architecture of 30-50 years ago is still valid today.

I do marvel at my new 1 GHz CPU with it's 30+ million transistors, but I
gringe that not a single one is dedicated to preventing the stack from
running riot over my own data and code. Or if it had any then the OS writers
left it disabled. "Look Ma - no hands".

I feel that the computer industry and PC users are now at the same point
that the American Automotive industry was with Ralph Nader some 30-40 years
ago. " Unsafe at any speed". But sadly there is no champion now, no one
dares to expose that the PC Emperor has no clothes.

The irony is that with proper hardware protection the OS and apps would run
faster because all that software now wasting CPU time checking for overflows
is no longer needed, and even the most baroque but popular languages could
safely co-exist with secure applications.

The only possible good effect from this war on terror is that the OS writers
and their bosses may be forced to fully use the hardware protection
available and the Silicon designers forced to read some history books and
re-invent the hardware wheel.

To correct the current unsecure PC situation will take a major government
action and wether it is done by force of law, at legal gun point or by
chucking lots of money at the suppliers to correct their earlier sins and
omissions, only time will tell.

Len Spyker, 49 Jeanes Rd, Karrinyup, WA Australia  +61 8 9245 1771

Privacy advocates doubt Pentagon promises on spying

<"NewsScan" <>>
Wed, 21 May 2003 09:20:33 -0700

The Pentagon has changed the name of its planned anti-terrorist surveillance
systems, but critics say the fundamental program remains the same and would
risk violating citizens' privacy if fully implemented. Now renamed the
Terrorist Information Awareness program (from Total Information Awareness),
the system would broaden government surveillance activities to encompass
passport applications, visas, work permits, driver's licenses, car rentals
and airline ticket purchases as well as databases including vast amounts of
personal information, such as financial, education, medical and housing and
identification records. Sen. Ron Wyden (D-Ore.), a major opponent of the
TIA, says, "What most Americans don't know is that the laws that protect
consumer privacy don't apply when the data gets into government's
hands. Lawfully collected information can include anything, medical records,
travel, credit card and financial data." Testing of the system is already
underway, raising privacy advocates' concerns about "false positives" based
on erroneous data. "If TIA is relying on personal information contained in
databases to determine whether someone is a suspect, what recourse does that
person have whose information has been entered incorrectly?" says a
spokeswoman for the Free Congress Foundation, which estimates that an error
rate as small as .10% could result in more than 30,000 Americans wrongly
being investigated as terrorists. [AP 20 May 2003;NewsScan Daily, 21 May 2003]

'Kingpin' cracker arrested in Thailand

<"NewsScan" <>>
Fri, 23 May 2003 08:29:25 -0700

Thai officials arrested a Ukrainian man described by a U.S. embassy
spokesman as a "kingpin" of international computer crime. Maksym
Vysochansky, 25, is accused of selling counterfeit versions of flagship
software products by major companies such as Microsoft and Adobe.
Vysochansky, who used a number of aliases, is thought to have been involved
in fraudulent schemes worth up to $1 billion. "This guy was on the U.S.
Secret Service's 10 most wanted list. He's definitely a big shot," said the
embassy official. Authorities allege that Vysochansky also built a "back
door" into the software he sold that allowed him to hack into buyers'
financial and credit card information. "It was a very complicated and
sophisticated fraudulent scheme," said the embassy official. Vysochansky
likely will be extradited to the U.S. where he'll face charges of copyright
violations, trafficking in counterfeit goods and money-laundering.
[ 22 May 2003; NewsScan Daily, 23 May 2003],,2-13-1443_1362931,00.html

Ex-student fined more than $500,000 for stock fraud on Net

<"NewsScan" <>>
Thu, 22 May 2003 08:02:27 -0700

Former UCLA student Refael Shaoulian has been ordered by a federal judge to
pay $534,000 in fines for using university computers and false identities to
post intentionally incorrect about stocks so that he could profit from the
buying and selling sprees he caused. The civil suit was brought by the
Securities and Exchange Commission.  [APOnline/*USA Today*, 22 May 2003;
NewsScan Daily, 22 May 2003]

Safe-cracking via telephone

<Lee Hasiuk <>>
Thu, 22 May 2003 10:46:50 -0400

My elderly aunt owns a large, heavy safe whose combination was lost when her
husband passed away.  She asked me if I could help her open it.  I called
the manufacturer and found that they offer a service where they will give
you the combination for $35, which may be charged to any major credit card.
All you need to provide is the safe's serial number, which is embossed on a
plate in the center of the combination dial.  They have no way of checking
if you are the owner of the safe, and indeed I wasn't.  The entire
transaction took place over the phone.  I've yet to try the combination they
read to me, and the company representative noted that it is possible for the
owner to change it.

I wonder how many thieves have used this safe cracking technique with a pay
phone and a stolen or invented credit card number?

  [Although this is not computer related, it is symptomatic of back doors in
  many security systems.  The manufacturer is probably smart enough to first
  verify that the credit card is legitimate, although it could have belonged
  to the owner of the house that was being burgled.  However, if we assume
  that the owner had changed the default delivered combination, then this
  supposedly beneficial service would not help — unless there was an
  unchangeable master combination IN ADDITION TO the user-set one.  PGN]

Re: OpenBSD ... protects against buffer-overflow ... (Ardley, R 22.72)

<Crispin Cowan <>>
Sat, 10 May 2003 19:19:12 -0700

>What is not so apparent is why technology that was developed and operating
>over 30 years ago is just being re-invented in software.

Because what was developed in operating systems over 30 years ago was use of
heavily segmented architectures. Over 20 years ago (the Intel 432) it was
discovered (the hard way) that such architectures run horribly slowly
compared to RISC architectures. Since the debacle of the 432, even CISC
processors such as the x86 have migrated towards RISC style instruction

What OpenBSD is implementing is a variety of software schemes to make up
for the lack of hardware protection for array bounds. Some of these
schemes (Openwall's <> non-executable stack) are
performance neutral: just mark the stack segment non-executable. Some
(ProPolice, a re-implementation of StackGuard
<>) are very cheap
<>, much cheaper than
enforcing memory safety in hardware.

Unfortunately, one of these enhancements (W^X) is not so cheap. Here,
they try to make all writable pages non-executable, and vice versa. This
is problematic on the x86 architecture because waaaay back in the day,
Intel decided that memory pages did not need separate Read and Execute
permission bits in the TLB (only segments have separate R and X bits,
not pages). The W^X hack has to do a lot of work with TLB faults to
compensate for this simple omission.

>The Burroughs 6700 implemented a hardware solution to the problem by
>assigning 3 bits of very 51 bit memory location to the type of data

The 432 did something similar, and the performance penalty was
astronomical. For a survey of buffer overflow attacks and defenses,
check out these papers:

  "Buffer Overflows:  Attacks and Defenses for the Vulnerability of
  the Decade". Crispin Cowan, Perry Wagle, Calton Pu, Steve Beattie,
  and Jonathan Walpole. DARPA Information Survivability Conference and
  Expo (DISCEX) <>, Hilton Head
  Island SC, January 2000. Also presented as an invited talk at SANS
  2000 <>, Orlando FL, March
  2000.  PDF <>.

  "Software Security for Open Source Systems". Crispin Cowan. IEEE
  Security & Privacy Magazine <>,
  February 2003, Volume 1, Number 1
  pages 35-48. PDF

Crispin Cowan, Ph.D., Chief Scientist, Immunix

Re: OpenBSD ... protects against buffer-overflow ... (Ardley, R 22.72)

<Dag-Erling Smorgrav <>>
Wed, 21 May 2003 10:27:23 +0200

I was rather disappointed to see that the attached e-mail, which I sent as a
followup to Jeremy Ardley's comment on "OpenBSD release protects against
buffer-overflow attacks" in 22.72, was not included in 22.73.

Jeremy Ardley made at least two serious factual errors: misidentifying the
FreeBSD project (of which I am a member) with the OpenBSD project [*], and
making incorrect assumptions (or wild guesses if you prefer) about Intel's
IA32 architecture on the basis of the original article.  My followup was
intended to correct those errors and give RISKS readers a somewhat better
understanding of the matter.

I was even more disappointed to see that 22.73 contained a further followup
by Mike Albaugh which not only builds on Jeremy Ardley's incorrect
assumptions about the IA32 architecture but furthermore does not (in my
eyes) contain any useful information about any kind of RISK.

Dag-Erling Smorgrav -

  [* This error has been corrected in the SRI archive copy, and
  will be picked up in the Newcastle archive.  PGN]

Comment on BMW/MSFT failure reported in Risks 22.73

Wed, 21 May 2003 08:54:04 +0200

As someone who has professional ties to BMW (I work with Germany's largest
private economic research group, which among other things provides the
Quandt family - which own 48.1% of BMW - with investment advice) as well as
having learned to drive on one (2002) and just order my third 5 (a 525td
after a 530d and a 528i) series as a company car, there are a couple of
points I'd like to make. I might be a tad biased 'cause I enjoy driving
these cars so much (the 528i handled 240kmh with ease, but for fuel economy
I will accept the top speed of 220 in the 525td...).

First, the 5 series does not use any MSFT products to run the car's systems.
There are two Motorola PowerPC chips in the 5 series, one which runs the
engine and the other takes care of the on-board electronics, which in turn
run embedded systems that react to environmental changes (air conditioning)
or to user changes (power windows, etc.). The on-board navigation system
(getting one in the new car...) also uses an embedded, proprietary system.

Second, BMW 5-series cars include as a standard safety feature a mechanical
interlock. If there is an accident or if there is an interruption of power
lasting more than a few seconds, this interlock unlocks the doors in an
event of an accident (determined by motion sensors and/or inflation of
airbags), so that in case of locked doors and a driver accident which
prevents the driver from unlocking the doors, rear-seat passengers are not
trapped. They do not open the doors (there is an option for power-assisted
door closing and opening...) but this does ensure that in case of accident,
no one gets trapped. As a matter of fact, if there is an accident of enough
severity to cause a set level of deformation in the motor cell, a small
explosive charge will separate the battery of the car from the electrical
system, preventing any electrical-caused fires in the wake of an accident.

Third, the new 7-series uses a version of WinCE for its I-drive. The new
5-series (with the Dr. Spock eyebrow blinkers) also uses a modified version
of this as well. Both are heavily modified, for which BMW pays for. There is
no reference to MSFT in BMW's advertising for the 7 series or the new 5 (at
least I haven't seen any...)

But more fundamentally, and here is where risks come in, what should the
default behavior of an armored limousine be? If I were to design such a
system, the fundamental importance is to protect the passengers. If it
became known that such an armored car would pop its locks when the on-board
system would fail, then a terrorist/assassin/kidnapper could exploit this in
order to gain access to the passengers, either by an EMP trap or some other
manner. Hence if the system failed on the BMW in question - which was most
likely the 7-series armored limousine, which is the only armored limousine
that BMW supplies (I think only in the 745 S and the 760 S versions with 4.5
V-8 and 6 liter V-12 engines with more horsepower than anyone else really
needs) and which would be appropriate for the politician involved - it
defaulted to the correct setup: protect the passengers.

John F. Opie, Feri Research GmbH, Haus am Park, Rathausplatz 8-10 D-61348
Bad Homburg von der Hoehe  +49 (0)6172 916 3216

Spam's cure could be worse than the disease

<"NewsScan" <>>
Tue, 27 May 2003 11:10:30 -0700

CNet columnist Declan McCullagh worries that the proliferation of
spam-blocking software incorporating challenge-response technology could
lead to the death of e-mail. Challenge-response systems require the human
sending a message to perform a simple task such as clicking on a link or
typing a special password to get past the barrier. The problem is, says
McCullagh, that many challenge-response systems are poorly designed, and
could causes big headaches for administrators of legitimate e-mail
newsletters (such as NewsScan Daily) that go out to large numbers of
people. "Big corporations may be able to afford to hire someone to sit in
front of a computer and spend all day proving they're not a spam bot, but
nonprofit groups, individuals and smaller companies probably can't," says
McCullagh. Earthlink has already announced its intentions to make a
challenge-response system available to subscribers by the end of May, and
other ISPs may follow suit — a scenario that has veteran list operators
concerned. Dave Farber, a computer scientist at the University of
Pennsylvania who runs the "interesting people" list, says: "If I start
getting a flood of challenges from Earthlink IPers that require my response
I will most likely declare them spam and you will stop receiving IP mail. I
fully expect this to be the case for almost all the legitimate mailing lists
you are on and count on." Meanwhile, editors at the popular Macintosh
newsletter TidBits, have told readers: "Be warned that we will not answer
any challenges generated in response to our mailing list postings. Thus, if
you're using a challenge-response system and not receiving TidBits, you'll
need to figure that out on your own."  [CNet 27 May 2003; NewsScan
Daily, 27 May 2003]

Spam limiting

<Harry Hochheiser <>>
Tue, 27 May 2003 09:54:08 -0400

Here's one that's either a risk or the most effective approach that I've yet
seen for reducing/eliminating spam: simply refuse to accept any mail, even
for your own host.

  [Domain name and user changed to protect the innocent:]

The original message was received at Mon, 26 May 2003 12:49:34 -0400 (EDT)
from localhost []

   ----- The following addresses had permanent fatal errors -----
    (reason: 550 5.7.1 <>... Relaying denied)

   ----- Transcript of session follows -----
... while talking to
>>> RCPT To:<>
<<< 550 5.7.1 <>... Relaying denied
550 5.1.1 <>... User unknown

Re: more spelling-checker follies? (Hopkins, RISKS-22.73)

<"Anna Shefl" <>>
Wed, 21 May 2003 09:55:30 GMT

> For three minutes, an AP story posted on *The New York Times* Web site about
> Justice Clarence Thomas referred to his predecessor as "Turgid Marshall."

MS has also made the historical black leader Marcus Gravy famous.  Given how
many names are not spelling-checker-friendly, I'm all the more surprised at
how many people let spelling-checkers run on auto-pilot.  We'll have to wait
and see what risks, other than embarrassment, could occur as a consequence.

I searched the Web for "Osaka bin Laden".  Results 1 - 40 of about 70.

REVIEW: "Protected Internet, Intranet, and Virtual Private Networks",

<Rob Slade <>>
Tue, 20 May 2003 14:00:51 -0800
   Alexander Moldovyan et al.

BKPIIVPN.RVW   20030404

"Protected Internet, Intranet, and Virtual Private Networks",
Alexander Moldovyan et al., 2003, 1-931769-14-1, U$44.95/C$67.95
%A   Alexander Moldovyan
%A   Nick Moldovyan
%A   Doug Summerville
%A   Vladimir Zima
%C   295 East Swedesford Road, PMB #285, Wayne, PA   19087
%D   2003
%G   1-931769-14-1
%O   U$44.95/C$67.95 fax 702-977-5377
%P   310 p.
%T   "Protected Internet, Intranet, and Virtual Private Networks"

Despite the slim size, it is still disconcerting to find that there are only
three chapters in this book.  Chapter one provides an introduction to
client/server networking, while implying that the technology is *not*
hierarchical.  Basic networking concepts are covered, but the writing has an
academic pomposity without the requisite rigour.  Figures and illustrations
are not only unhelpful, but may actually confuse issues, and typographical
and grammatical errors abound.  Lists of idiosyncratic, and very odd, attack
taxonomies are given in chapter two.  Items like "attacks on the security
policy and administration procedures" aren't really explained, while
"attacks on permanent components of the security system" seems to be limited
to cryptanalysis.  Chapter three has some descriptions of virtual private
networks, tunnelling, IPSec, and key management protocols.

The writing is hard to understand, there does not seem to be any logical
organization to the material, and the mistakes in the content do not inspire
any confidence in the reliability of any part of this text.  All the topics
touched on here are covered much more effectively in other works, but the
topics are so random that it is difficult to make specific recommendations.
For those interested in the basics of data communications I would suggest
Tanenbaum (cf.  BKCMPNWK.RVW), while "Building Linux Virtual Private
Networks (VPNs)" (cf. BKBLVPNS.RVW) is a good introduction to VPNs

copyright Robert M. Slade, 2003   BKPIIVPN.RVW   20030404

Survivable and Self-Regenerative Systems: workshop

<Doug Maughan <>>
Thu, 22 May 2003 02:34:26 -0400

2003 ACM Workshop on Survivable and Self-Regenerative Systems
  In conjunction with
2003 ACM International Conference on  Computer and Communications Security
31 Oct 2003
George W. Johnson Center at George Mason University, Fairfax, VA, USA

Call for papers

One of the key areas of current research in the fields of computer and
communication security is survivability, where the objective is to survive
rather than to prevent or detect intrusions. Survivability research has
explored the intersection of Fault Tolerance and Security, and recently, the
notion of using self-regenerative capabilities in the context of
survivability has generated a significant interest in the community. This
workshop aims to provide a venue for scholars in this area to exchange ideas
and to explore research issues involving survivable and self-regenerative
systems.  Papers offering original research contributions in any aspect of
this emerging field are solicited for submission to this workshop.

Topics of interest include, but are not limited to, the following:

* Survivable Systems & Networks
* Self-Regenerative Systems & Networks
* Use of Self-Healing Techniques in Surviving Attacks
* Security vs. Fault Tolerance in building survivable and
  self-regenerative systems
* Use of Self-Stabilization Techniques in Surviving Attacks
* Role of Formal Models in Survivable and Self-Regenerative Systems
* Self-Adapting and Self-Securing Systems and Techniques
* Measuring and Quantifying Survivability and Self-Regeneration
* Role of Redundancy, Diversity, Unpredictability and Deception in
  Survivable and Self-Regenerative Systems
* Impact of Detection Accuracy and Latency on Survivability and

Papers due: 	July 9, 2003
Link to the workshop can be found from the CCS webpage at:

Please report problems with the web pages to the maintainer