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 22 Issue 14

Tuesday 9 July 2002


DCS/SCADA Security
Eytan Adar
Fishermen rescued after dam malfunction
Thomas Dzubin
China bans toxic American computer junk
Mich Kabay
A Microsoft Medley in RISKS-22.13
Peter da Silva
Windows Media Player security update EULA gives MS permission to keep you from using "other software" on your computer
Bill Tolle
Re: E-mail address parsing
George Roussos
MI5 hates encryption so much, they don't use it!
Ben Laurie
More on The Telecom Crash of 2002
Joe Pistritto via Dave Farber
Security in General - wireless - simplicity
M Simon
M Simon
11th USENIX Security Symposium
Alex Walker
REVIEW: "Decrypted Secrets", F. L. Bauer
Rob Slade
Info on RISKS (comp.risks)

DCS/SCADA Security

<Eytan Adar <>>
Thu, 27 Jun 2002 09:33:59 -0700 (PDT)

>From an article about security of various control systems (dams, trains,
etc.).  My favorite quote from this article:

  "Most of these devices are now being connected to the Internet. But
  because the digital controls were not designed with public access in mind,
  they typically lack even rudimentary security, with fewer safeguards that
  accompany the purchase of flowers online."

(this and other good stuff at:

Fishermen rescued after dam malfunction

<Thomas Dzubin <>>
Fri, 28 Jun 2002 15:29:19 -0700 (PDT)

(*The Vancouver Sun*, 27 Jun 2002)

Four anglers were rescued by helicopter Wednesday from a small island in
the Capilano River after a control malfunction at the Greater Vancouver
regional district's Cleveland Dam released an unexpected torrent of water.
The malfunction of the drum-gate water-control mechanism, which occurred
during a computer upgrade, is expected to prompt the installation of more
signs along the river warning fishermen of the potential for rapid
increases in water levels.

The Cleveland Dam had been releasing snow-melt water through the drum-gate
at the rate of about 1,000 cubic feet per second when the malfunction
occurred at 7 a.m. Wednesday.  By the time dam employees brought the problem
under control about an hour later, the flow had increased four-fold to about
4,000 cubic feet per second. At that rate, it would take about 30 seconds to
fill an Olympic-sized swimming pool.

Thomas Dzubin note: the GVRD does not tightly control physical access to
the land around the Capilano river and I've walked by various points along
its banks quite a few times.   I guess the Risk here might be that you
shouldn't automate a system where you can't control access to all
directly affected points or at least have an independent feedback system
in place to not allow (or send an alarm) a 4x increase in flow over a
short period of time.
(Although, I'm not a civil engineer...such a feedback mechanism might
be tough to implement and still allow the dam to "let-go" water in
emergency situations such as the week-long rainstorms which we
sometimes have in Vancouver.)

Thomas Dzubin, Vancouver, Calgary, or Saskatoon, CANADA

China bans toxic American computer junk

<Mich Kabay <>>
Sun, 30 Jun 2002 11:24:34 -0400

John Gittings in Shanghai, writing for the Guardian Weekly, published
an article entitled "China bans toxic American computer junk:
Electronic scrap puts the lives of rural villagers at risk" (GW,
2002-06-01, <,3604,725756,00.html

"Beijing has announced a clampdown on the import of electronic junk
from the US and other developed countries which is being stripped by
Chinese peasants in primitive and dangerous conditions.

The ban follows an outcry by western environmental groups and in the Chinese
press about reports that young children are employed to smash up computers
and that local water supplies have been poisoned by toxic waste.

A new list of banned items will include "TV sets, computers, Xerox
machines, video cameras and telephones", according to the national
environment agency."

The article goes on to describe threats to the health of >100,000
unprotected workers, including children, who extract heavy metals from
circuit boards plus severe environmental degradation to farmland surrounding
the recycling centers.  Most of the waste comes from the US because, "The US
is the only industrialised country to have failed to ratify the 1989 UN
Basel convention which calls for a total ban on the export of hazardous

This article highlights the RISKS of assuming that bringing our
defunct computer gear to a recycling center is "protecting the
environment."  It may be protecting our part of the environment, but
on a global basis, we seem to be causing a great deal of harm to many
poor people and to the long-term future of our planet.  In addition,
we ought to look at the morality of treating other human beings as if
they are expendable tools for protecting ourselves at their expense.

Seems to me that the only sustainable approach to reducing the harm we can
cause by discarding computer gear is to include the price of safe recycling
in the purchase price and to have manufacturers, wholesalers and retailers
contribute to an economically viable treatment process where users live --
not in some shantytown on the far side of the planet.  Perhaps signing and
abiding by the Basel convention would be a good first step.

M. E. Kabay, PhD, CISSP, Dept CompInfoSys, Norwich University, Northfield VT

A Microsoft Medley in RISKS-22.13

<Peter da Silva <>>
Thu, 4 Jul 2002 18:22:20 -0500 (CDT)

Four fascinating articles in RISKS-22.13:

> Microsoft's secret plan to secure the PC (Monty Solomon)

The referenced article included such gems as "Palladium stops viruses
and worms. The system won't run unauthorized programs, preventing
viruses from trashing your system." Setting aside all the other issues
in the article, this by itself is a remarkable piece of misdirection.

Why? Well, let's look at viruses...

There are four main avenues that viruses and worms use to spread. There
are others, but the vast majority of outbreaks have used these avenues
of attack.

The first, and oldest, is "social engineering". You trick a human into
running a program for you. This is the electronic equivalent of calling
up the sysop at a company and saying "hey, this is Jack Smith in
accounting, I can't get in, I forgot my password because I had it
programmed into my mail program, can you clear it for me?". Making the
OS more secure can help somewhat, but you don't need to wait for
Palladium to do this... most multi-user operating systems are designed
so that users normally run with restricted privileges, and so can only
damage their own files... not the OS or other user's programs.

The second is exploiting a straightforward bug, usually a buffer
overflow. To fix this you don't need a new security model, you need a
programming language that doesn't allow buffer overflows.

The third is a "cross frame attack": you trick the client software (web
browser, e-mail program, music player) into running untrusted code
without restrictions. This is almost always an attack on Microsoft's
poorly-advised merge of the web browser (which is almost always dealing
with untrusted objects) with the desktop, mail software, and so on. If
they had integrated the HTML rendering engine in the OS and left the
Internet access code in a separate program that used the HTML rendering
code but otherwise managed its own access controls... at least 90% of
the widespread virus outbreaks would never have happened.

The fourth is conversion attacks. You encode the message containing the
attack code inside a package the outer layers of the OS or application
don't know how to open. Ironically, Palladium is likely to make this
kind of attack easier, because it's almost certain that part of the
security model will involve separating the system up into components
that don't have the keys to each other's files.

Ironically, one of the latest security issues with a Microsoft product
is due to the first Palladium-type software having three of the kind of
security holes I just listed above... Windows Media Player. The second
of the three holes would not exist if Media Player didn't have to have
access to the OS internals to implement Digital Rights Management.

Of more concern, the integration of the browser and the desktop and
other components that created the possibility of "cross frame attacks"
is due specifically to Microsoft's attempt to avoid complying with
their original agreement with the Justice Department by bundling the
Browser and the OS. Microsoft has maintained this dangerous design
despite years of massive virus outbreaks caused by this decision,
because otherwise they'd have to admit fault. Even now, when they have
been found at fault, and there's nothing left to lose, they refuse to
unbundle the Internet access from the rendering code.

So, not only has Microsoft never before shown much concern for this
problem, they have actively worked to prevent a straightforward fix that
they are legally required to implement. Using this issue as a hook to
get more control of the computer is, well, there are polite terms for
it and I'll let you decide which one to apply.

Even if you don't care about this specific issue, what does this say
about their likely behaviour if security problems crop up in the design
of Palladium?

> Risks to your privacy from using MSN Messenger 4.6? (Michael Weiner)
> Microsoft sent Nimda worm to developers (Mike Hogsett)

The implications of these two, in light of the first, are obvious.

> Microsoft's Allchin: API disclosure may endanger U.S. (Brien Webb)

This article basically says that Microsoft knows they have fundamental
design flaws in their protocols, which if discovered will open up your
computer to uncontrolled access.

So now they want us to trust them that this time, honest, they'll
really get it right?

Windows Media Player security update EULA gives MS permission to keep

<Bill Tolle <>>
Sun, 30 Jun 2002 10:56:11 -0500
 you from using "other software" on your computer

The latest from MS is buried deep in the EULA if you download the Windows
Media Player security update:

  "You agree that in order to protect the integrity of content and software
  protected by digital rights management ('Secure Content'), Microsoft may
  provide security related updates to the OS Components that will be
  automatically downloaded onto your computer. These security related
  updates may disable your ability to copy and/or play Secure Content and
  use other software on your computer. If we provide such a security update,
  we will use reasonable efforts to post notices on a web site explaining
  the update."

  "may disable your ability to copy and/or play Secure Content and use other
  software on your computer" is an interesting phrase. If you remove one
  item from the sentence it becomes "may disable your ability to
  ....................... use other software on your computer".

Wonder what "other software" Bill G. might decide to not let us use at some
point in the future?


Bill Tolle <>

Re: E-mail address parsing {RISKS-22.13}

<George Roussos <>>
Mon, 1 Jul 2002 00:28:08 +0100 (BST)

>The risk is that the customer-relations programmers are living in a
>world of [a-z0-9_] for mailbox names, while the standard has long
>allowed for virtually any character (including NULL).

Actually, they live in an MS Outlook world (try to send e-mail to
"@ @" using outlook). In fact, Outlook would refuse to send e-mail
to a number of perfectly valid addresses, including any that contain
the end dot for the root domain. This is obviously a feature, not a bug!

MI5 hates encryption so much, they don't use it!

<Ben Laurie <>>
Wed, 03 Jul 2002 12:39:06 +0100

According to Network News (the UK rag) today, MI5, the Home Office, and
others don't use PGP signing at RIPE (the European Internet registry),
although its the only really secure method for updating records. So anyway,
I thought I'd look into it, and, well, its true (edited highlights follow):         6715    IN      A

inetnum: -
mnt-by:       QINETIQ-UK-MNT

mntner:       QINETIQ-UK-MNT
auth:         MD5-PW $1$tSMW1DGk$GIAERGLu5BwBUXabmYjvs1

I'm sure Qinetiq haven't been so foolish as to choose a guessable password
(after all, they've shown their IT expertise by the masterly handling of the
1901 Census website), but even so, their e-mail must contain the password in
plain text. Of course, if anyone out there runs their password cracker on
that and finds I'm wrong, I'd _love_ to hear about it.

Note: all data above is from publicly available sources.

Incidentally, the article suggests that some people are still using
MAIL-FROM auth, which is, frankly, astonishing. I can't be bothered to
track down who, though.


  [PS.  OK, I lied: I can be bothered. This is just too amazing:             35656   IN      CNAME    283     IN      A

  inetnum: -
  mnt-by:       AS12967-MNT

  mntner:       AS12967-MNT
  auth:         MAIL-FROM .*
  auth:         MAIL-FROM .*

  Yes, folks. The UK government's Website  uses MAIL-FROM auth. And not even
  .uk addresses!]

More on The Telecom Crash of 2002

<Dave Farber <>>
Sun, 30 Jun 2002 19:15:06 -0400

------ Forwarded Message
>Date: Sun, 30 Jun 2002 12:00:36 -0700
>From: "Joseph C. Pistritto" <>
>Subject: Re: IP: The Telecom Crash of 2002

The most telling comment here is the comment about bankruptcy allowing new
players to take over bandwidth debt-free, dropping prices.

We've seen this pattern before.  In Iridium for instance.   Further, we see
it in the equipment markets, where companies can buy equipment on the
secondary market for 20% of list price.  This is hurting all the equipment
companies as well. (especially Sun, which is very vulnerable to
this.)   Cisco is probably hurting as well because of it.

Its an interesting vicious circle:
1) People install something, (bandwidth, satellites, Sun machines,
   etc.)  and don't have enough revenue to support the cost of it.
