CRYPTO-GRAM, May 15, 2000

[Bruce Schneier <schneier@counterpane.com>]

[: hacktivism :]

                  CRYPTO-GRAM

                 May 15, 2000

               by Bruce Schneier
                Founder and CTO
       Counterpane Internet Security, Inc.
            schneier@counterpane.com
           http://www.counterpane.com


A free monthly newsletter providing summaries, analyses, insights, and 
commentaries on computer security and cryptography.

Back issues are available at http://www.counterpane.com.  To subscribe or 
unsubscribe, see below.


Copyright (c) 2000 by Counterpane Internet Security, Inc.


** *** ***** ******* *********** *************

In this issue:
      Computer Security: Will We Ever Learn?
      Counterpane Internet Security News
      News
      The Doghouse: Cybercrime Treaty
      More on Microsoft Kerberos
      Trusted Client Software
      ILOVEYOU Virus
      Comments from Readers


** *** ***** ******* *********** *************

     Computer Security: Will We Ever Learn?



If we've learned anything from the past couple of years, it's that computer 
security flaws are inevitable.  Systems break, vulnerabilities are reported 
in the press, and still many people put their faith in the next product, or 
the next upgrade, or the next patch.  "This time it's secure," they 
say.  So far, it hasn't been.

Security is a process, not a product.  Products provide some protection, 
but the only way to effectively do business in an insecure world is to put 
processes in place that recognize the inherent insecurity in the 
products.  The trick is to reduce your risk of exposure regardless of the 
products or patches.

Consider denial-of-service attacks.  DoS attacks are some of the oldest and 
easiest attacks in the book.  Even so, in February 2000, coordinated, 
distributed DoS attacks easily brought down several high-traffic Web sites, 
including Yahoo, eBay, Amazon.com and CNN.

Consider buffer overflow attacks.  They were first talked about as early as 
the 1960s -- time-sharing systems suffered from the problem -- and were 
known by the security literati even earlier than that.  In the 1970s, they 
were often used as a point of attack against early networked computers.  In 
1988, the Morris Worm exploited a buffer overflow in the Unix fingerd 
daemon: a very public use of this type of attack.

Today, over a decade after Morris and about 35 years after these attacks 
were first discovered, you'd think the security community would have solved 
the problem of security vulnerabilities based on buffer overflows.  Think 
again.  Over two-thirds of all CERT advisories in 1998 were for 
vulnerabilities caused by buffer overflows.  During an average week in 
1999, buffer overflow vulnerabilities were found in the RSAREF 
cryptographic toolkit (oops), HP's operating system, the Solaris operating 
system, Microsoft IIS 4.0 and Site Server 3.0, Windows NT, and Internet 
Explorer.  A recent study named buffer overflows as the most common 
security problem.

Consider encryption algorithms.  Proprietary secret algorithms are 
regularly published and broken.  Again and again, the marketplace learns 
that proprietary secret algorithms are a bad idea.  But companies and 
industries -- like Microsoft, the DVD consortium, cellular phone providers, 
and so on -- continue to choose proprietary algorithms over public, free 
alternatives.

Is Anyone Paying Attention?

Sadly, the answer to this question is: not really.  Or at least, there are 
far fewer people paying attention than should be.  And the enormous need 
for digital security products necessitates people to design, develop and 
implement them.  The resultant dearth of experts means that the percentage 
of people paying attention will get even smaller.

Most products that use security are not designed by anyone with security 
expertise.  Even security products are generally designed and implemented 
by people who have only limited security expertise.  Security cannot be 
functionality tested -- no amount of beta testing will uncover security 
flaws -- so the flaws end up in fielded products.

I'm constantly amazed by the kinds of things that break security 
products.  I've seen a file encryption product with a user interface that 
accidentally saves the key in the clear.  I've seen VPNs where the 
telephone configuration file accidentally allows a random person to 
authenticate himself to the server, or that allows one remote client to 
view the files of another remote client.  There are a zillion ways to make 
a product insecure, and manufacturers manage to stumble on a lot of those 
ways again and again.

No one is paying attention because no one has to.

Computer security products, like software in general, have a very odd 
product quality model.  It's unlike an automobile, a skyscraper, or a box 
of fried chicken.  If you buy a product, and get harmed because of a 
manufacturer's defect, you can sue...and you'll win.  Car-makers can't get 
away with building cars that explode on impact; chicken shops can't get 
away with selling buckets of fried chicken with the odd rat mixed in.  It 
just wouldn't do for building contractors to say thing like, 
"Whoops.  There goes another one.  Sorry.  But just wait for Skyscraper 
1.1; it'll be 100% collapse-free!"

