RISKS-LIST: Risks-Forum Digest Tuesday 30 October 2001 Volume 21 : Issue 72
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
***** See last item for further information, disclaimers, caveats, etc. *****
This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/21.72.html>
and by anonymous ftp at ftp.sri.com, cd risks .
Contents:
TD Bank Canada system crash (Richard Akerman)
ANOTHER SRI-wide Power Outage (PGN)
ACT Election Electronic Voting (Josh Polette)
Project Liberty (Jay R. Ashworth)
Re: Are spammers getting sneakier? (Crispin Cowan)
Re: Are spammers getting sneakier? - Yes, they are (Greg Searle)
USPS correction (Ken)
NSF Trusted Computing program (Carl E. Landwehr)
REVIEW: "Malicious Mobile Code", Roger A. Grimes (Rob Slade)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Tue, 30 Oct 2001 09:53:43 -0400 (AST)
From: Richard Akerman <rakermanat_private>
Subject: TD Bank Canada system crash
This past weekend in Canada, one of our 5 major banks, the Toronto-Dominion,
experienced a serious systems failure. This caused particular problems
because Canadians use debit cards more than any other nation, in fact, many
people (including me) carry only a debit card and credit card in their
wallet, and no cash.
The Tuesday, October 30, 2001 _Globe and Mail_ reports in
"TD aims to clear backlog following system crash" that:
'The crash was caused by the failure of a single "motherboard" in one of
the bank's central computers at about 11 a.m. Saturday [Oct 27, 2001].
This "gradually started to shut down the system" to "protect the
integrity" of the data already there, Mr. Livingston [head of TD
electronic banking] said.'
Then this remarkable statement
'It was a purely random event," he said, adding that hardware failures are
rare. "This has never happened before, and it will likely never happen
again."'
and ending with
'As TD sought to identify and fix the problem, "a few million
transactions" were rejected by the bank's systems, which, on a busy
Saturday, process up to 500 transactions a second, he said.
The bank's computer systems have all sorts of "redundancies" built in to
try to protect against failures, but the incident on Saturday "just shows
you can't protect against the random element," Mr. Livingston said.'
This seems to me to be a remarkable design philosophy.
Richard J. Akerman <rakermanat_private>
http://www.chebucto.ns.ca/~rakerman/
------------------------------
Date: Sat, 27 Oct 2001 13:45:33 -0700
From: "Peter G. Neumann" <neumannat_private>
Subject: ANOTHER SRI-wide Power Outage
Despite our carefully conceived phased UPS systems, standby generators, and
co-generation plant designed to keep SRI in continuous power, we experienced
a site-wide power outage Saturday morning that took everything electrical
down with it.
Thanks to Dave Stringer-Calvert for sharing the punch-line from an SRI
facilities memo:
"The power outage was caused when Cogen staff pressed the wrong button
and took the facility off-line."
------------------------------
Date: Thu, 25 Oct 2001 19:54:31 +1000
From: joshpoletteat_private
Subject: ACT Election Electronic Voting
The recent ACT Assembly Elections created a first in Australian political
history by introducing electronic voting. It was not a full scale
implementation with electronic voting limited primarily to pre-poll voting
and to a small number of polling stations on election day. Electronic
voting was intended to provide great benefits in vote counting because of
the complexity of the Hare-Clark system. However, this was not to be.
There was a floor in the architecture of the system. The system was
designed to allow live results to be viewed on the Internet. Unfortunately,
the same server that was doing the number crunching (ie, counting the votes)
was also the one serving information to the Internet. As a result, the rate
of vote counting was severely impacted by the load placed on the server by
voters eager to see the results.
URL: http://news.ninemsn.com.au/Sci_tech/story_20717.asp
There are several causes for concern in this article, primarily because of
the sensitivity of the subject (ie, election vote counting). After the
fiasco in the US Presidential elections over ballot paper design and
counting, there was a call for electronic voting to be introduced. The
theory being that computers are never wrong. However, the ACT experience
shows that it is not guaranteed. While there is no evidence that vote
tampering has occurred it is of concern that Internet activity can affect
the counting process of an election. Surely, the counting system should be
isolated from the Internet with only a copy of the interim results stored in
a separate, Internet accessible server? What is really worrying is that the
article doesn't say whether the actual web server was running on the vote
counting server or not. Given the severe impact on counting performance,
one has to wonder.
Josh Polette, Engineering Manager, JCSS, ADI Limited, C4ISR, IS3
Phone: 02 6247 6854 Fax: 02 6247 7864 joshpoletteat_private
------------------------------
Date: Tue, 23 Oct 2001 14:17:16 -0400
From: "Jay R. Ashworth" <jraat_private>
Subject: Project Liberty
In last week's Linux Weekly News, there was some preliminary coverage of
Project Liberty, an "open" alternative to Microsoft's Hailstorm, which is --
very roughly -- an a attempt to embed Passport into everything on the
planet.
The short version is: a repository of information about your person, life,
and preferences which can be accessed by people and companies you authorise,
to provide authentication that you are you, and information about, for
example, your purchase default desires (credit-card numbers, which card to
use, do you prefer first class or coach, etc).
Now, this is, fundamentally, not an especially bad idea.
But how it is implemented is -- given the sort of information which it might
end up holding -- pretty crucial to your personal privacy: do you want
anyone except your doctor and your pharmacist knowing that you have a
prescription for protease inhibitors? (Drugs used to control AIDS and
related conditions.)
You probably don't even want your *health insurer* to know that, even though
perhaps you want them to know *other* things about you, and therein lies the
major problem:
Hailstorm will be run by Microsoft.
And we all know how pristine Microsoft's track record is for placing the
interests of individuals above that of large corporations off of whom
Microsoft makes lots of money. Right?
So here comes Project Liberty, an "open" alternative to this. They've not
much design done yet, I don't think, so we don't know what *specific* goals
PL will be aiming towards. But that's good, because it means that this is
the exact time for private individuals to be casting their bets on what they
think is important: personal privacy and control are good choices there,
IMHO.
I know that in our New World, it's almost unpatriotic to be concerned about
personal privacy, but you know what? That's a wrongheaded, short sighted,
and dangerous outlook to have. Our country became something to be proud of,
protect, and defend precisely *because* it attempted to secure such
liberties to the people against government control, and corporations should
be given no extra leash -- they work for *us*, in the final analysis, just
like the government.
But the most fundamental tenet of Project Liberty's operation must be, for
it to succeed, that it will always favor the desires and interests of those
one billion people whose identities it likes to tout it's representation of
*over* the interests of the corporations with all the money.
>From a design standpoint, it must make it possible to break down your
information to a sufficiently fine granularity to allow you to authorize
access for someone to only the data which you want them to have... and
indeed, to make it as difficult as possible for different providers to
cross-correlate the information the hold privately about you with one
another. (Why do I get my cablemode service from one company, my wireless
Internet from someone else, and my cellphone service from yet another
company? Because I *can*, and because it one bill is late, I don't get cut
off from all three. Do I want to give that flexibility up? Certainly not.)
Ensuring that the provision of the convenience of "single-sign on" won't
deprive me of rights and conveniences I now have won't necessarily be easy
for the Project Liberty folks.
But if they don't do it, and stick to it, then I will not -- and you should
not -- give them any more quarter than Microsoft. Regardless of whom they
have on their side.
Jay R. Ashworth, Member of the Technical Staff Baylink, The Suncoast Freenet
Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 jraat_private
------------------------------
Date: Fri, 26 Oct 2001 16:43:10 -0700
From: Crispin Cowan <crispinat_private>
Subject: Re: Are spammers getting sneakier? (Slade, RISKS-21.71)
The "may be forged" note is a standard indication from the MTA (Mail
Transfer Agent, i.e., mail server) that the host the MTA is receiving this
mail from cannot successfully be reverse-DNS'd. If the MTA did reverse DNS
on the originating IP and got a different name, it would have told you that.
As it is, it is just saying that it doesn't trust the claim that this is
from triton.net.
Given the fairly prolific amount of inaccurate reverse DNS info out there,
this isn't even a reliable indication that a give piece of e-mail is spam.
But in the context that Slade provides (multiple forged headers, stupid
generic query) it is a good bet.
I've seen it many, many times in the last couple of years of spam-fighting.
The earliest instance I have a record of is August 1998, but that's only
because that is literally the oldest archived spam that I have. Since then
I have logged approximately 2000 occurrences of such spam. An interesting
result of this investigation: the frequency has dropped sharply in recent
years, although spam frequency certainly has not. Whatever spam technique
causes this to occur appears to be falling out of favor.
Crispin Cowan, Chief Scientist, WireX Communications, Inc. http://wirex.com
Security Hardened Linux Distribution: http://immunix.org
------------------------------
Date: Fri, 26 Oct 2001 12:28:45 -0400
From: "Greg Searle" <greg_searleat_private>
Subject: Re: Are spammers getting sneakier? - Yes, they are
Here's the bag of tricks that many spammers are using to keep you from
finding out who really sent you the spam:
1. The obvious - find an open e-mail relay, and use it for "e-mail
laundering". Forge the e-mail headers, and the e-mail becomes untraceable.
All you see is the IP for the open relay, and whatever the spammer wants you
to see afterward. The "From" header is always forged, and complaining to
the ISP behind the "From" address is pointless. The most you can do is
complain to the company that owns the open relay, and hopefully they will
close it. Unfortunately, new mail servers appear on the net every day, and
many IT "professionals" setting up these systems are just not aware of the
open relay problem. There are many web pages which have the sole purpose of
finding and listing these open relays.
2. Include a "relay" URL in the spam for potential customers. This URL is
typically a "throwaway" account opened on one of the many free webpage
services (tripod, geocities, angelfire, etc.) with false credentials. The
spammer only expects this URL to exist for a day or two, as the provider
will quickly terminate the page once complaints start coming in. The URL
typically points to a file or page that will redirect the customer to the
true page.
3. There are some businesses that are specifically set up to relay URLs for
spammers. One of these is 1freesite.net (G Stubberfield Enterprises).
Spammers hire the business to set up a relay page on their server, so they
can include this page in their e-mails.
4. Obfuscate the URL in an attempt to make it untraceable. Do you know
that IP addresses can be expressed as a single, decimal digit? Browsers
will accept this digit and translate it into a valid IP address. Encoding
the URL in hex is another trick. Browsers will convert two-digit hex digits
that are preceded by a percent sign into a valid character. The URL
specification also allows usernames and passwords in a URL. This can be
used to mislead. For instance, the URL
http://www.webservice.com:www.server.comat_private/spampage.html seems
to point to "webservice.com", but the piece of the URL before the second
colon is really the "username", the piece before the at sign is the
"password", and the real web server is the IP after the at sign! Most web
servers simply ignore the user name and password if they don't need it.
These techniques can be combined to make a URL really hard for a person to
decode.
5. Compose the relay webpage in JavaScript. Encrypt the "real" web page
and any URL's, and have a JavaScript function decode it.
6. Ask customers to respond to the message. Include a valid "Reply To"
header that is different from the "From" header. The e-mail client will
recognize this and send any responses to the "Reply To" address. The e-mail
account set up to receive these messages is usually a "throwaway" address
set up on a free mail service with false credentials.
7. Include an unlisted phone number, which is protected by the telephone
company and is untraceable.
8. Included an executable at the URL enclosed in the message. This
executable is typically compressed to obfuscate its contents from prying
binary file editors. The executable then forwards the customer's computer
to the business's true URL. Anybody who opens this executable file is too
ignorant to know any better.
All of these methods, except for the telephone number and the reply-to
address, are completely reversible to expose the company behind the e-mail.
If the computer can get to the final page, then so can the person operating
the computer, given enough knowledge of the technology involved. There is
one particularly nasty spammer, hosted at sexmansion.com and web69.com, that
includes a doubly-compressed executable in the page that they set up on a
"throwaway" site. Their extremely explicit e-mailings point to this
executable's URL. This executable is a dialer application that redirects
the user's modem to an offshore telephone number and sends their browser to
one of the above mentioned domains. This appears as a charge on their
telephone bill. This business was rather clever with the obfuscating
technology used to hide their presence, but the same technology can be used
to unravel the obfuscation and find the business behind it.
------------------------------
Date: Wed, 24 Oct 2001 22:30:54 -0400
From: Ken <kenzo@free-music.com>
Subject: USPS correction (Re: Improper address-change validation)
>... the advisory went to the new address, along with all the old mail.
Actually, their policy is slightly better than this; they send advisories to
both the old and the new addresses. So, in theory, you can rush to the post
office upon receiving the advisory and at least stop them from forwarding
any additional mail. Not terribly secure (no attempt is ever made to verify
your identity), and it depends on you successfully receiving the advisory,
but it's still slightly better than cutting your old address off altogether.
kenzo@free-music.com
[... but not much help if you are away for a month. PGN]
------------------------------
Date: Thu, 25 Oct 2001 14:56:01 -0400
From: "Landwehr, Carl E." <clandwehat_private>
Subject: NSF Trusted Computing program
[Carl Landwehr, erstwhile security guru at the U.S. Naval Research Lab and
more recently at Mitretek, is now on a one-year leave at the National
Science Foundation, as Director of the Trusted Computing program. NSF is
a good source of funding, and this procurement should be of interest to
many RISKS readers. As always, I recommend that we focus on developing
TRUSTWORTHY systems, not just UNTRUSTWORTHY systems that have to be
TRUSTED because we have no alternative. PGN]
The initial announcement for the new Trusted Computing program is at:
http://www.nsf.gov/pubs/2001/nsf01160/nsf01160.html
The deadline for proposals is 5 Dec 2001; if you are in a position to
conduct research in this area, I encourage you to consider submitting a
proposal. NSF focuses on funding research at universities and not-for-profit
organizations. I also hope you will consider helping me staff the review
panels for the proposals that are submitted.
My new contact information is provided below; please use this e-mail address
for future correspondence.
Carl E. Landwehr, Program Director, Trusted Computing, CISE/CCR, Suite 1175
National Science Foundation, 4201 Wilson Blvd., Arlington, VA 22230
e-mail: clandwehat_private phone: 703-292-8936 fax: 703-292-9059
------------------------------
Date: Mon, 29 Oct 2001 08:00:43 -0800
From: Rob Slade <rsladeat_private>
Subject: REVIEW: "Malicious Mobile Code", Roger A. Grimes
BKMLMBCD.RVW 20010814
"Malicious Mobile Code", Roger A. Grimes, 2001, 1-56592-682-X,
U$39.95/C$59.95
%A Roger A. Grimes rogerat_private
%C 103 Morris Street, Suite A, Sebastopol, CA 95472
%D 2001
%G 1-56592-682-X
%I O'Reilly & Associates, Inc.
%O U$39.95/C$59.95 800-998-9938 fax: 707-829-0104 nutsat_private
%P 522 p.
%T "Malicious Mobile Code: Virus Protection for Windows"
I have to admit to a very definite bias. My co-authors and I have just
finished a book that attempts to provide up to date virus protection
information to sysadmins. As I understand it, ours will be printed about
three weeks after this one.
I also have a problem with the title. Grimes appears to be trying to carve
himself out a niche by promoting a term that nobody else is currently using.
And the subtitle should more properly be, "Risk Mitigation for Microsoft
Software." However, if you are using Windows, there is a good deal of
information is this book that, with some diligence and additional work on
your part, can help improve your security.
Grimes starts off the book by listing some fallacies that we have always
believed. "You can't get a virus by simply reading an e-mail." (OK,
Microsoft has amply demonstrated that they've added virus capabilities to
their mail software.) "Malicious code can't harm hardware." (Well,
quibbles about terminology aside, it usually can't.) "A virus can't hide
from a booted write-protected diskette." (Ummm, I'm not sure that sentence
even *means* anything.)
Melissa and the Love Bug were serious nuisances, and even worse, but is it
really accurate to say that they shut down tens of thousands of networks?
This book is intended for intermediate and advanced users and system
administrators, and addresses only the Microsoft Windows operating systems.
While I would agree that Windows is the system most in need of virus
protection and help, this focus does limit the audience. Grimes also tries
to avoid the virus/worm/replicating trojan argument with the use of the term
malicious mobile code, and states that the book does not deal with attacks
and security holes, but the coverage of trojans, RATs (Remote
Access/Administration Trojans/Tools), and browser attacks seems to
contradict that position. (In fact, the more detailed description of
"malicious mobile code," and the MMC acronym that Grimes creates, seems to
be amply covered under the more commonly used term malware.)
Chapter one provides a very brief outline of some malware related concepts.
Most of the chapter concentrates on the virus writing community, although
only in a superficial way. Grimes obviously feels sympathetic towards virus
writers, and presents their own stories without criticism or analysis. Some
details of the MS-DOS operating system, as well as basic virus technologies,
are given in chapter two. The programming particulars, and a bit of virus
source code, are likely to be of more help to budding virus writers than to
the defending sysadmins. There are copious errors in the information listed
about specific viruses. Sometimes the material is careless, such as the
assertion that Michelangelo formats hard drives (the original version
overwrites sections of the disk, and only the disk booted from on the
trigger date). In other places the wording is slipshod, such as the
implication that a seldom seen screen artifact of the Jerusalem virus is
somehow responsible for file deletion. (Oddly, while Grimes does not appear
to have done serious research he has obviously read my stuff at some point:
one of the examples is taken almost word for word from my writings. Other
passages originating in my work are recognizable, although not quite as
blatant.) The recovery advice is also suspect: he reiterates the rather
dangerous suggestions to format the disk or use FDISK /MBR.
Some very useful information about Windows, particularly the 9x, NT, and
higher versions, is presented in chapter three. The material does not often
deal with malware as such, and, in a number of cases, details are either too
particular or not specific enough. A few "native" Windows viruses are
described in chapter four, along with some useful general security and
recovery tips. Unfortunately, the virus detection and recovery tips are
derivative, vague, and not always comprehensive. Chapter five has
explanations of the VBA (Visual Basic for Applications) macro system in
Microsoft Office applications, and lists some common macro viruses.
Chapter six lumps trojans, worms, backdoors, and DDoS (Distributed Denial of
Service) packages together in a somewhat confusing manner. One useful
inclusion in the material is a list of RAT utilized port numbers. The
invention of real-time conferencing, or instant messaging, appears to be
credited to AOL, in chapter seven, although various forms existed long
before AOL's existence. All forms of chat or messaging seem to be lumped
together in the chapter, although it concentrates on the technology and
examples from IRC (Internet Relay Chat).
Chapter eight contains a reasonable overview of Web browser technologies,
although Grimes makes the usual mistakes, such as confusing Secure HyperText
Transfer Protocol (S-HTTP) with the https protocol specifier actually used
by Secure Sockets Layer (SSL). A number of old program bugs and exploits
are described in chapter nine. Most relate to browsers, although some
depend on HTML enabled mail clients. The preventive measures listed,
however, deal strictly with the settings on recent versions of Microsoft's
Internet Explorer, and do not mention other browsers at all. Since Java
applet bugs and exploits have been confined to implementation errors, it is
difficult to understand why chapter ten was included in the book. Again,
some older exploits are described, and there is a bit of confusion in the
text between the applet sandbox model and the full Java security model.
Chapter eleven examines the possibility of the malicious misuses of the
ActiveX system, but first it spends a lot of time and space presenting the
one security aspect of ActiveX: digital signatures. By doing so, Grimes is
giving Microsoft way more than the benefit of the doubt. The text does,
eventually, get around to pointing out some of the flaws in the Authenticode
system, but the structure of the chapter works to downplay the dangers.
In chapter twelve, the Microsoft chauvinism that has been evident in prior
sections ramps up to full throttle. Grimes states that it isn't just
Outlook that can be exploited for e-mail viruses, any mail client could be so
abused. (He later has to tacitly admit that almost no other e-mail client
has been so utilized, and none to the same extent.) There is even a paean
of praise to Windows Script Host, the application that made the Love Bug
possible. The material on virus hoaxes, in chapter thirteen, is a bit of a
mix, but does have a good list of signs to watch for. Defence consists
mainly of a generic security planning process and a reasonable, though
brief, outline of the types of antiviral software, in chapter fourteen.
Chapter fifteen finishes off with the usual look to the future.
Overall, the content is wide-ranging, but not complete. There is coverage
of a broader range of topics than was the case with other recent books, such
as Dunham (cf. BKBVRTPR.RVW) and Schmauder (cf. BKVRSPRF.RVW). However,
depth of research and understanding of the problem is not in evidence. The
material is very questionable in view of the number of errors Grimes makes
in his retailing of details of specific viruses.
While some support and background content is included, the book is written
in a very field independent style: at the end of the chapter you are simply
supposed to do what Grimes tells you to, and believe what he says.
There is virus code in the book. Not extensively, perhaps, but it is there.
Grimes justifies its presence by saying that it is not code for an entire
virus, and that he has made changes to disable it in any case.
Unfortunately, it is real code, for some important sections of viruses, and
the missing and changed bits aren't all that hard to spot. While it would
not allow wannabe vxers to compile a complete virus right off the page, it
would help any semi-competent code dweeb write a more functional virus.
And, all protestations notwithstanding, it doesn't provide any help to the
user or network manager.
Aside from problems with the content, Grimes' organization and writing is
careless and difficult to understand. The chapters address individual
topics, and have a standard structure, but the structure is only a template.
Within each topic the flow of sections and even paragraphs does not always
course logically. The illustrations and figures are not very informative.
This is not a good book on viruses or malware. The breadth of coverage and
detailed content on macro and e-mail virus technology does save it from being
really awful: up to the summer of 2001 no other book has dealt with those
topics in sufficient depth. And the MS-centrism does have one very positive
advantage. If you absolutely must use Microsoft software and applications,
the prevention sections of the various chapters do contain a lot of detail
that will be useful in reducing the risk that you face.
copyright Robert M. Slade, 2001 BKMLMBCD.RVW 20010814
rsladeat_private rsladeat_private sladeat_private p1at_private
http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
------------------------------
Date: 12 Feb 2001 (LAST-MODIFIED)
From: RISKS-requestat_private
Subject: Abridged info on RISKS (comp.risks)
The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
if possible and convenient for you. Alternatively, via majordomo,
send e-mail requests to <risks-requestat_private> with one-line body
subscribe [OR unsubscribe]
which requires your ANSWERing confirmation to majordomoat_private .
[If E-mail address differs from FROM: subscribe "other-address <x@y>" ;
this requires PGN's intervention -- but hinders spamming subscriptions, etc.]
Lower-case only in address may get around a confirmation match glitch.
INFO [for unabridged version of RISKS information]
There seems to be an occasional glitch in the confirmation process, in which
case send mail to RISKS with a suitable SUBJECT and we'll do it manually.
.MIL users should contact <risks-requestat_private> (Dennis Rears).
.UK users should contact <Lindsay.Marshallat_private>.
=> The INFO file (submissions, default disclaimers, archive sites,
copyright policy, PRIVACY digests, etc.) is also obtainable from
http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info
The full info file will appear now and then in future issues. *** All
contributors are assumed to have read the full info file for guidelines. ***
=> SUBMISSIONS: to risksat_private with meaningful SUBJECT: line.
=> ARCHIVES are available: ftp://ftp.sri.com/risks or
ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks
[volume-summary issues are in risks-*.00]
[back volumes have their own subdirectories, e.g., "cd 20" for volume 20]
http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue].
Lindsay Marshall has also added to the Newcastle catless site a
palmtop version of the most recent RISKS issue and a WAP version that
works for many but not all telephones: http://catless.ncl.ac.uk/w/r
http://the.wiretapped.net/security/info/textfiles/risks-digest/ .
http://www.planetmirror.com/pub/risks/ ftp://ftp.planetmirror.com/pub/risks/
==> PGN's comprehensive historical Illustrative Risks summary of one liners:
http://www.csl.sri.com/illustrative.html for browsing,
http://www.csl.sri.com/illustrative.pdf or .ps for printing
------------------------------
End of RISKS-FORUM Digest 21.72
************************
This archive was generated by hypermail 2b30 : Tue Oct 30 2001 - 11:03:00 PST