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 42

Weds 11 December 2002


A little bit of anti-porn filtering can go a long way
Ironic filtering
Ray Dillinger in rec.humor.funny via Dawn Cohen
Impostor eBay site set up to steal credit info
Feds raid Ptech looking for al Qaeda link
Web Surfers: What could they be thinking?
UK police offer anonymity to cybercrime victims
Anti-worm "throttling"
Rob Slade
More on dangers of spelling correctors
Gene Spafford
Your empty mailbox is full
Peter Kaiser
Re: Windows 2000 EAL4 Evaluation
Rick Smith
REVIEW: "VPNs: A Beginner's Guide", John Mairs
Rob Slade
REVIEW: "IPSec: Securing VPNs", Carlton Davis
Rob Slade
Info on RISKS (comp.risks)

A little bit of anti-porn filtering can go a long way

<"NewsScan" <>>
Wed, 11 Dec 2002 09:54:22 -0700

"A little bit of filtering is O.K., but more isn't necessarily better," says
Vicky Rideout, vice president of the Henry J. Kaiser Family Foundation,
which conducted a study showing that when anti-pornography Internet
filtering software is set at a low level of restriction, it's just as
effective as when it is set a high level, and is far less likely to prevent
searchers from reaching bona fide health sites. But some observers, such as
Judith F. Krug of the American Library Association, think that filters are
such blunt instruments that they should not be used at all in public
institutions: "Filters are just fine for parents to use at home.  They are
not appropriate for institutions that might be the only place where kids can
get this information." The filtering programs generally block any references
to sex-related terms; examples given by the report include such subjects as
safe sex, condoms, abortion, jock itch, gay, and lesbian.  [*The New York
Times*, 11 Dec 2002; NewsScan Daily, 11 December 2002]

Ironic filtering (Ray Dillinger in rec.humor.funny)

<"Dawn Cohen" <>>
Fri, 06 Dec 2002 09:38:42 -0500

Freedom of sXYZch (Ray Dillinger)

(smirk, computers)

"Congress shall make no law abridging the freedom of sXYZch, or the right
of the people peaceably to XYZemble, and to peXYZion the government for a
redress of grievances."

  -- but your ISP might.

  [This item also noted by Carl Ellison.  I changed the three-X strings
  in Ray's original piece to YXZ, in order to avoid having this issue
  ex-filtrated.  PGN]

Impostor eBay site set up to steal credit info

<"NewsScan" <>>
Wed, 11 Dec 2002 09:54:22 -0700

A Web site called, having no relation to the eBay auction
site, was created as part of a scam to obtain credit information
fraudulently from eBay customers. The scam was discovered by the private
Internet watchdog group SANS Institute Internet Storm Center, and was
confirmed by an eBay executive who said: "Some members have reported
attempts to gain access to their personal information through e-mail
solicitations that are falsely made to appear as having come from eBay.
These solicitations will often contain links to Web pages that will request
that you sign in and submit information. eBay employees will never ask you
for your password."  [Reuters/*San Jose Mercury News*, 11 Dec 2002; NewsScan
Daily, 11 December 2002

Feds raid Ptech looking for al Qaeda link

<"Peter G. Neumann" <>>
Tue, 10 Dec 2002 13:07:17 PST

On 6 Dec 2002, Federal agents raided Ptech in Quincy, Massachusetts,
reportedly under suspicion of financial links to Osama bin Laden.  Ptech
provides unclassified software to many U.S. Government agencies and armed
services), and thus there suspicions were raised regarding possible Trojan
horses installed in their software.  However, on 9 Dec 2002, Justice
Department officials said that they do not have any reason to believe any
federal systems have been compromised.  The search was reportedly done "in
connection with an on-going financial crime investigation," according to a
U.S. Attorney, rather than part of any terrorist investigations.
[Sources: (1) Feds Raid Boston Area Computer Firm Suspected of Links to Al
Qaeda Brian Ross, 6 Dec 2002, courtesy of Monty Solomon
(2) Justice states Ptech presents no security risk, Wilson P. Dizard III
and Patience Wait, *Post Newsweek Tech Media*, 9 Dec 2002, courtesy of
Lillie Coney at ACM; severely-PGN-ed]

Web Surfers: What could they be thinking?

<"NewsScan" <>>
Tue, 10 Dec 2002 08:47:04 -0700

