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 6

Wednesday 8 May 2002


Unprepared for cyberattacks?
Ashcroft wants stiffer penalties for identity theft
The Console Buffer Knows...
Mark Bergman
Rob Slade
GNU in Not Unix
Dimitri Maziuk
More on Clez
Rob Slade
Moderated mailing lists and virus scanners
Matthew Byng-Maddick
CLUTS: Composable Low-assurance UnTrusted Systems
Ben Laurie
NRC report on porn
Herb Lin
ACM invitation
Lillian Israel
Info on RISKS (comp.risks)

Unprepared for cyberattacks?

<"NewsScan" <>>
Tue, 07 May 2002 09:01:12 -0700

People with knowledge of national intelligence briefings say that little has
been done to protect the country against a cyberattack. Senator Jon Kyl
(R-Ariz.) says: "It's a big threat, because it is easy to do and can cause
great harm," and vulnerable U.S. targets are said to include the Centers for
Disease Control and Prevention; FedWire, the money-movement clearing system
maintained by the Federal Reserve Board; computer systems that operate
water-treatment plants or that run electrical grids and dams; facilities
that control the flow of information over the Internet; the nation's
communications network, including telephone and 911 call centers; and air
traffic control, rail and public transportation systems. Rep. Jane Harman
(D-Calif.)  says: "What I fear is the combination of a cyberattack
coordinated with more traditional terrorism, undermining our ability to
respond to an attack when lives are in danger."  (USA Today 6 May 2002;
NewsScan Daily, 7 May 2002)

Ashcroft wants stiffer penalties for identity theft

<"NewsScan" <>>
Fri, 03 May 2002 08:20:55 -0700

U.S. Attorney General John D. Ashcroft is proposing legislation increasing
by 2 to 5 years the jail time for persons convicted of aggravated identity
theft a crime . "The Department of Justice is committed to seeing to it that
criminals and terrorists cannot find refuge in the identities of law-abiding
citizens of this country." Since October 1998, 2,223 criminal cases have
been filed against 2,899 defendants. The call for tougher penalties won
immediate support from Democrat Sen. Dianne Feinstein of California, who
chairs the Senate Judiciary subcommittee on technology, terrorism and
government. (*The Washington Post*, 3 May 2002; NewsScan Daily, 3 May 2002)

The Console Buffer Knows...

<Mark Bergman <>>
Mon, 06 May 2002 13:13:32 +0200

The advantage (and risk) of being able to use screen buffers and scroll bars
to go "back in time" and see what happened in a terminal session is fairly
well known, but I associate that kind of thing with fairly "intelligent" GUI
terminal emulators such as xterm. I happened to be using the "GSP" (Guardian
Service Processor--a set of low level hardware and diagnostic routines) to
check the cause of the blinking error LED on an HP "L" class server
recently. I was using a very "dumb" console--just an 80x24 monitor and a
keyboard with a serial connection to the server to access the GSP.

Among the dozens of commands within the GSP is a selection to show the
console log.

I was pleased to see that the console log contained the many diagnostic
messages that are displayed when the server boots up, before logins are
available. I was also very surprised to find that the log also held the
screen shots of the last console login session, including a telnet session
into a network switch and the complete log (not just the commands, but all
output as well) of the switch reconfiguration!

No passwords were visible this time, and this discovery isn't a particularly
earth-shattering revelation. However, I think that there's a RISK when
someone uses an apparently "dumb" device with no intrinsic "history" to
connect to another device (the switch) with no command history, and yet
there's a record of every screen preserved weeks later.

Mark Bergman


<Rob Slade <>>
Mon, 22 Apr 2002 19:50:21 -0800

Recently a RISKS reader has been regaling me with stories about life in the
marketing trenches at--well, shall we just say A Very Large Technology

AVLTC (TC to its very close friends), like most other technology companies,
has a marketing arm.  The marketing people have managed to include
directives to be issued to all incoming staff.  Prime among these is
indoctrination about the importance of Contacts.  Contacts, are, of course,
the life blood of Sales and Marketing.  Every Contact is to be forwarded to
Marketing for inclusion in the database.  And, in order for the Contact to
be useful, it must include as much information about the Contact as
possible.  (Remember the old joke price list for Answers, Correct Answers,
and so forth?  Well, in the TC world, an Answer costs you a name, address,
and phone number, while a Correct Answer costs you a life history. Even a
Dumb Look costs you a name and phone number, at the very least.)