2) They go into debt, sometimes spectacularly
3) They go bankrupt servicing the debt, which gets written off.
4) Other people buy the assets debt-free, and can now cut prices
5) Driving all other providers to go into *more* debt. (if they can), or
   go bankrupt (if they can't).
6) Making more of them go bankrupt. - iterate to step (3).

This can't stop until everyone's gone through bankruptcy, to get back on a
"level" playing field.

As a programmer at heart, I have to believe there's a bug here.

Its clear that the worst iterations of this are where the item involved can
only be used to provide *one kind* of service.  If it's Sun machines,
companies could buy them to put in their internal networks, they don't have
to only build e-<something> web sites with them.  But with Telecom
bandwidth, you're stuck.  Fiber only moves bits.  Voice bits or Data bits,
but still bits.   Which is why this bug is much worse for the Telecom
people than for other kinds of equipment makers, which have multiple
non-competitive uses.   jcp

  Dave's archives:

Security in General - wireless - simplicity

<msimon <>>
Thu, 27 Jun 2002 12:33:50 +0100

I think that wireless networks and www based networks for hardware
control are a thing of the past.

I had often thought that this was the stupidest thing I had ever heard
of and so despite the personal cost had never bothered to learn the

Sadly events are beginning to prove me correct. I expect my retro skills
to be in high demand shortly.