A study by Aaron Schatz has found that the top ten search terms used on
Lycos Net this year have been: 1, Dragonball (the Japanese cartoon); 2,
Kazaa (the music and video file-swapping service); 3, tattoos (that's right
-- tattoos); 4, Britney Spears, the pop singer who, oops, did it again; 5,
Morpheus (file-swapping); 6, NFL, the National Football League; 7, IRS; 8,
Halloween; 9, Christmas; and 10, Pamela Anderson, the actress and, uh,
celebrity icon. Schatz says, "No matter how the news ebbs and flows, people
still use the Internet for entertainment." So we see. There just doesn't
appear to be that big a demand for information on the origins of the First
World War.  [*USA Today*, 10 Dec 2002; NewsScan Daily, 10 December 2002]

UK police offer anonymity to cybercrime victims

<"Peter G. Neumann" <>>
Tue, 10 Dec 2002 10:24:15 PST

To overcome the natural reticence companies have against exposing the cases
in which they have been victimized by digital attacks, Britain's National
Hi-Tech Crime Unit (NHTCU) says it will grant full anonymity to businesses,
if they are forthcoming.  This is of course not a new concept, but is being
tried in hopes it will encourage greater cooperation.  [Source:
zdnet/Reuters, 9 Dec 2002; PGN-ed, courtesy of Keith Rhodes]

Anti-worm "throttling"

<Rob Slade <>>
Mon, 9 Dec 2002 12:36:10 -0800

In a number of recent presentations, I have been asked about virus "traps"
or "tarpits."  The references are to the idea of throttling, and I have
finally found the actual paper, rather than the news stories about it:

The idea is simple and (within a limited scope) potentially quite effective.
Simply include, in the network stack, programming to limit the number of
connections that any computer is making.  In particular, limit "new"
connections, to machines not normally dealt with.  This ensures that normal
work, at human generated speeds, proceeds normally, while automated, random
connections are restricted.

There are a few caveats to make.  The paper refers to viruses, and, of
course, what throttling would block are not viruses but classic worms, which
make direct connections to other machines.  In particular, email viruses
might be somewhat restricted, but a Melissa or Loveletter situation would
likely be slowed only marginally: connections to the regular mail server
would not be "new."  Throttling will only be effective against "fast
burners": it would definitely help in a situation like the Code Red
infestation where a third of a million machines were infected within hours.
Slower infectors would be less impeded, and a number of viruses and worms
restrict their own spread in order to avoid detection.  In addition, a
number of viruses now work by replacing the network stack, and therefore
this protection would be lost, unless additional protections were layered
around the stack.  (It would also be fairly simple for viruses or worms to
simply start carrying their own network stack.)    or

More on dangers of spelling correctors

<Gene Spafford <>>
Sun, 8 Dec 2002 14:12:39 -0500

So, in one of my many editorial positions, I sent something out for review
to several colleagues.  One question I asked was "Is this paper
significantly different from the same authors' workshop XYZ paper?  If not,
then we will not publish it again, as a matter of editorial policy."

One of the reviewers returned a review that was negative but
insightful.   However, it ended with:

  "I think that the paper published in XYZ Workshop is a core
  part of this paper, although the authors did add some new
  excrement results."

Well, I think that sums up the rest of the reviews I have seen about the
paper, but perhaps a bit more candidly than usual! :-)

I asked (politely) if something else had been intended and a transcription
error had occurred.  I got as a response:

  "Very Sorry!! It should be "experiment". It's a typo. MS Outlook corrected
  it as "excrement" when it checks spelling and I didn't pay
  attention.... Very embarrassing, but it's all Bill Gates' fault."

Yet another reason I don't use Outlook.....

  [Mor(e-)on spelling correctors?  PGN]

Your empty mailbox is full

<Peter Kaiser <>>
Tue, 10 Dec 2002 19:39:33 +0100

Once upon a time I was the customer of a local ISP, Internet Access AG,
that had an excellent support line, competent people, and excellent dialup
coverage here in Switzerland.  They were bought out by a third-tier
telephone company that needed an ISP arm quickly.  Things were undisturbed:
same e-mail address, same people, same location, same quality of service.

Somewhat later the third-tier company was bought out by a second-tier
telephone company, call it Sunrays.  I could keep the old address.  I was
still a paying customer, although Sunrays also offers free accounts.

Sunrays has a history of obtuseness about the Internet and Internet service
-- for instance they don't seem able to distinguish what should and what
needn't be done through secure web pages, they mix languages carelessly
(pages are available in German, French, Italian and English), and the FAQs
are a bad joke.  Long ago I remarked this to a company officer I know
socially, and his response was a shrug and a "not my department".