Software is different.  It is sold without any claims whatsoever.  Your 
accounts receivable database can crash, taking your company down with it, 
and you have no claim against the software company.  Your word processor 
can accidentally corrupt your files and you have no recourse.  Your 
firewall can turn out to be completely ineffectual -- hardly better than 
having nothing at all -- and yet it's your fault.  Microsoft fielded 
Hotmail with a bug that allowed anyone to read the accounts of 40 or so 
million subscribers, password or no password, and never bothered to apologize.

Software manufacturers don't have to produce a quality product because 
there is no liability if they don't.  And the effect of this for security 
products is that manufacturers don't have to produce products that are 
actually secure, because no one can sue them if they make a bunch of false 
claims of security.

The upshot of this is that the marketplace does not reward real 
security.  Real security is harder, slower, and more expensive, both to 
design and to implement.  Since the buying public has no way to 
differentiate real security from bad security, the way to win in this 
marketplace is to design software that is as insecure as you can possibly 
get away with.

Microsoft knows that reliable software is not cost effective.  According to 
studies, 90% to 95% of all bugs are harmless.  They're never discovered by 
users, and they don't affect performance.  It's much cheaper to release 
buggy software and fix the 5% to 10% of bugs people find and complain about.

Microsoft also knows that real security is not cost-effective.  They get 
whacked with a new security vulnerability several times a week.  They fix 
the ones they can, write misleading press releases about the ones they 
can't, and wait for the press fervor to die down (which it always 
does).  And six months later they issue the next software version with new 
features and all sorts of new insecurities, because users prefer cool 
features to security.

The only solution is to look for security processes.

There's no such thing as perfect security.  Interestingly enough, that's 
not necessarily a problem.  In the U.S. alone, the credit card industry 
loses $10 billion to fraud per year; neither Visa nor MasterCard is showing 
any sign of going out of business.  Shoplifting estimates in the U.S. are 
currently between $9.5 billion and $11 billion per year, but you never see 
"shrinkage" (as it is called) cited as the cause when a store goes out of 
business.  Recently, I needed to notarize a document.  That is about the 
stupidest security protocol I've ever seen.  Still, it works fine for what 
it is.

Security does not have to be perfect, but the risks have to be 
manageable.  The credit card industry understands this.  They know how to 
estimate the losses due to fraud.  Their problem is that losses from phone 
credit card transactions are about five times the losses from face-to-face 
transactions (when the card is present).  Losses from Internet transactions 
are many times those of phone transactions, and are the driving force 
behind SET.

My primary fear about cyberspace is that people don't understand the risks, 
and they are putting too much faith in technology's ability to obviate 
them.  Products alone cannot solve security problems.

The digital security industry is in desperate need of a perceptual 
shift.  Countermeasures are sold as ways to counter threats.  Good 
encryption is sold as a way to prevent eavesdropping.  A good firewall is a 
way to prevent network attacks.  PKI is sold as trust management, so you 
can avoid mistakenly trusting people you really don't.  And so on.

This type of thinking is completely backward.  Security is old, older than 
computers.  And the old-guard security industry thinks of countermeasures 
not as ways to counter threats, but as ways to avoid risk.  This 
distinction is enormous.  Avoiding threats is black and white: either you 
avoid the threat, or you don't.  Avoiding risk is continuous: there is some 
amount of risk you can accept, and some amount you can't.

Security processes are how you avoid risk.  Just as businesses use the 
processes of double-entry bookkeeping, internal audits, and external audits 
to secure their financials, businesses need to use a series of security 
processes to protect their networks.

Security processes are not a replacement for products; they're a way of 
using security products effectively.  They can help mitigate the 
risks.  Network security products will have flaws; processes are necessary 
to catch attackers exploiting those flaws, and to fix the flaws once they 
become public.  Insider attacks will occur; processes are necessary to 
detect the attacks, repair the damages, and prosecute the attackers.  Large 
systemwide flaws will compromise entire products and services (think 
digital cell phones, Microsoft Windows NT password protocols, or DVD); 
processes are necessary to recover from the compromise and stay in business.

Here are two examples of how to focus on process in enterprise network 
security:

