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 52

Monday 27 January 2003


Special notice to certain .MIL/.GOV subscribers
Identity thefts doubled last year
Crooks harvest bank details from Net kiosk
Fuzzy Gorilla
Planned obsolescence of current games
Cody Boisclair
Computer virus writer gets two years in prison
SQL Slammer worm slows Net, grounds S.Korean surfers
Monty Solomon
Bank of America ATMs hit by Slammer worm
Fuzzy Gorilla
SQL Slammer: Are Admins really to blame?
Chris Leeson
The worm turned back: Slammer damage contained
'Slammer' Feared to Strike Again
Monty Solomon
SQL Slammer in Canada
M Taylor
MS SQL Server worm info
Monty Solomon
Re: Keep it secret, stupid!
Fred Cohen
Matt Blaze is a Hero
Robert Ellis Smith
Re: Trouble with Prime Numbers: DeCSS, DVD, ...
Bill Bumgarner
REVIEW: "Auditing Information Systems", Mario Piattini
Rob Slade
REVIEW: "Internet and Intranet Security Management", Lech Janczewski
Rob Slade
Info on RISKS (comp.risks)

Special notice to certain .MIL/.GOV subscribers

<"Peter G. Neumann" <>>
Mon, 27 Jan 2003 14:07:03 PST

Dennis Rears will no longer be providing his very valuable .mil/.gov
redistribution service.  For many years, he has minimized the traffic flow
from CSL to those domains, allowing me to send just ONE message for all of
his subscribers.  MANY THANKS to Dennis.

Those of you who were thusly subscribed have now been moved to CSL's
majordomo server, as of this issue.  This change may entail some new
problems.  Two people were unable to receive mail sent to a list, and I have
given them individual one-of-a-kind subscriptions.  Several dozen people had
addresses that bounced when sent from SRI.  Some of those bounces were
apparently already blacklisted even from Dennis's .mil site, and other
bounces may be due to sites blocking RISKS from SRI as a result of overly
aggressive spam filtering.

If you have friends and colleagues who complain that they are no longer
getting RISKS, please show them this message, and suggest that they
resubscribe at  The majordomo server still has a
few problems with its challenge-response mechanism, mostly due to
upper/lower case incompatibility problems and also to certain noncompliant
mailers.  If you experience any difficulties, please let me know.

Identity thefts doubled last year

<"NewsScan" <>>
Thu, 23 Jan 2003 08:40:35 -0700

The number of identity thefts doubled in 2002, with 162,000 reports of
identity theft compared to 86,000 the previous year. However, the Federal
Trade Commission says that the rise in identity theft complaints does not
necessarily mean an increase in actual crimes — it may simply reflect an
increasing public awareness of the problem and a greater likelihood that
such incidents are now being reported. But an official of the Michigan State
Police points out that many former violent criminals are now using the
Internet for identity theft: "They are switching over to white-collar crime
because it's more lucrative and they know they will get less time.  Identity
theft is not necessarily a sophisticated crime." [*The New York Times*,
23 Jan 2003; NewsScan Daily, 23 Jan 2003]

Crooks harvest bank details from Net kiosk

<"Fuzzy Gorilla" <>>
Mon, 27 Jan 2003 16:09:01 -0500

Crooks, operating in the Birmingham (England) area, are preying on people
using public access terminals for Internet banking.  The scam came to light
after a *Register* reader discovered to his horror an authorised transfer of
6,300 pounds from the joint account he and his wife hold with Lloyds TSB. ...

"Lloyds have advised me that there is a large-scale Internet banking fraud
taking place, affecting customers in the Birmingham area, and has been
ongoing for several weeks. Apparently branches have been alerted," the
victim, a company director of a West Midlands Net services firm, told us.
"It appears that account details are being harvested from public access
points (such as Internet Cafes, and more worryingly, Internet Kiosks)."
[Source: John Leyden, *The Register*, 27 Jan 2003; PGN-ed]

Planned obsolescence of current games (Re: Arrogance, RISKS-22.46)

<CodeMan38 <>>
Sun, 26 Jan 2003 16:37:55 -0500

The "/Trivial/ Risks of Technical Arrogance" post in RISKS-22.46 reminds me
of a personal frustration, related to a game which *should* work on a recent
operating system, but which, due to some apparent oversight by the
programmers, simply refuses to run.