Remember the days when everything was going to be hooked up to the net?
Let us hope those days are gone for good.

Wires and hard connections. Still vulnerable but at least you need
physical access.

No doubt this will raise costs. But you have to balance that against
what a plant is worth. I am aware of new aircraft designs that are using
IP for moving data in an aircraft rather than a proprietary protocol as
was usual in the past. Dumb, dumb, dumb.

BTW I worked on the original Raytheon ATC when I got out of the Navy in
'67. It is interesting to see how badly Raytheon has bungled the
replacement.  If only they had gone with advanced hardware capable of
future expansion and simply directly replaced the old terminals and
systems 1:1.  No bells and whistles.  Then once they had the simple
replacements proved start doing revs. But no - like all fools they got
too ambitious. All they could see was how much money and how much more
capable the new system was going to be. And in C yet. Where you are at
the mercy of the compiler writer rather than the now relatively defunct
FORTH system which produces code that is always defined the same way in
every instance and is much easier to test.

Simpler is better. But try telling that to any young fool who never
fought in the clone wars.


<msimon <>>
Thu, 27 Jun 2002 13:00:23 +0100

Did I mention that FORTH could be the assembly language of a relatively
simple processor?

The advantage is that you get a language on a par with C that runs
directly on the processor.

I know of no processor that runs C code directly. You need a relatively
complex compiler and lots of hardware tricks to make it run fast.