1.  Watch for known vulnerabilities.  Most successful network-security 
attacks target known vulnerabilities for which patches already 
exist.  Why?  Because network administrators either didn't install the 
patches, or because users reinstalled the vulnerable systems.  It's easy to 
be smart about the former, but just as important to be vigilant about the 
latter.  There are many ways to check for known vulnerabilities.  Network 
vulnerability scanners like Netect and SATAN test for them.  Phone scanners 
like PhoneSweep check for rogue modems inside your corporation.  Other 
scanners look for Web site vulnerabilities.  Use these sorts of products 
regularly, and pay attention to the results.

2.  Continuously monitor your network products.  Almost everything on your 
network produces a continuous stream of audit information: firewalls, 
intrusion detection systems, routers, servers, printers, etc.  Most of it 
is irrelevant, but some of it contains footprints from successful 
attacks.  Watching it all is vital for security, because an attack that 
bypassed one product might be picked up by another.  For example, an 
attacker might exploit a flaw in a firewall and bypass an IDS, but his 
attempts to get root access on an internal server will appear in that 
server's audit logs.  If you have a process in place to watch those logs, 
you'll catch the intrusion in progress.

In this newsletter and elsewhere I have written pessimistically about the 
future of computer security.  The future of computers is complexity, and 
complexity is anathema to security.  The only reasonable thing to do is to 
reduce your risk as much as possible.  We can't avoid threats, but we can 
reduce risk.

Nowhere else in society do we put so much faith in technology.  No one has 
ever said, "This door lock is so effective that we don't need police 
protection, or breaking-and-entering laws."  Products work to a certain 
extent, but you need processes in place to leverage their effectiveness.


A version of this essay originally appeared in the April issue of 
_Information Security_ magazine.
<http://www.infosecuritymag.com/apr2000/cryptorhythms.htm>


** *** ***** ******* *********** *************

       Counterpane Internet Security News



You've probably been wondering what Counterpane has been doing since last 
summer.  We've changed our name to Counterpane Internet Security, 
Inc.  We're no longer providing consulting services.  We've hired 95 
people.  The old Counterpane Systems has become Counterpane Labs, the 
research arm of the larger company.  And we're addressing the real problems 
of computer security.

You never see a door lock advertised with the slogan: "This lock will 
prevent burglaries."  In computer security, you see this kind of thing all 
the time.  "Encryption prevents eavesdropping."  "Firewalls prevent network 
penetration."  "PKI prevents impersonation."  It's actually not true.

When you buy a safe, it comes with a rating.  "30TL" -- 30 minutes, 
tools.  "60TLTR" -- 60 minutes, tools and torch.  What this means is that a 
professional safecracker, with safecracking tools and an oxyacetylene 
torch, will need an hour to break open the safe.  If the alarm doesn't 
sound, and guards don't come running, within that hour, the safe is 
worthless.  All that safe buys you is time; you have to spend it wisely.

Prevention.  Detection.  Response.  The computer-security industry has 
concentrated on protection, and has largely ignored detection and 
response.  Intrusion-detection systems sound alarms, but unless there is 
someone to respond, it is no better than a car alarm that everyone 
ignores.  This doesn't make sense.

If the protection mechanisms were perfect, you wouldn't need detection and 
response.  If the safe could withstand safecrackers indefinitely, you 
wouldn't have to bother with alarms.  If your firewalls never had any 
security bugs or were never misconfigured, if the encryption were always 
perfect, and if the PKI never had any vulnerabilities, you wouldn't need 
detection and response.

But no computer security product is perfect.  Every day new security 
vulnerabilities are discovered in operating systems, server software, 
Internet applications, firewalls and other security devices.  These 
products show no signs of getting more secure; if anything, the increasing 
complexity of the Internet is driving them towards being even less 
secure.  You need detection and response.

Counterpane Internet Security, Inc. provides that detection and 
response.  We're a managed security monitoring service.  We don't replace 
your existing security products: your firewalls, VPNs, IDSs, PKIs, servers, 
routers.  We love those products, and want them to get better and 
better.  What we do is watch them.

We send their alerts to our trained security analysts, and contact you when 
we notice a security breach.  We're your Internet alarm company.  We 
augment your prevention products with a detection and response 
service.  It's the only way to maintain security in today's networked world.