Since TC deals in Solutions (and don't we all?), many people approach TC
speakers at conferences and seminars with Problems.  In order to get a TC
person to even listen to your Problem (hopefully thinking that they might
get back to you with a Solution) you have to give them your Contact info.
And that info goes into the database.  And, of course, many of the people
with the most interesting Problems might work for important agencies.  Like,
say, the military.

So TC has a Very Extensive List of names and phone numbers of people in the
military, as well as other agencies.

Now, given the least benefit of the doubt, we can assume that TC is not
interested in espionage.  What TC *is* interested in is Aggressive
Marketing.  So they regularly have people call the numbers in the List.
And, of course, if they have no other information, and if they are worthy of
their Marketing headsets, they start asking questions.

In security realms this would be known as social engineering, and it is a
really neat way to get people to tell you things that they ordinarily
wouldn't.  If you have the right number, and the right name, there tends to
be a presumption that you also have the right to ask questions.
Particularly if you also know the right Problem.

But remember, this is not espionage, just Aggressive Marketing.

Now comes an interesting twist.  Assume that TC has no interest in
espionage.  Assume that their Marketing and Sales people are all of the
highest ethical calibre.  (No, Peter, this is not a military pun.)  Even
granted all of this, TC does not use its own sales staff to gather this
information.  TC sales staff are highly trained and skilled workers, and are
also paid more than three dollars per hour.  So TC contracts out this
information gathering work to outside companies.  At this point,
unfortunately, the tale gets a bit fuzzy, since we don't know an awful lot
about these companies, except that they are likely also the people who phone
you at dinner time to sell excess credit cards and unwanted magazines.

Well, we do know slightly more about these companies.  Said companies
provide a valuable employment opportunity to any number of rather low paid
workers who are very likely industrious and entrepreneurial.  And, if the
lack of command of the English language is any indication, also recent
immigrants to these shores.    or

GNU in Not Unix (Re: Markettos, RISKS-22.05)

< (Dimitri Maziuk)>
Mon, 6 May 2002 14:52:30 -0500

Well, that particular risk is well known to professional Unix systems
administrators -- in fact, I was rather surprised to see that Linux
"killall" made the RISKS now: it's been [in]famous among Unix sysadmins for
quite a while now.

I see two issues here: one is that of false advertising, and another one --
of professionalism (not that they are entirely unrelated).

Stallman's rants about "LiGNUx" have a perfectly good technical reason
behind them: "Linux" (as in "OS based on Linux kernel and free software")
has lots of GNU software in it, and "GNU is Not Unix".  Hence, Linux is
*Not* Unix, regardless of what Linux advocates may be telling us, it is
"GNU". (And, BTW, Unix is Not GNU.)

That was about false advertising, now let's look at professionalism.

Linux killall is perfect illustration of what happens when a product is
designed by a diletante.

Back in 1975 professionals designed an OS called Unix. Being professionals,
they realised the need for certain design principles.  Such as splitting a
task into a number of smaller subtasks and designing a separate tool to
handle each subtask (that does one thing, and does it well)[0].

For example, shutting down a computer involves flushing (synchronizing) file
buffers to disk ("sync"), killing all running processes ("killall"), and
powering off the machine ("poweroff", at least on Solaris). All perfectly
neat and logical.

Along comes a layman who is unaware of the above principle, nor of
the significant "prior art"[1]. Result? -- read Theo's message.

  (Various observations to show that isn't such a big problem (in
  no particular order):

  * professionals already know that similarly-named utilities often
     behave differently on different operating systems,
  * GNU folks never intended to uphold the aforementioned design
    principle in the first place (see EMACS), so no surprises there,
    after all, you'll only run "killall" on a Unix once.)

We have a bigger problem with another Unix principle: source code

As software becomes more complex, it requires more sophisticated build
tools.  More and more open source software is being developed using GNU
compilers and build tools, and it is becoming dependant on them. The result?
-- While portability at the level of each compilation unit is still
maintained, the whole thing is not portable anymore. It fails to build on
non-GNU systems[2].

GNU project in particular did a great service to software community by
promoting and popularizing free software. It also did a great disservice by
turning the whole thing into a political issue, and pretty much ignoring the
need for competence and expertise on the part of software developers.
Instead of sound software engineering, we now have "Free Speech"

With more companies (individuals, governments) jumping on Linux bandwagon,
the situation becomes eerily reminiscent of the recent dot-com boom; back
then we had The Internet and e-words, now we have Open Source and
Linux. Back then a few cautionary voices drowned in marketing hype, now
they're likely to be branded Paid Advocates of Evil Entertainment Industry
and Oppressors of Free Speech[tm] -- so they shut up and go learn Plan9, or

  (BTW, if it sounds like I'm singling GNU out, I'm not. Microsoft
  et al., did at least as much as GNU to get us where we are now.
  The whole thing would be very different if there was e.g. a
  liability clause in every software license.)

But the $15 question remains: would you board an airplane designed by, say,
2nd year biology student as a night-time hobby? So what makes you think
their software design skills are any better?

Hmm. This came out sounding like a rant. Well, it probably is.


[0] Various aspects of the problems related to complex software systems are
very familiar to RISKS readers. They come up in, what? -- every other RISKS
issue? 25+ years ago Unix authors were well aware of them, too.

[1] Irix and Solaris "killall", for examle, behave like HP-UX one -- not
surprising, considering the "grand scheme of things" outlined above.

[2] Anyone who ever tried building open source software on Solaris using
native build tools knows that 9 times out 10 GNU "libtool" fails to link
shared libraries. The remaining 1 time GNU ./configure script fails to
determine compiler flags to make position-independent code (needed for said
libraries). And since GNU compiler and build tools are unable to produce
64-bit code on Solaris, the libraries, and all software that uses them must
be built as 32-bit binaries. Now, why did I pay for that 64-bit hardware,

[3] And instead of one Shakespeare, we have a zillion monkeys with C
compilers. As history of Usenet shows, we shouldn't expect them to come up
with even "Hello World" anytime soon, not to mention "Hamlet".

More on Clez (Re: Slade, RISKS-22.05)

<Rob Slade <>>
Tue, 7 May 2002 16:17:48 -0800

Crying Klez: Maybe the sky *is* falling
by Robert M. Slade

Maybe it's because the name is unassuming, without the flash of a
"Melissa" or "Loveletter" or "Chernobyl."  Maybe it's because various
reports have called it Klaz, Kletz, W32/Klez.[a-k]@mm, or I-Worm.Klez.
Maybe it's because the public's attention has been exhausted by media
viruses like Code Red.  Maybe it's because there have been a number of
versions, and only the latest one has made an impact.  Maybe it's
because the beast is bewilderingly complicated.

Whatever the reason, a virus called Klez (or, more specifically,
Klez.H) seems to be happily spreading far and wide, without much
attention from anyone except antiviral vendors.  Warnings have been
issued about it, but these are often limited and unhelpful.  The
general media does not appear to have paid any attention to the
problem at all.  One of the most widespread and dangerous viruses of
recent times, Klez is hard to identify, is difficult to track, is
generating serious numbers, and carries a number of payloads.  Also,
it probably isn't the last of it's kind.

Klez is actually a family of viruses.  The limited information
available seems to indicate that the same author or a small group,
probably resident in China, is likely responsible for all of the Klez
variants.  Eight have been identified so far, seemingly released
between the fall of 2001 and spring of 2002.  Each variant has added
new features and payloads.  In little over half a year the Klez family
has gone from being a minor nuisance to a major threat.

The first version was so buggy that flaws in programming seemed to be
the major concern.  However, even then the virus was notable for its
ambition and complexity.  In addition to spreading itself, Klez
dropped a virus called ElKern.  (There have been reports of a new
version of a new version of the CIH virus traveling with Klez, but
this may be due to infection of the Klez program file itself.)  The
subject line, sender address, and filename attachment were all
variable, avoiding the major means of e-mail virus detection.  (Various
Klez variant subject lines have promised games, humour, pornography,
vague but important messages, and, interestingly, antiviral
protection.)  Klez also used a vulnerability in Microsoft's Outlook
mailer (actually resident in Internet Explorer programming) that would
automatically unpack and invoke the message attachment, in some cases
before the message was even read by the user.

(This mailer loophole, sometimes known as the IFRAME vulnerability,
had actually been addressed and patched by Microsoft in March of 2001.
Users who had regularly upgraded installed patches would not have been
at risk of this specific function.  The bug is addressed in
However, the more widely known Microsoft security bulletin,, deals
with a composite patch, and talks about browser certificates, rather
than the mail problem.  It is also interesting to note that, in order
to use this function, Klez forms messages with a non-standard MIME
[Multimedia Internet Mail Extensions] format.  Non-Microsoft mailers,
such as Pegasus and Netscape Communicator, may not even allow users to
see the attachment, and thus, inadvertently, offer users additional

The file attachment, as of version H, will have an extension of .EXE,
.BAT, .PIF, or .SCR.  The MIME file type will not match the extension
(although that is not a reliable indicator of a virus infection).
E-mail addresses used to create new infected messages are harvested
from the infected machine.  Recent versions of the virus also have
code to use ICQ as a source of e-mail addresses.

Klez.E (version 2.0, according to internal text), released in January
of 2002, added file infection capabilities, so that the virus could
spread using e-mail, direct copying to network shares, and infection of
program files.  (Windows system files were often corrupted by the
infection attempts.  Other files might be infected by a companion type
method: the original file was renamed and hidden and a copy of Klez
written with the original filename.)  The virus carried its own SMTP
(Simple Mail Transfer Protocol) program so that it did not need to use
local mail clients.  The "From" line was also faked such that if Alice
received an infected message from Bob, it might not come from Bob but
from Charles, who had addresses for both Alice and Bob on his infected
machine.  This function not only prevented tracking of the infected
machine, but caused many people to try and track infections in the
wrong place.  In addition, the virus had a payload to overwrite text,
Microsoft Word, MP3, HTML and other files with random data, thus
destroying the contents.

Early versions of the virus had a hidden message (in the body of the
infected message) seemingly indicating that the author was trying to
gain a reputation in order to get a better job.  Later versions tried
to kill processes of the Code Red family of worms, including Nimda,
and included hidden messages suggesting that Klez was an antivirus
virus.  Klez.E, in addition to adding to the list of virus processes
that would be stopped, also killed processes for a number of the most
popular and effective antiviral programs.  It would remove Windows
Registry keys for antiviral software, and also corrupted checksums or
deleted files for antiviral systems.  (Text strings seemed to indicate
that this was because the world had not offered the author a well-
paying computer job.)

The latest version (as of this writing), Klez.H, often sends itself in
a message offering a tool to remove and immunize against Klez.E.  (It
purports to come from one of a number of well-known antiviral
companies.)  Klez.H also added a new function: it would frequently
pick up a file from the infected computer and add it as an attachment
to the infected message sent out.  There is already one known case
where a confidential negotiating document was transmitted to a mailing
list of several thousand people in this manner.  Fortunately, the file
overwriting payload seems to have been removed.

Any available virus tends to spawn variants.  It is also not unusual
for a virus author to improve on his (or her) own work, and release
new versions.  However, variants seldom involve additions of functions
and features to the extent seen in Klez.  The original version alone
demonstrated effective social engineering and polymorphic techniques,
as well as complex features that would be dangerous in conjunction
with other forms of malware.  In less than six months, the author (and
the greatest probability is that there is a single author) has added
features manipulating processes in memory, attacking antiviral and
security software, increasing the means of reproduction and spread,
and attacking data availability and confidentiality.  It is unlikely
that this is the last version of Klez that will be seen, and a number
of common viruses could give the author new ideas for new payloads to
add and new technologies to employ.

In a sense, though, there is absolutely nothing new about Klez.
Microsoft software is well-known to be full of bugs and security
loopholes: Internet Explorer is much more dangerous to use as a
browser than is Netscape Navigator.  There are dangerous technologies
in common programs that should be disabled or patched.  There is a
definite trend towards convergence in malware, with different types of
programs supporting and distributing each other.  Polymorphism has
long been known in file infecting viruses: the use of variant subject
lines in Klez is tame compared to the (literally) myriad forms of
files generated by Tremor.

Most importantly, however, your mother's old adage still holds true.

Moderated mailing lists and virus scanners

<Matthew Byng-Maddick <>>
Tue, 7 May 2002 14:12:46 +0100

Some readers of RISKS may be familiar with Dan Bernstein's ezmlm mailing
list manager, and some more may have used the slightly more full-featured
ezmlm-idx. In both of these, extensive use is made of a cryptographically
hashed input address, to confirm particular actions. In particular, it
almost always sets these addresses as the e-mail "Reply-To:" header, so
that when you just hit your "Reply" button in your user-agent, things
work sanely.

The case of a moderated announce list managed by ezmlm-idx is no different.
The moderation includes the full request (as with the rest of ezmlm), and
a bit of text telling you how to moderate the message, and the "Reply-To:"
header set. This would seem fine.

Now let us consider the case where the moderator has some kind of virus
scanning, a not entirely uncommon case in this modern world, and that we
have a virus which picks senders and recipients out of addresses in your
address book.

The virus decides that it's going to send itself to the announce list. This
should not be a problem, as the list is moderated, except, in this case,
the message is included in its entirety at the bottom of the request for
moderation. An online virus scanner, looking for signatures will decide
(correctly) that there is a virus. It therefore replies to the sender of
the message to tell them that there is a virus, but in this case, the
virus software in question is slightly broken, and uses the From: and
Reply-To: headers to work out where it should send the warning. But, any
mail to the Reply-To: address will cause the held message to be sent out
to the announcees.

So the only time the protection doesn't work is when there are viruses,
arguably when it most needs it.

Of course, this doesn't just apply to viruses, but what happens with
moderator "Out of office" autoreplies?

  Well, I can see several here

  * In the quest to make such things as moderation of a list easier,
    the MLM is using the Reply-To header so that all you need to do
    is reply to that virtual mailbox. There is no checking of, say,
    a subject line, or something that necessitates human input.

  * The virus scanner is non-compliant with the standards, and is
    delivering an effective Delivery Status Notification message
    (``We couldn't deliver your message because we believe it to be
    virus-infected.'') to address designated for user-agent rather
    than transport-agent use.

  * This case only occurs where the system sees a virus infected file,
    which is not a case that will be tested for when building the

  * Sending out a virus to your customers via your announce list is
    probably unlikely to make you popular.

Matthew Byng-Maddick         <> 

CLUTS: Composable Low-assurance UnTrusted Systems

<Ben Laurie <>>
Tue, 07 May 2002 14:10:47 +0100

ezmlm, when running a moderated mailing list, sends messages to the
moderators with the From and Reply-To addresses set to cause rejection
and acceptance of the moderated message, respectively.

If the moderators use certain virus scanning services that shall remain
nameless, and a virus (such as the currently rampant Klez, which also
forges the sender address, so is more likely to be accepted for
moderation) is sent to the moderated list, those services report the
virus to the Reply-To address (erroneously, IMO - these should be seen
as delivery errors and reported to the Return-Path, see RFC 2821),
causing the virus to be accepted and distributed to the list.

One RISK is obvious. The other, IMO, is poorly defined standards for e-mail
that make it incredibly difficult to work out what the right thing to do is
in these cases.

Incidentally, vacation(1) send to the From address, which will cause
rejection - not such a bad outcome, but also wrong. But whose fault is the

NRC report on porn

<"Herb Lin" <>>
Mon, 6 May 2002 01:34:43 -0400

Given RISKS readers' interest in these matters, the National Academies'
report entitled "Youth, Pornography and the Internet" was released on May 2.
The report examines approaches to protecting children and teens from
Internet pornography, threats from sexual predators operating on-line, and
other inappropriate material on the Internet. It discusses social and
educational strategies, technological tools, and policy options for how to
teach children to make safe and appropriate decisions about what they see
and experience on the Internet. Chaired by former Attorney General Dick
Thornburgh, it's the most comprehensive study yet on the topic.

More information on the report is available at:

The report itself is available online at:

If you are interested in a briefing on or discussions about the report, please
contact the study director, Herb Lin, at 202-334-3191.

ACM invitation

<Lillian Israel <>>
Tue, 7 May 2002 14:26:40 -0400

  [The Risks Forum is an official ACM activity.  Although we normally never
  run advertising in RISKS, perhaps we owe the ACM this one.  PGN]

IT and computing professionals are invited to join ACM and receive a special
15% discount on their first-year membership, PLUS receive a FREE
Limited-Edition IT book! A second free book is also available if you add a
subscription to the optional ACM Portal (available at a 15% savings as
well).  ACM even has a special offer designed just for students!

To learn more, and to Join ACM now, go to:

Some of the valuable benefits of an ACM membership include:

* Full access to the Online Guide to Computing Literature (July 2002)
* Free access to ACM's new Distance Learning Portal (July 2002) - 150+
  online courses
* A one-year subscription to "Communications of the ACM"
* The option to subscribe to the enormous online ACM Portal - one of the
  world's largest databases of IT information and the ultimate resource for
  IT professionals!

Find out more about the many benefits of an ACM membership, and read about
the FREE Limited Edition books at:

ACM, the Association for Computing Machinery, is the world's leading
scientific and educational society serving the IT and Computing
communities. Founded in 1947, ACM has members in more than 100 countries.

Please report problems with the web pages to the maintainer