This didn't matter much to me, though.  I use their Internet service only
for mail, directly through a POP3 server.

Late last week they began rejecting my incoming mail, and all that was in
in my POP3 mailbox was this message:

    Your mailbox is full! It is currently over its allowed capacity.

But except for that message the mailbox was empty.

Here I discovered that even for paying customers their only Internet
support other than the FAQs is a premium-priced phone line, another example
of not getting it.  (I omit a long and familiar kind of tale about how long
it took and what I had to do to get anyone to pay attention to the

Here's what had happened.

On 7 August, with no notice to me, they began filtering spam.  The filtered
mail is directed to a mail folder named "Spam" which is visible only to
users of the browser interface or MS Outlook.  I use neither.  Between
August and late last week they had filed enough mail there to occupy my
account's entire storage quota.  I was eventually told I had to log on to
the Web interface -- my first time using it -- where I was able to see the
situation and empty that folder.  He tells me they're thinking of sweeping
spam folders automatically when they near being over quota, but that's for
the future.

After clearing out all the spam -- there seemed to be no false positives,
which is consistent with how much still gets through -- I went to the
"personalization" page, where I checked the box for Sunrays to send me
their Internet-matters newsletter.  But the server wouldn't accept that
change unless I also added a whole lot of other information including my
birthdate, telephone number, address, and many other things they have no
need to know, or already have on file.  So no change.

Obviously there's a lot wrong here.

It's clearly a RISK to assume that all their customers are using the mail
service through their web interface, where Sunrays may well have posted
something about their technique of filtering spam.  As a matter of fact,
they know perfectly well that some customers are using POP3, because one of
their rare useful FAQs is a POP3 how-to for the Eudora mail client.

It's clearly RISKy to send an unclear message when you could perfectly well
send an informative one.

It's RISKy to send such messages only when the damage has already been
done; for instance, they should send (informative) warning messages long
before the user's space is over quota.

And so on.  As remarked above, they really don't get it.  I'll be shopping
for a better service.  And perhaps offering them my own services, since I
can be bought.  But I don't expect them to understand any of this.

Re: Windows 2000 EAL4 Evaluation

<Rick Smith <>>
Thu, 05 Dec 2002 23:25:41 -0700

While on one hand I don't believe that EAL4 is an especially strong
statement, particularly given the protection profile being used, I think
Jonathan Shapiro's comments miss the mark.

Today, EAL4 is the best we're going to see in a large scale commercial
product evaluation. The security community barely knows how to do EAL4 in a
consistent, cost-effective manner: don't expect to see higher levels except
for small-scale things like smart cards.

If EAL4 doesn't provide value to the customers of the evaluated products,
then our whole notion of evaluation is flawed (and it just might be).

Regarding EAL7:

>As I mentioned before, EAL levels run from 1 to 7. EAL1 basically means that
>the vendor showed up for the meeting. EAL7 means that key parts of the
>system have been rigorously verified in a mathematical way.

EAL7 isn't the solution, it's just another problem. We're still learning
what "key parts" we're supposed to verify, and what it is we might want to
prove about them. Windows has huge chunks of behavior that people rely on
every day, and only a tiny fraction of those behaviors can be effectively
modeled in a mathematical way. Without a rigorous model you can't do that
rigorous proof, and we aren't going to give up word processing simply
because we can't prove mathematically that "undo" always works correctly.

Regarding EAL4:

>EAL4 means that the design documents were reviewed using non-challenging
>criteria. This is sort of like having an accounting audit where the auditor
>checks that all of your paperwork is there and your business practice
>standards are appropriate, but never actually checks that any of your
>numbers are correct.  An EAL4 evaluation is not required to examine the
>software at all.

While I like the choice of an audit as an analogy, the analogy is wrong.

Having lived through various evaluation activities, I can attest to the fact
that you DO have to show that your numbers are correct, even at EAL4, and
you have to show it in the manner that most third parties are going to
respect: you do a lot of requirements-based testing and you have to show
that the testing covers all of your security requirements.

While it is true that the criteria for the design document review might not
be especially strict, at least in comparison to doing formal proofs, that
part of the process gets very expensive, especially for US-based
evaluations. Why? Because you can't use your off-the-shelf design documents:
you have to rewrite them to satisfy the evaluators. This is getting better,
but it's still a source of high costs and uncertain schedules.

>An EAL4 rating means that you did a lot of paperwork related to the software
>process, but says absolutely nothing about the quality of the software
>itself. There are no quantifiable measurements made of the software, and
>essentially none of the code is inspected. Buying software with an EAL4
>rating is kind of like buying a home without a home inspection, only more

Very wrong. Home inspections are based on external inspections of major
components and possibly a few tests like water quality, radon, lead,
asbestos, etc. Inspectors rarely disassemble the house to compare the
internal structure against the blueprints. And few home inspectors actually
try to burn the flameproof drapes, but that's what you'd need to do for EAL4
if your Security Target says your drapes are flameproof.

>Security isn't something that a large group can do well. It is something
>achieved by small groups of experts. Adding more programmers and more
>features makes things worse rather than better. Microsoft has been adding
>features demanded by their customers for a very long time.

I'd argue that the problem isn't so much the size of the team as it is the
discipline applied to managing the architecture. Without a strong security
architecture in place, it doesn't matter how many people work on the system
-- it'll still be Swiss cheese.

>It is possible to do much better. EROS, a research operating system that we
>are working on here in the Systems Research Laboratory at Johns Hopkins
>University, should eventually achieve an EAL7 evaluation rating, and is
>expected to provide total defense against viruses and malicious code.

I think such systems will provide a strong basis for special-purpose
devices, but I doubt they'll replace desktop systems, which become a lot
like one's office: a mishmash of what you need to get through the day and
hopefully be productive. If people have EROS on their desktops, it'll stay
virus proof right up until they start installing all those virus-enabled
e-mail products and word processors they love so much. This is a variant of
the "GOVNET" problem - GOVNET was a boondoggle because it focused on ISO
layers 4 and below, ignoring the growing problem of virus-laced e-mail and
shared Word documents.

Rick Smith ( Oxford International, Scottsdale, AZ

  [The most fundamental problem with the evaluation process is that the
  evaluation is done against criteria evaluation profiles that are
  established by the organization seeking evaluation.  The MS EAL4 is rather
  lame primarily because the evaluation profiles are not very comprehensive.
  However, as Rebecca Mercuri's thesis shows in her casting of electronic
  voting systems into the Common Criteria framework, EVEN IF THE EVALUATION
  significant security vulnerabilities can still remain.  PGN]

REVIEW: "VPNs: A Beginner's Guide", John Mairs

<Rob Slade <>>
Fri, 22 Nov 2002 07:42:10 -0800

BKVPNABG.RVW   20020928

"VPNs: A Beginner's Guide", John Mairs, 2002, 0-07-219181-3, U$39.99
%A   John Mairs
%C   300 Water Street, Whitby, Ontario   L1N 9B6
%D   2002
%G   0-07-219181-3
%I   McGraw-Hill Ryerson/Osborne
%O   U$39.99 +1-800-565-5758 +1-905-430-5134 fax: 905-430-5020
%P   584 p.
%T   "VPNs: A Beginner's Guide"

Part one deals with networks and security.  The material is not bad;
in fact, it is very good; but it is, possibly, too much information on
topics which are not, really, relevant to virtual private networks
(VPNs).  On the other hand, anyone who is a rank beginner to
networking as well will certainly have a thorough introduction.

Chapter one covers layering architecture and the OSI (Open Systems
Interconnection) model, and the text on encapsulation is definitely
relevant to VPNs.  Network architecture, in chapter two, concentrates
on topology and the physical layer.  There is a detailed reference to
the lower layers of the TCP/IP protocol stack in chapter three.
Chapter four's explanation of the basics of security is good, absent
some material on threats and parts of risk analysis, but the use of
non-standard language may be confusing.  Threats and attack methods,
in chapter five, is weak: the text lists a variety of network protocol
exploits, concentrating on spoofing, and doesn't really bring out the
concepts.  The explanations of intrusion detection systems and
firewalls, in chapters six and seven respectively, are good overviews.

Part two is supposed to provide the fundamentals of VPNs themselves,
but, rather oddly, does a much poorer job on this central idea than on
the previous and following content.  Chapter eight is on VPN basics,
and nine is on VPN architecture.

Part three covers VPN protocols.  Chapter ten introduces the tunneling
protocols of GRE (Generic Routing Encapsulation) and PPTP (Point-to-
Point Tunneling Protocol).  L2F (Layer 2 Forwarding) and L2TP (Layer 2
Tunneling Protocol), plus a little bit of IPSec, are reviewed in
chapter eleven, although it is not always clear what functions are

Part four looks at secure communications.  The material on
cryptography, in chapter twelve, is not very good: polyalphabetic
ciphers are *not* examples of transposition, there is some use of non-
standard terminology, the text is simplistic in many areas, and the
discussion of key management with asymmetric systems is quite weak.
There are similarly feeble explanations and minor errors with respect
to cryptographic algorithms in chapter thirteen.  The discussion of
certificates, in chapter fourteen, is more reasonable, although the
section on PKI (Public Key Infrastructure) is a bit terse.  Chapter
fifteen, on authentication, reprises earlier content on identification
and authentication (chapter four), PAP (Password Authentication
Protocol, chapter ten), CHAP (Challenge Handshake Authentication
Protocol, chapter eleven), but adds discussion of RADIUS, TACACS, and
Kerberos, at varying levels of detail.

Part five delves into the details of IPSec.  Chapter sixteen outlines
the components of IPSec, although it is somewhat disjointed with
repeated returns to the topics of security associations and the
different operating modes.  Key management, in chapter seventeen,
introduces ISAKMP (Internet Security Association and Key Management
Protocol) and IKE (Internet Key Exchange), but does not do so in the
detail with which other protocols have been discussed, and does not
address the weaknesses of the systems.  For some reason the details,
and some other key management and exchange protocols, are in chapter
eighteen (but still limited analysis).  Chapter nineteen does have
good deliberations on IPSec architecture and implementation.

Part six deals with MPLS (Multi-Protocol Label Switching).  Chapter
twenty talks about quality of service, and related technologies.  A
few topics associated with traffic engineering are discussed in
chapter twenty one.  MPLS is proposed as the answer to quality of
service and traffic engineering issues in chapter twenty two.  Chapter
twenty three outlines some of the components of MPLS and finally
explains what MPLS has to do with VPNs, although not in much detail.

With some caveats about certain sections of the book, I can recommend
this both as a reference to a number of VPN technologies, and to some
security related issues with TCP/IP.

copyright Robert M. Slade, 2002   BKVPNABG.RVW   20020928

REVIEW: "IPSec: Securing VPNs", Carlton Davis

<Rob Slade <>>
Mon, 2 Dec 2002 08:00:16 -0800

BKIPSECS.RVW   20021001

"IPSec: Securing VPNs", Carlton Davis, 2001, 0-07-212757-0,
%A   Carlton Davis
%C   300 Water Street, Whitby, Ontario   L1N 9B6
%D   2001
%G   0-07-212757-0
%I   McGraw-Hill Ryerson/Osborne
%O   U$49.99/C$79.95/UK#36.99 800-565-5758 fax: 905-430-5020
%P   404 p.
%T   "IPSec: Securing VPNs"

Chapter one is an overview of TCP/IP.  The material is generally good,
but does demonstrate a possible weakness of the book: we are provided
with way too much information about a number of areas that are not
relevant to IPSec.  A similar overabundance of detail (and math)
describes symmetric cryptography, in chapter two.  Oddly, given the
level of particulars in other areas, there is no analysis of the
weakness of double DES (Data Encryption Standard).  Operational
specifics of the various AES (Advanced Encryption Standard) candidates
are also included.  The mathematical basis of asymmetric cryptography,
in chapter three, is not explained as well as symmetric is.  In
dealing with hashes and message authentication codes, chapter four has
lots of math and almost no other discussion.  Chapter five provides
extensive details about X.509 attribute fields, for digital
certificates, and also has a bit of material on PGP (Pretty Good
Privacy) and key recovery.  The fields of LDAP (Lightweight Directory
Access Protocol) are outlined in chapter six.

Chapter seven finally talks, very briefly, about IPSec architecture,
repeating (from chapter one) the specifics of the IP header, and
mentioning some of the components of IPSec.  Chapters eight, nine, and
ten concentrate of the header structure of AH (Authentication Header),
ESP (Encapsulating Security Payload), and ISAKMP (Internet Security
Association Key Management Protocol) packets, albeit chapter ten also
covers a bit of the handshaking process.  There is very little
discussion of strengths and weaknesses.  There are lots of details
related to IKE (Internet Key Exchange) in chapter eleven, but
surprisingly little information about what it does or how it works.
The header structure and options for the compression function, IPComp,
are given in chapter twelve.  Chapter thirteen is supposed to talk
about implementation, but has a fairly generic example of a VPN and
some screen shots from a commercial product.

Overall, the book contains lots of technical details, but very little
in the way of explanation, discussion, or analysis.  You would
probably learn just as much about IPSec by reading the RFCs

copyright Robert M. Slade, 2002   BKIPSECS.RVW   20021001

Please report problems with the web pages to the maintainer