Counterpane Internet Security, Inc. does not sell security products; we 
only sell the service.  We've realized that the fundamental problems in 
security are no longer about technology; they're about how to use the 
technology.  Visit the Counterpane Web site; I look forward to explaining 
our company further.

Company Web site:
<http://www.counterpane.com>

A white paper on what we're doing:
<http://www.counterpane.com/whitepaper.html>

A brochure:
<http://www.counterpane.com/brochure2.html>

Press:
<http://www10.nytimes.com/library/tech/00/04/biztech/articles/03code.html>
<http://news.cnet.com/news/0-1007-200-1626469.html?tag=st.ne.fd.lthd.1007-20 
0-1626469>
<http://www.nwfusion.com/news/2000/0403intrusion.html>
<http://www.thestandard.com/article/display/0,1151,13474,00.html>

Counterpane's launch:
<http://www.counterpane.com/pr-unveiling.html>

Counterpane's partners:
<http://www.counterpane.com/pr-partners.html>

Counterpane's funding:
<http://www.counterpane.com/pr-funding.html>

The importance of vigilance (written by Schneier):
<http://www.zdnet.com/special/stories/defense/0,10459,2510681,00.html>


** *** ***** ******* *********** *************

                     News



Yet another classified laptop stolen, this time a U.S. State Department one:
<http://www.cnn.com/2000/US/04/17/state.computer.02/index.html>
<http://www.computerworld.com/home/print.nsf/all/000419D6BA>
<http://news.cnet.com/news/0-1003-200-1708583.html>
<http://www.gcn.com/vol19_no9/news/1783-1.html>
And still more:
<http://www.zdnet.com/zdnn/stories/newsbursts/0,7407,2562861,00.html>

Intel is dropping the unique serial number in its microprocessors.  This is 
good news, and Intel should be applauded for this move.
<http://yahoo.cnet.com/news/0-1006-200-1773089.html?pt.yfin.cat_fin.txt.ne>

After almost two years of study, a secret committee of the German 
government has concluded that Internet attacks will supplant military 
conflicts in coming years.
<http://www.zdnet.com/enterprise/stories/main/0,10228,2504525,00.html>

An article on U.S. military security classifications:
<http://www.ostgate.com/classification.html>

No one was surprised when the Russian government said that they were going 
to eavesdrop on the Internet, but now the UK government wants to read your 
e-mail:
<http://www.the-times.co.uk/news/pages/sti/2000/04/30/stinwenws01034.html>

Interesting commentary on the "backdoor password" in Red Hat Linux.
<http://www.securityfocus.com/commentary/25>

A balanced, and skeptical, article on Echelon:
<http://www.thebulletin.org/issues/2000/ma00/ma00richelson.html>

Yet another reason why it makes no sense to hide the lists of URLs that 
content filters filter:
<http://www.news.com/Perspectives/Column/0,176,421,00.html>

Convicted hacker Kevin Mitnick was released from jail on probation a few 
months ago.  Since then he's written for magazines, testified in front of 
Congress, and done various public speaking gigs.  Suddenly his parole 
officer wants him to shut up.  Mitnick responds, publicly:
<http://news.cnet.com/news/0-1005-200-1781398.html?tag=st.ne.1002.bgif.1005- 
200-1781398>

More invasions of privacy on the way, this one via your ISP:
<http://www.vortex.com/privacy/priv.09.13>

Good article on _Database Nation_:
<http://www.oreillynet.com/pub/a/network/2000/04/27/garfinkel/index.html>
...which is an excellent book (by the way).
<http://www.oreilly.com/catalog/dbnation/>

More information on UCITA.  The moral seems to be that it's smarter to 
spend your lobbying dollars at the state level than to risk it in an 
all-or-none federal bill.  This whole thing is VERY dangerous.
<http://www.infoworld.com/articles/op/xml/00/04/24/000424opfoster.xml>

Microsoft is touting biometrics as the solution to its security problems.
<http://www.wired.com/news/business/0,1367,36050,00.html>
<http://www.msnbc.com:80/news/402255.asp?cp1=1>
<http://news.excite.com:80/news/r/000502/18/tech-microsoft-biometrics>
<http://library.northernlight.com/FA20000503570000125.html?cb=0&dx=1006&sc=0>
This announcement borders on ludicrous.  Biometrics will do nothing to 
improve the general state of Windows security, and will have no effect on 
most of the security problems they have been suffering.  And even on a good 
day, biometrics doesn't do what the industry proponents claim.  See my 
other writing on the topic:
<http://www.counterpane.com/insiderisks1.html>
<http://www.counterpane.com/crypto-gram-9808.html#biometrics>