The compiler becomes untestable because of all of the possible
combinations and the million transistor chips become untestable for the
same reason.

The FORTH model is a simple processor (30,000 transistors for 16 bit -
100,00 transistors for 32 bit) with lots of stack and local memory.
Memory is very testable. So are simple processors. Because of the
simplicity of design the FORTH chip needs only a one level deep pipeline
and no branch predictors since a pipeline miss only costs you one cycle
at most. Sometimes depending on the code there is no penalty. A few
years back they were getting speeds of 500 MIPs from 1 micron design
rules and a 32 bit wide bus. Instructions were 5 bits so you got 6
instructions per fetch (best case). With a memory rate of  90 million
fetches a second. Go to 64 bits if you need to reduce the external
memory rate to a very comfortable 45 million fetches a second.

But every one today is in love with complexity. Stupid, stupid, stupid.
Except from a marketing standpoint. Yechh.

Did I mention that all the new complexity requires a very expensive and hard
to test and verify BGA package for all the interconnects vs a less dense
PQFP type package that is visually inspectable vs X-ray inspection which
degrades the silicon.?  Yechh again.

But no one listens to me. I'm not bleeding edge enough. Too simple.

11th USENIX Security Symposium

<Alex Walker <>>
Mon, 01 Jul 2002 15:08:08 -0700

San Francisco. Check out for our early
registration and student discounts.

This year's program brings together an exceptional group of speakers
to inform and educate including Keynote speaker Whitfield Diffie,
co-inventor of public key cryptography and Chief Security Officer at
Sun Microsystems.  Diffie will talk about security policy and
challenges for the 21st century.  Other Invited Talks teach you why
common security systems fail; how to validate and test security
designs; how to make biometrics authentication work; legal aspects of
the DMCA; and much more.