A certain popular video game, originally released on a rather failing
console system but later re-released on the PC-- I won't mention it by name,
but let's just say that its main character is a blue, spiny, fleet-footed
anthropomorphic animal-- can even now be found in the discount racks of many
software stores for $10 US.

I bought this game before I upgraded to Windows XP; it was quite fun, and
under Windows 98, it played exactly like the console version.

However, after I upgraded to XP, I discovered a sad truth about the game: it
DOES NOT work on that operating system at all.  Anywhere beyond the title
screen, it causes a General Protection Fault in one of the old, obsolete
DLLs used by the game, *even in the strictest compatibility mode that XP
provides*.  Technically, this is covered on the system requirements-- which
state "Windows 95/98"-- but there is nothing on the manufacturer's site
mentioning an incompatibility with XP (something one generally wouldn't
expect, given that every other Win98 game I've played works almost
flawlessly in the new OS).

If the game in question were so-called abandonware — that is, having gone
out of production years ago — I'd excuse it.  But, as I mentioned, it can
be found on store shelves at this very moment, and if I recall correctly,
was also re-released in unaltered form either last year or the year before
in a compilation.

And yet "Earthworm Jim", whose PC version was released even *earlier*,
works absolutely fine in XP.  Go figure...

Computer virus writer gets two years in prison

<"NewsScan" <>>
Fri, 24 Jan 2003 09:30:24 -0700

Simon Vallor, from Llandudno, Wales, was sentenced two years in prison by a
London magistrate who said that Vallor's actions "cried out for the
imposition of a deterrent sentence." The judge brushed aside Vallor's
request for leniency, saying: "These offenses were planned and very
deliberate. Frankly, when you go to this trouble to make a sophisticated
virus, programmed to leave damage this week, next week and the week after,
it is absurd to claim you do not intend to do harm. These were by no means
isolated offenses and they were committed over a period of time." Vallor
wrote the viruses called Admirer, Redesi B, and Gokar, and was judged to be
responsible wreaking damage in at least 46 countries.  [*The Western Mail*,
Wales, 22 Jan 2003; NewsScan Daily, 24 Jan 2003]

SQL Slammer worm slows Net, grounds S.Korean surfers

<Monty Solomon <>>
Sat, 25 Jan 2003 12:27:33 -0500

A rapidly spreading computer worm infested networks and bogged down Internet
traffic across the globe on Saturday, crippling online services in one of
the world's most wired countries, South Korea.  Called "Sapphire" or "SQL
Slammer," the worm carries a self-regenerating mechanism that enables it to
multiply quickly across the web, said Mikko Hypponen, manager of anti-virus
research at F-Secure, a Helsinki-based computer security firm.
[Source: Jane Macartney and Bernhard Warner, Reuters, 25 Jan 2003]

Bank of America ATMs hit by Slammer worm

<"Fuzzy Gorilla" <>>
Mon, 27 Jan 2003 16:07:10 -0500

The bandwidth-crunching Slammer worm caused all manner of damage since its
appearance on the Net in the early hours of Saturday morning.  The spread of
the worm was so severe that the majority of Bank of America's 13,000
automatic teller machines "were unable to process customer transactions",
according to *The Washington Post* — which quotes the bank saying it was
able to restore services on Saturday evening but a Seattle-based Reg reader
tells us he was "unable to make a deposit to my Bank of America Account on
Sunday at about noon Pacific time".