There's some news on the quantum cryptography front.  I was not going to 
even bother mentioning this, but I have received enough press calls to 
indicate that most people don't understand the ramifications.  As a 
scientist, I find this interesting.  As a security professional, I know 
it's irrelevant.  Elsewhere I've described a reliance on cryptography as 
putting a tall spike in the ground and hoping the enemy runs right into 
it.  The real problems are not crypto-related: they're implementation 
errors, trust-model screw-ups, intentional misuse, misconfiguration, 
etc.  Quantum cryptography is an interesting development, but it's akin to 
arguing whether the spike is one mile tall or 1.5 miles tall.  (For anyone 
who's wondering what quantum cryptography is, there's a lucid explanation 
in the last chapter of Simon Singh's _The Code Book_.)  Much more useful is 
to start worrying about all the non-crypto-related vulnerabilities.
<http://www.aip.org/releases/2000/release03.html>

I've long considered the lack of vendor liability to be one of the primary 
reasons the Internet is insecure.  I also predicted a spate of lawsuits 
this year.  Lawyers were trained in computers to prepare for the Y2K 
litigations, and they're bored.  Here's a first inkling of what might 
come:  one lawyer is suing US West because his DSL connection left his 
files exposed.  As much as I don't like solving problems by litigation, he 
does have a point.
<http://cgi.zdnet.com/slink?29949:8469234>

Excellent Village Voice story on the DeCCS DVD copy protection case:
<http://www.villagevoice.com/issues/0018/howe.shtml>

President Clinton has signed a bill requiring law enforcement to document 
how frequently it intercepts encrypted conversations between suspected 
criminals.
<http://www.wired.com/news/politics/0,1283,36067,00.html>
Clinton's statement:
<http://www.politechbot.com/docs/clinton-crypto.050300.html>
Wiretap stats from 1999:
<http://www.uscourts.gov/wiretap99/contents.html>

Analyzing privacy policies:  Major Web sites have privacy policies, 
right?  Have you ever tried to read one of them?  USA Today tried to, and 
failed.
<http://www.usatoday.com/life/cyber/tech/cth818.htm>

A good introduction to IPSec:
<http://www.cisco.com/warp/public/759/ipj_3-1/ipj_3-1_ip.html>

Another essay on the open-source security debate:
<http://www.securityfocus.com/commentary/19>


** *** ***** ******* *********** *************

       The Doghouse: Cybercrime Treaty



The Council of Europe has released a draft of a proposed treaty on crime in 
cyberspace.  (The Council of Europe consists of over 40 signatory nations, 
including the U.S., Canada, Japan, Russia, and South Africa.)  While 
well-intentioned, it has a provision that could effectively cripple research.

The offending paragraph states:

 > Article 6 Illegal Devices
 >
 > Each Party shall adopt such legislative and other measures as
 > may be necessary to establish as criminal offences under its
 > domestic law when committed intentionally and without right:
 >
 >         a.the production, sale, procurement for use, import,
 > distribution or otherwise making available of:
 >
 >         1.a device, including a computer program, designed
 > or adapted [specifically] [primarily] [particularly] for the
 > purpose of committing any of the offences established in
 > accordance with Article 2

This would make it illegal to create, post, or download any piece of 
software that is "designed or adapted" to break into computer systems.

This is one of those "throwing the baby out with the bathwater" sorts of 
provisions.

Many legitimate computer-security tools -- vulnerability scanners, for 
example -- fall into this category.  So does most of the computer-security 
research that discovers and fixes existing vulnerabilities.  The effects of 
this treaty, if enforced, will only enable more insecure software.

I don't see how this law will affect the computer criminals.  They're 
already distributing attack tools, and most of them do so 
anonymously.  This will primarily affect legitimate computer-security research.

Treaty:
<http://conventions.coe.int/treaty/en/projets/cybercrime.htm>

News article:
<http://wired.com/news/politics/0,1283,36047,00.html>


** *** ***** ******* *********** *************

           More on Microsoft Kerberos



Microsoft has made its proprietary Kerberos extensions available, sort of.

You can download a document outlining the changes from the Microsoft Web 
site.  However, the document is delivered as a self-extracting executable 
archive.  But when you run the .exe, you are shown a license agreement that 
you must agree to to see the document.  Here's the relevant paragraph:

"b. The Specification is confidential information and a trade secret of 
Microsoft.  Therefore, you may not disclose the Specification to anyone 
else (except as specifically allowed below), and you must take reasonable 
security precautions, at least as great as the precautions you take to 
protect your own confidential information, to keep the Specification 
confidential.  If you are an entity, you may disclose the Specification to 
your full-time employees on a need to know basis, provided that you have 
executed appropriate written agreements with your employees sufficient to 
enable you to comply with the terms of this Agreement."

What we have here is a way to distribute the spec while making it illegal 
to build compatible implementations.  This completely defeats the IETF's 
interoperability goals, and helps Microsoft leverage their desktop monopoly 
into the server market.

Microsoft Web site:
<http://www.microsoft.com/technet/security/kerberos/default.asp>

News articles:
<http://slashdot.org/articles/00/05/02/158204.shtml>
<http://www.infoworld.com/articles/en/xml/00/04/28/000428enkerpub.xml>

It gets worse.  It seems that there was a discussion of the Microsoft 
Kerberos specification on Slashdot.  Some of this discussion violated the 
terms of the ridiculous license agreement above.  So Microsoft sent 
Slashdot an angry lawyer letter, claiming that the postings were in 
violation of the DMCA (the Digital Millemium Copyright Act, the one that 
prohibits reverse-engineering).  At this writing Slashdot has not removed 
the offending postings, but this could get ugly.  My hope is that this 
acutally goes to court, and that some of the more bizarre provisions of the 
DMCA (and UCITA) get thrown out.

The thread Microsoft objects to:
<http://slashdot.org/article.pl?sid=00/05/02/158204>

Microsoft's lawyer letter and SlashDot's initial reply:
<http://slashdot.org/article.pl?sid=00/05/11/0153247&mode=nested&threshold=0>

More SlashDot commentary:
<http://slashdot.org/features/00/05/13/2038233.shtml>

Mirrored copy of the Kerberos specfication (live link at the time of writing):
<http://members.xoom.com/MSKerberos/>

News stories:
<http://salon.com/tech/log/2000/05/11/slashdot_censor/index.html>
<http://news.cnet.com/news/0-1003-200-1857407.html?tag=st>
<http://www.washingtonpost.com/wp-dyn/articles/A52826-2000May11.html>
<http://slashdot.org/features/00/05/12/1421258.shtml>

An essay:
<http://www.securityfocus.com/news/33>


** *** ***** ******* *********** *************

            Trusted Client Software



Recently there has been a spate of news articles on client-side computer 
security topics.  Several companies claim to sell e-mail security solutions 
where the e-mail cannot be read after a certain date, effectively 
"deleting" it.  Other companies claim to sell rights-management software: 
audio and video files that can't be copied or redistributed, data that can 
be read but cannot be printed, software that can't be copied.  The common 
thread in all of these "solutions" is that they postulate a situation where 
the owner of a file can control what happens to that file after it is sent 
to someone else.

It's complete nonsense.

Controlling what the client can do with a piece of data assumes a trusted 
(from the point of view of the initial owner of the file) piece of software 
running on the client.  Such a thing does not exist, so these solutions 
don't work.

As an example, look at the on-line gaming community.  Many games allow for 
multi-player interaction over the Internet, and some games even have 
tournaments for cash prizes.  Hackers have written computer "bots" that 
assist play for some of these games, particularly Quake and NetTrek.  The 
idea is that the bots can react much quicker than a human, and that the 
player becomes much more effective with the assistance of these bots.  An 
arms race has ensued, as the game designers try to disable these bots and 
force fairer play, and the hackers make the bots cleverer.

These games are trying to rely on trusted client software, and the hacker 
community has managed to break every trick the game designers have thrown 
at them.  I am continuously amazed by the efforts hackers will go through 
to break the security.  The lessons are twofold: not only is there no 
reasonable way to trust a client-side program in real usage, but there's no 
possible way to ever achieve that level of protection.

Against all of these systems -- disappearing e-mail, rights management for 
music and videos, fair game playing -- there are two types of attackers: 
the average user and the skilled attacker.  Against the average user 
anything works; there's no need for complex security software.  Against the 
skilled attacker nothing works.  And even worse, most systems need to be 
secure against the smartest attacker.  If one person hacks Quake (or 
Intertrust or DisappearingInc), he can write a point-and-click software 
tool that anyone can use.  Suddenly a security system that is secure 
against almost everyone can now be compromised by everyone.

Building a trusted client in software, and trying to limit the abilities of 
a user, on a general purpose computer is doomed to failure.  For now, 
though, it provides a nice false sense of security.


** *** ***** ******* *********** *************

               ILOVEYOU Virus


What strikes me the most about this virus is how well it social engineers 
the user.  It comes from someone the user knows.  It has an enticing 
subject line.  In Microsoft Outlook the ".vbs" extension is supressed by 
default, so it looks like an innocuous ".txt" file.  Even with all the 
admonitions not to open attachments you're not expecting, the average user 
doesn't stand a chance against a virus like this.

Expect even worse in the future.  Systems running either Microsoft Office 
2000 or Internet Explorer 5.0 can be infected with these sorts of viruses 
even if the recipient doesn't open the attachment.  That's right; if the 
system is running Internet Explorer with the default settings, it is 
vulnerable.  The problem is
caused by a programming bug in an Internet Explorer ActiveX control.  Thank 
you, Microsoft.

Back to the ILOVEYOU virus.  Read James Gleick's excellent essay:
<http://slate.msn.com/Features/lovebug/lovebug.asp>

And Phil Agre's commentary is so perfect, I'm just going to reprint it 
here.  You can subscribe to his newsletter, "Red Rock Eater News Service," at:
<http://dlis.gseis.ucla.edu/people/pagre/rre.html>

Phil says:

I received about 60 copies of the latest Microsoft e-mail virus and its 
variants.  How many did you get?  Fortunately I manage my e-mail with 
Berkeley mailx and Emacs keyboard macros, so I wasn't at risk.  But if 
we're talking about billions of dollars in damage, which equates roughly to 
millions of lost work days, then I think that we and Microsoft need to have 
a little talk.

Reading the press reports, Microsoft's stance toward this situation has 
been disgraceful.  Most of their sound bites have been sophistry designed 
to disassociate the company from any responsibility for the problem.  One 
version goes like this quote from Scott Culp of Microsoft Public Relations, 
excuse me, I mean Microsoft Security Response Center:

      This is a general issue, not a Microsoft issue.  You can write a
      virus for any platform.  (New York Times 5/5/00)

Notice the public relations technology at work here: defocusing the issue 
so as to move attention away from the specific vulnerabilities of 
Microsoft's applications architecture and toward the fuzzy concept of "a 
virus".  Technologists will understand the problem here, but most normal 
people will not.  Mr. Culp also says this (CNET 5/5/00):

      This is by-design behavior, not a security vulnerability.

More odd language.  It's like saying, "This is a rock, not something that 
can fall to the ground".  It's confusing to even think about it.  Even 
though Microsoft had been specifically informed of the security 
vulnerability in its software, it had refused to fix it.  Microsoft even 
tried to blame its problem on Netscape, which *had* fixed it:

      <http://news.cnet.com/news/0-1005-200-1820959.html>

The next step is to blame the users.  The same Mr. Culp read on the radio 
the text of a warning that the users who spread the virus had supposedly 
ignored.  That warning concludes with a statement to the effect that you 
shouldn't execute attachments from sources that you do not trust.  He read 
that part kind of fast, as you might expect, given that the whole point of 
this virus is that people receive an attachment from a person who has 
included them in their address book.  This particular blame-shifting tactic 
is particularly disingenuous given that the virus spread rapidly through 
Microsoft itself, to the point that the company had to block all incoming 
e-mail (Wall Street Journal 5/5/00).

Similarly, CNET (5/4/00) quoted an unnamed "Microsoft representative" as 
saying that companies must educate employees "not to run a program from an 
origin you don't trust".  Notice the nicely ambiguous word "origin".  The 
virus arrives in your mailbox clearly labeled as having been sent by a 
particular individual with whom you probably have an established 
relationship.  It bears no other signs of its "origin" that an ordinary 
user will be able to parse, short of executing the attachment.

So what on earth is Microsoft doing allowing attachments to run code in a 
full-blown scripting language that can, among many other things, invisibly 
send e-mail?  Says the "Microsoft representative",

      We include scripting technologies because our customers ask us to
      put them there, and they allow the development of business-critical
      productivity applications that millions of our customers use.

There needs to be a moratorium on expressions such as "customers ask us 
to".  Does that mean all of the customers?  Or just some of them?  Notice 
the some/all ambiguity that is another core technology of public 
relations.  Do these "customers" really specifically ask for fully general 
scripts that attachments can execute, or do they only ask for certain 
features that can be implemented in many ways, some of which involve 
attachments that execute scripts?  Do the customers who supposedly ask for 
these crazy things understand the consequences of them?  Do they ask for 
them to be turned on by default, so that every customer in the world gets 
the downside of them so that a few customers can more conveniently get the 
upside?  And notice how the "Microsoft representative" defocuses the issue 
again, shifting from the specific issue of scripts that can be executed by 
attachments to the fuzzy concept of "scripting technologies", as if anybody 
were suggesting that scripting technologies, as such, in general, were to 
blame.

Microsoft shouldn't be broken up.  It should be shut down.


Agre has even more examples of Microsoft doublespeak at:
<http://commons.somewhere.com/rre/2000/RRE.notes.and.recommenda6.html>


** *** ***** ******* *********** *************

             Comments from Readers



From: David Wadsworth <dwadsw@etna.demon.co.uk>
Subject: Stolen Enigma Machine

Apparently the stolen machine was an Abwehr Enigma, as used by the 
German  Intelligence service during the war.  It does seem feasible that 
there are only three of these surviving in the world, they were taken 
better care of than the ordinary Enigmas, and the operators were more 
likely to destroy them to prevent capture.  It was of particular interest 
to cryptographers, since it had two innovations: Firstly the fourth 
(reflecting) rotor stepped instead of being static, and each wheel stepped 
the next wheel several times per rotation instead of only once.  The book 
"The Codebreakers" describes this machine in chapter 16, and suggests that 
BP would have had trouble breaking it if it wasn't for the fact that the 
Germans omitted the plug board which was used on the normal Enigmas.


From: David Jones <dej@inode.org>
Subject: UCITA, remote self-help and implications for firewalls

UCITA in theory permits vendors to remotely disable software over the 
Internet.  How, precisely, is this to be done?

All commercial enterprises that I know of that use commercial software have 
firewalls that prevent access to internal resources from outside.  Even at 
home, I have my own LAN and a firewall.

In order for a vendor to be able to remotely disable software through the 
Internet, the vendor would need to access the software's license server, 
through the customer's firewall.

This opens up a number of issues.  Vendors would have to document the 
protocols required to perform remote disable (e.g. what ports to use) so 
that customers could open up their firewalls.  Vendors would need to ensure 
that customers indeed permit access, perhaps by requiring network licenses 
to be refreshed periodically.  Different packages may have differing 
disable requirements.  In the case of software that uses a common licensing 
technique (e.g. Globetrotter's FlexLM), the remote disable protocols may 
conflict with one another.  (How many different license servers are running 
in your business?) Of course, vendors will likely also require that 
everyone do it the same way, since vendors won't want to keep track of 
which ports are used for each customer.  As an I.T. director, would you 
want to handle all of this?


** *** ***** ******* *********** *************

CRYPTO-GRAM is a free monthly newsletter providing summaries, analyses, 
insights, and commentaries on computer security and cryptography.

To subscribe, visit <http://www.counterpane.com/crypto-gram.html> or send a 
blank message to crypto-gram-subscribe@chaparraltree.com.  To unsubscribe, 
visit <http://www.counterpane.com/unsubform.html>.  Back issues are 
available on <http://www.counterpane.com>.

Please feel free to forward CRYPTO-GRAM to colleagues and friends who will 
find it valuable.  Permission is granted to reprint CRYPTO-GRAM, as long as 
it is reprinted in its entirety.

CRYPTO-GRAM is written by Bruce Schneier.  Schneier is founder and CTO of 
Counterpane Internet Security Inc., the author of "Applied Cryptography," 
and an inventor of the Blowfish, Twofish, and Yarrow algorithms.  He served 
on the board of the International Association for Cryptologic Research, 
EPIC, and VTW.  He is a frequent writer and lecturer on computer security 
and cryptography.

Counterpane Internet Security, Inc. is a venture-funded company bringing 
innovative managed security solutions to the enterprise.

<http://www.counterpane.com/>

Copyright (c) 2000 by Counterpane Internet Security, Inc.



[: hacktivism :]
[: for unsubscribe instructions or list info consult the list FAQ :]
[: http://hacktivism.tao.ca/ :]