For detailed information and to register, please visit our Web site

Alex Walker, Production Editor, USENIX Association
2560 Ninth Street, Suite 215, Berkeley, CA 94710
1-510-528-8649 x33

REVIEW: "Decrypted Secrets", F. L. Bauer

<Rob Slade <>>
Tue, 25 Jun 2002 07:44:48 -0800

"Decrypted Secrets", F. L. Bauer, 2002, 3-540-42674-4, U$44.95
%A   F. L. Bauer
%C   175 Fifth Ave., New York, NY   10010
%D   2002
%G   3-540-42674-4
%I   Springer-Verlag
%O   U$44.95 212-460-1500 800-777-4643
%P   474 p.
%T   "Decrypted Secrets: Methods and Maxims of Cryptology, 3rd Ed."

Cryptology is the study of the technologies of taking plain, readable
text, turning it into an incomprehensible mishmash, and then
recovering the initial information.  There are two sides to this
study.  Cryptography is the part that lets you garble something, and
then recover it if you have the key.  Cryptanalysis is usually seen as
the "dark side" of the operation, because it is the attempt to get at
the original meaning when you *don't* have the key.  Most current and
popular works on cryptology actually only speak about cryptography.
For one thing, nobody wants to get into trouble by telling people how
to break encryption.  However, it is also much easier to blithely talk
about key lengths and algorithms and pretend to know what you are
doing than it is to demonstrate a sufficient mastery of mathematics to
enable you to go about cracking a particular cipher.

Bauer examines both sides, which is an important plus.  If you need to
decide how strong an encryption algorithm or system is, it is
important to know how difficult it might be to break it.

Chapter one looks at steganography, the science of hiding in plain
sight, or concealing the fact that a message exists at all.  In this
he first demonstrates a wide ranging historical background which is
quite fascinating in its own right.  Basic encryption concepts are
introduced by the same historical background, but move on to a very
dense mathematical discussion of cryptographic characteristics in
chapter two.  Encryption functions are started in chapter three, and
it is delightful to have examples other than Julius Caesar's
substitution code.  Polygraphic substitutions are in chapter four and
the math for advanced substitutions is in chapter five.  Chapter six
introduces transpositions.  Families of alphabets, and rotor
encryptors such as ENIGMA, are reviewed in chapter seven.  Keys are
discussed in chapter eight, ending with a brief look at key
management.  Chapter nine covers the combination of methods resulting
in systems such as DES (Data Encryption Standard).  The basics of
public key encryption are introduced in chapter ten.  The relative
security of encryption is introduced in chapter eleven, leading to
part two.  However, Chapter eleven also ends with a discussion of
cryptology and human rights, concentrating mainly, although not
exclusively, on the US public policy debates.

Part two examines the limits of functions used in cryptography, and
thus the points of attack on encryption systems.  Chapter twelve
calculates complexity, and thus the size of brute force attacks.
Known plaintext attacks are the basis of chapters thirteen to fifteen,
looking first at general patterns, then at probable words, and finally
at frequencies.  Frequency leads to a discussion of invariance in
chapter sixteen.  Chapter seventeen follows with a look at key
periodicity.  Alignment of alphabets is covered in chapter eighteen.
Of course, cryptographic users sometimes make mistakes, and chapter
nineteen reviews the different errors and various ways to take
advantage of them.  Chapter twenty one looks at anagrams as an
effective attack on transposition ciphers.  The concluding chapter
muses on the relative effectiveness of attacks and of cryptanalysis

Those seriously interested in cryptology will really *need* to be
serious: brush up on your number theory if you want to use this book
for anything.  This third edition is essentially and structurally
unchanged from its predecessors, although it has been updated to
reflect the latest algorithms and technologies.  Bauer's history and
vignettes from the story of codes and the codebreakers are
interesting, amusing, and accessible to anyone.

copyright Robert M. Slade, 1998, 2002   BKDECSEC.RVW   20020520    or

Please report problems with the web pages to the maintainer