[*The Washington Post* article is not explicit about why the worm disrupted
  the ATM network.  Whether the ATMs are attached to the Internet or whether
  the BoA server used by the ATM was infected, this does not sound very

  ATMs, ISPs hit by Slammer worm spread, by John Leyden, 27 Jan 2003

SQL Slammer: Are Admins really to blame?

<"LEESON, Chris" <>>
Mon, 27 Jan 2003 12:37:33 +0000

Over the weekend the SQL Slammer worm wreaked havoc across the Internet.

As usual the two most common responses are:
     1. Blame Microsoft for producing code with holes in.
     2. Blame the sysadmins for not patching systems.
[and 3. Nobody blames the anti-social [deleted] who wrote it]

Of course, (1) is a little unfair as Microsoft patched the hole
six months ago. (2) seems to be a more reasonable response.

At risk of being flamed, I would like to suggest that it isn't.

We are frequently reminded in RISKS that we need to balance our
viewpoint. There are risks in using technology, and risks in not using
technology, and we need to accept that there is a tradeoff between the two.

This is a case in point. When a Service Update is applied to a system, a
number of things are introduced:

 - Bug Fixes
 - New Bugs (due to changes in the system)
 - New Code Behaviour (also due to changes in the system)

In theory, when a Service Update is applied to a computer, the Applications
that are affected by the Service Release need to be re-tested to make sure
that the Application still works correctly with the new level of the
Operating System/DBMS.

Because Service Releases have such a wide scope this can be difficult in a
development environment and near impossible in the live environment. In any
case, testing takes time.

The requirement to maintain a "Stable Production Environment" may mean that
some Service Releases cannot be applied, regardless of what holes they fix.

This is not just a vague generalisation. I have seen systems I maintain
brought down by DBMS Service Releases. There are also many examples that
have appeared in the Risks Digest.

Our current system is held at a very old release because the next Service
Release WILL break the application. This will require extensive work to find
out all the places where code fixing is required.

Note that I am not saying that Service Releases should never be applied, I
am saying that they should never be applied blindly.

The worm turned back: Slammer damage contained

<"NewsScan" <>>
Mon, 27 Jan 2003 10:17:08 -0700

It's unlikely that there will be much additional destruction from the
so-called Slammer computer worm that wreaked damage on the Internet over the
weekend, by infecting more than a quarter of a million computer servers and
clogging networks throughout the world. The worm targeted a known virus in
Microsoft's 2000 SQL server database server; the company had issued software
security patches in July 2002, but many network administrators had failed to
install them. But now the worst appears to be over, says an executive at the
security firm Symantec.  [*USA Today*, 27 Jan 2003; NewsScan Daily, 27 Jan

'Slammer' Feared to Strike Again

<Monty Solomon <>>
Mon, 27 Jan 2003 14:23:10 -0500

'Slammer' Feared to Strike Again
Michelle Delio,, 26 Jan 2003

The global worming attack that fried much of the Internet this weekend may
return on Monday as unpatched systems and applications boot up at the start
of the workweek.  The worm can attack a multitude of Microsoft applications
as well as applications distributed by other companies including
administration, helpdesk, corporate antivirus and assorted security
applications.  Network administrators may not even be aware that their
systems harbor programs that need to be patched.  ...,1377,57409,00.html

SQL Slammer in Canada

<M Taylor <>>
Mon, 27 Jan 2003 15:03:30 +0000

By one account, some Canadian government agencies were embarrassed to have
been caught off guard by the so-called SQL Slammer, a string of
self-replicating computer code spread through data servers using Microsoft
SQL [Server].

Royal Bank of Canada, Bank of Montreal and Canadian Imperial Bank of
Commerce all reported virus-related glitches on Saturday. RBC's telephone
and on-line banking systems were down for hours, and some CIBC and BMO cash
machines worked sluggishly or not at all. Toronto-Dominion Bank also had
problems but gave no details. Bank of Nova Scotia said its systems were

[*The Globe and Mail*, 26 Jan 2003]

M Taylor

MS SQL Server worm info

<Monty Solomon <>>
Sun, 26 Jan 2003 01:35:03 -0500

CERT Advisory CA-2003-04 MS-SQL Server Worm

Cisco Security Advisory: MS SQL "Sapphire" Worm Mitigation Recommendations

SQL Sapphire Worm Analysis

Microsoft SQL Slammer Worm Propagation

Unauthenticated Remote Compromise in MS SQL Server 2000

Sapphire SQL Worm Analysis

Sapphire SQL Worm Scanner Tool

Slammer slugs Internet, down but not out

Re: Keep it secret, stupid! (Blaze, RISKS-22.51)

<[name withheld by request]>
Mon, 27 Jan 2003

Matt Blaze has recently written (in
and about
his discovery of a vulnerability in master-keyed mechanical lock systems.

The paper is a well-written and detailed exposition of the technique, and
will serve well to educate readers both about the workings of mechanical
locks and about this particular attack. However, the attack may not be as
exciting and ground-breaking as claimed. For example, a friend and I figured
out how to do this in high school, but we realized that it would be much
more time-consuming and persnickety than other attacks that were practical
in that environment. As for whether the attack uses "cryptanalytical
techniques", that claim is hard to justify unless you consider
"cryptanalytical" the most appropriate term for recursive exhaustive search.

It's hardly surprising that the technique is not widely covered in
locksmithing texts. That's because it isn't particularly useful in
legitimate contexts. No locksmith would ever bother going through all that
rigmarole when he could instead disassemble the lock and read the master key
directly--which is almost always possible if one has both a legitimate
purpose and a legitimate key.

Given the generally low quality of original work in the underground
community, I'm not very surprised that it's not well-known there, either.
Most techniques I've gleaned from there have fairly clear origins in the
adult world. That's not to say that execution by the underground isn't
clever--but finding the 99th new buffer overflow in Internet Explorer is
more a matter of persistence, I think, than it is of original thinking.
After all, buffer overflows have been well-understood as a security flaw for
over 30 years.  The "MIT Guide to Lockpicking", for instance, is a clear and
educational exposition of lockpicking, but doesn't present anything that
hasn't been well-known in the locksmithing trade since before the invention
of computers.

The basic vulnerability--that there are many more keys which will open the
locks in a masterkeyed system than are ever actually delivered with such a
system--IS well-understood and publicized to the trade. Locksmithing texts
(some, at least) explicitly warn about deploying different masterkey systems
in the same geographic area that use the same kind of keys, for that very
reason. Lock manufacturers sell recommended keying patterns that are
explicitly designed to avoid the problem, and I'm sure there is computer
software that locksmiths use today for the same purpose.

A more interesting question is how to deduce the master key when you *don't*
have a legitimate change key. That, too, is something we understood in high
school, and it involves deducing patterns from several (temporarily)
disassembled locks. Here, there's something resembling a geniune (although
not especially difficult) cryptanalytical problem, in that one must deduce
the pattern the lock manufacturer (or installer) used to assign the keys,
and the manufacturer in turn can try to make that pattern difficult to
deduce. That's the technique we used in actual practice, and it was an
absorbing intellectual challenge at age 16.

The observation that customers aren't warned about this problem, well,
that's hard to assess. One could make the same complaint about not warning
customers that most mechanical locks can be picked in a few seconds.
Fortunately, a lot of contexts where this is an issue (such as hotels) have
already converted to different technologies that may be more secure.

Re: Keep it secret, stupid! (Blaze, RISKS-22.51)

<Fred Cohen <>>
Sun, 26 Jan 2003 19:56:56 -0800 (PST)

When the original paper on Computer Viruses was sent to CACM for possible
publication, they spent a year debating whether it should be considered for
publication because of the potential harm that could be caused by people
knowing about the vulnerability.  I was so disgusted that I have not sent a
paper to the ACM since that time.

Fred Cohen - - -
tel/fax: 1-925-454-0171 Fred Cohen & Associates - University of New Haven

Matt Blaze is a Hero

<"Robert Ellis Smith" <>>
Mon, 27 Jan 2003 14:11:27 -0500

Congratulations to Matt Blaze for his extraordinary discovery about the
vulnerability created by many master keys and especially for his forthright
decision to publish his findings - after carefully weighing all of the
consequences. The usual responses have been to keep findings like this a big
'secret' or to disclose the findings without any responsible planning or
precautions.The critical messages he is receiving from the ostriches in the
business are variations on a theme we have seen in other contexts. Matt
tells it like it is, and he's a hero for doing so.

Robert Ellis Smith, Privacy Journal, PO Box 28577, Providence RI 02908 401/274-7861 fax 401/274-4747

Re: Trouble with Prime Numbers: DeCSS, DVD, ... (Guadamuz, R-22.51)

<Bill Bumgarner <>>
Mon, 27 Jan 2003 11:28:18 -0500

A slight clarification.

CSS-- the encryption used on DVDs-- was not designed to prevent the
duplication of DVDs, illegal or otherwise.  One can easily perform an 'image
copy' of a DVD and the resulting copy will play just fine.  On a Macintosh,
it is trivial to create a disk image-- a virtual piece of media-- of any
filesystem, including a DVD.  The "virtual DVD" plays just fine and has the
added advantage of lowering power usage on portable systems.

CSS is intended to prevent unlawful access to the content in three ways.

First, it makes it possible to enforce region codes in that it is [was]
impossible to decode the content without a licensed-- and likely region
locked-- decoder.  Region locking prevents a DVD targeted for the Japanese
market from being played on a DVD player sold into the US market.  The
motivation behind this is to supposedly prevent cannibalization of sales
between different units of large distribution companies.  That is, Capital
Records' US division does not want folks in the US purchasing something from
Capital Records' UK division.

Second, it hinders direct lossless access to the contents of the DVD.  This
prevents folks from directly stealing the content and producing a derivative
work.  It also hinders digital to digital conversion to other, smaller,
formats such as Video-CD (VCD's are hugely popular in the far East).

Finally, CSS provides a much greater degree of control over the distribution
of content.  This allows the content producers to tightly tune release
cycles, marketing, etc.. to the business climate in a particular market.
That is, they can charge what the market will bear in the target region.  It
also allows the media companies to control the production of the playback
devices-- the content decoders.  If you want to market and sell a DVD
player, you have to buy a very expensive decryption key from the agency that
controls CSS decryption keys [I believe it is the MPAA, but I'm not sure].

REVIEW: "Auditing Information Systems", Mario Piattini

<Rob Slade <>>
Fri, 10 Jan 2003 08:17:30 -0800

BKAUINSY.RVW   20020825

"Auditing Information Systems", Mario Piattini, 2000, 1-878-28975-6,
%E   Mario Piattini
%C   1331 E. Chocolate Ave., Hershey, PA   17033-1117
%D   2000
%G   1-878-28975-6
%I   IRM Press/Idea Group
%O   U$139.95 717-533-8845 fax: 717-533-8661
%P   246 p.
%T   "Auditing Information Systems"

Chapter one is a general overview of auditing, with few details.
COBiT is not being used as intended by the majority of purchasers, we
are told in chapter two.  There is a rather random discussion of some
security (and some network) concepts in chapter three, which changes
format rather abruptly towards the end.  Chapter four notes that
software maintenance has dangers and a structured process would help.
It also suggests a COBiT style list of objectives.  All kinds of
things it would be nice to have in the perfect data warehouse are
described in chapter five.  Chapter six looks at a few legal issues
with respect to information.  The theme of chapter seven seems to be
that databases should do what they are supposed to.  (I suppose Gene
Spafford could sympathize: his definition of a secure computer is one
that does what it is supposed to.)  Chapter eight attempts to recreate
ISO 9000 as a COBiT table.  Task analysis by another name (audit
function points) is described in chapter nine.

Even though the name of COBiT is repeatedly invoked in this book it is
really hard to say what it has to do with auditing.

copyright Robert M. Slade, 2002   BKAUINSY.RVW   20020825    or

REVIEW: "Internet and Intranet Security Management", Lech Janczewski

<Rob Slade <>>
Thu, 9 Jan 2003 08:05:45 -0800

BKIISMRS.RVW   20020825

"Internet and Intranet Security Management", Lech Janczewski, 2000,
1-878-28971-3, U$69.95
%E   Lech Janczewski
%C   1331 E. Chocolate Ave., Hershey, PA   17033-1117
%D   2000
%G   1-878-28971-3
%I   IRM Press/Idea Group
%O   U$69.95 800-345-432 fax: 717-533-8661
%P   302 p.
%T   "Internet and Intranet Security Management: Risks and Solutions"

There is a heavy emphasis, in the preface, on the book's being up to date.
Yet the very first article relies on survey data that was three years old at
the time the essay was written.

Part one supposedly talks about the state of the (security, one assumes)
art.  Chapter one is a vague and superficial look at random topics and
technology related to security, plus results of the aforementioned opinion
poll.  A list of Internet security problems, and solutions that are not
connected to the difficulties, make up chapter two.

Part two deals with managing Internet security.  Chapter three has terse
descriptions of a number of theories of trust, related to some generic
security concepts.  There are brief overviews of the TCSEC (Trusted Computer
System Evaluation Criteria), Common Criteria, and not-really-the-BS7799 in
chapter four.  Out of thirty three pages in chapter five, three discuss the
general subject of Web security, while there is almost nothing on the
titular topic of management of Web security.

Part three reviews cryptographic and technical security standards.  (There
are a great many grammatical errors, and the authors use almost-but-not-
quite standard terminology.)  Chapter six is an opinionated piece, but does
touch on some basic cryptographic ideas.  Myths and limitations of
cryptography are listed in chapter seven.  Chapter eight has descriptions of
ISO cryptographic standards, both overly technical and incomplete.

Part four talks about law and security.  Chapter nine discusses privacy, but
only in regard to employer monitoring of employee email.  The weaknesses of
the New Zealand privacy law are commented on in chapter ten.

It is difficult to say that any audience would benefit from this vague
collection of unfocused ideas.

copyright Robert M. Slade, 2002   BKIISMRS.RVW   20020825    or

Please report problems with the web pages to the maintainer