CRYPTO-GRAM, June 15, 2000

[InfoSec News <isn () C4I ORG>]

Forwarded by: Bruce Schneier <schneier () counterpane com>

                  CRYPTO-GRAM

                 June 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:
      SOAP
      Crypto-Gram Reprints
      News
      Counterpane Internet Security News
      Java and Viruses
      The Doghouse: Infraworks
      The Data Encryption Standard (DES)
      Comments from Readers


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

                     SOAP



SOAP (Simple Object Access Protocol) is a proposed standard for
linking Internet applications running on different platforms, using
XML messages.  SOAP is designed to connect together programs running
on different machines, without regard to what OS/CPU is on each.
It's basically remote procedure calls (RPC) implemented via HTTP with
XML content.  Because no security is required in either HTTP, XML, or
SOAP, it's a pretty simple bet that different people will bungle any
embedded security in different ways, leading to different holes on
different implementations.  SOAP is going to open up a whole new
avenue for security vulnerabilities.

SOAP has been developed by a bunch of companies, but it's instructive
to read Microsoft's own words on security and SOAP:

"Currently, developers struggle to make their distributed applications
work across the Internet when firewalls get in the way.  Since most
firewalls block all but a few ports, such as the standard HTTP port
80, all of today's distributed object protocols like DCOM suffer
because they rely on dynamically assigned ports for remote method
invocations.  If you can persuade your system administrator to open a
range of ports through the firewall, you may be able to get around
this problem as long as the ports used by the distributed object
protocol are included.

"To make matters worse, clients of your distributed application that
lie behind another corporate firewall suffer the same problems.  If
they don't configure their firewall to open the same port, they won't
be able to use your application.  Making clients reconfigure their
firewalls to accommodate your application is just not practical.

"Since SOAP relies on HTTP as the transport mechanism, and most
firewalls allow HTTP to pass through, you'll have no problem invoking
SOAP endpoints from either side of a firewall.  Don't forget that SOAP
makes it possible for system administrators to configure firewalls to
selectively block out SOAP requests using SOAP-specific HTTP headers."

That's right.  Those pesky firewalls prevent applications from sending
commands to each other, so SOAP lets vendors hide those commands as
HTTP so the firewall won't notice.

Let's continue the DCOM example.  So what if DCOM runs over a
firewall?

DCOM is Microsoft's main protocol for inter-application communication.
It's not just used by programs that are intended to be servers; it's
used for all sorts of desktop communication and remote access.  The
result is that an average machine has dozens of programs using DCOM.
Mine shows 48, ranging from "Microsoft PowerPoint Presentation" to
"logagent" and including the catchily named
"{000C101C-0000-0000-C000-000000000046}"; you may be able to list
yours by bringing up a Command Prompt and typing "dcomcnfg".

Now, there are lots and lots of ways to secure DCOM applications, so
maybe all of those applications are happily responding only to
authenticated requests from the local machine.  On the other hand,
there are lots and lots of ways to make DCOM applications insecure, so
maybe one of them is just waiting for somebody to send it an entirely
unauthenticated request to overwrite selected files on my hard disk.

Firewalls have good reasons for blocking protocols like DCOM coming
from untrusted sources.  Protocols that sneak them through are not
what's wanted.

Information on SOAP:
<http://soap.weblogs.com/>

Microsoft's document (which includes the quoted paragraphs):
<http://msdn.microsoft.com/library/periodic/period00/soap.htm>


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

             Crypto-Gram Reprints



Those of you who have subscribed recently might have missed these
essays from back issues.

Timing attacks, power analysis, and other "side-channel" attacks
against smart cards:
<http://www.counterpane.com/crypto-gram-9806.html#side>

The internationalization of cryptography, policy:
<http://www.counterpane.com/crypto-gram-9906.html#policy>
and products:
<http://www.counterpane.com/crypto-gram-9906.html#products>

The new breeds of viruses, worms, and other malware:
<http://www.counterpane.com/crypto-gram-9906.html#viruses>


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

                     News



New kinds of network devices to attack:
<http://news.cnet.com/news/0-1003-200-1864025.html?tag=st.ne.ron.lthd.ni>
(Note the invocation of "128-bit encryption," as if that just solves
everything.)

The UK advertising authority upholds a complaint that an RSA flyer was
misleading when it implied that freeware encryption was somehow inadequate:
<http://www.asa.org.uk/adj/adj_4765.htm>

One project to reduce buffer overflow vulnerabilities:
<http://www.bell-labs.com/org/11356/libsafe.html>

Modern phone phreaking:
<http://www.wired.com/news/business/0,1367,36309,00.html>

What if smart people wrote computer viruses?:
<http://lcamtuf.na.export.pl/worm.txt>

Excellent speech by Dan Geer on risk management and security:
<http://www.stanford.edu/~hodges/doc/Geer-RiskManagement.txt>

Just because you configure Microsoft Windows 2000 to use triple-DES with
IPsec, doesn't mean you get it:
<http://www.wired.com/news/technology/0,1282,36336,00.html>
In some circumstances the software only uses single DES.  And to make
matters worse, it never bothers alerting the user.

The Canadian government intended to put all of its data on citizens in one
big database, including tax return information (which, by law, Revenue
Canada is forbidden to disclose to other arms of government).
<http://www.wired.com/news/politics/0,1283,36435,00.html>
<http://www.canoe.ca/CNEWSArchiveMay00/candigest_may16.html>
<http://www.canoe.ca/CNEWSArchiveMay00/candigest_may17.html>
But the plan was scrapped.
<http://www.hrdc-drhc.gc.ca/common/news/dept/00-39.shtml>
<http://www.wired.com/news/politics/0,1283,36649,00.html>

More on the dangers of relying on PKI:
<http://www.DGA.co.uk/customer/publicdo.nsf/public/WP-HERESY>

Microsoft's Office Assistant -- that annoying paper-clip helper in
Office -- has some nasty security vulnerabilities in Office 2000.  It
seems that an attacker can write scripts for the assistant that can do
all sorts of damaging things, and that these scripts can run
automatically when the user clicks on a Web page or opens an
HTML-enabled e-mail.  This is an amazing breach of security for
Microsoft.  Because they chose to mark all Office Assistant scripts as
"safe," these scripts can do anything they want.  This is exactly the
sort of vulnerability that virus writers exploit.  This isn't a
programming error; this is a deliberate design decision made at a very
high level.  Even more evidence that Microsoft doesn't take security
seriously.
<http://www.zdnet.com/zdnn/stories/news/0,4586,2570727,00.html> A
Microsoft bulletin that really downplays the importance:
<http://www.microsoft.com/technet/security/bulletin/ms00-034.asp> A
patch from Microsoft:
<http://officeupdate.microsoft.com/2000/downloadDetails/Uactlsec.htm>

Someone actually patented using a tattooed bar code to verify a person's
identity.  Isn't Revelation 13:16-18 prior art?
<http://patents.uspto.gov/cgi-bin/ifetch4?ENG+PATBIB-ALL+0+946309+0+7+25907+
OF+1+1+1+PN%2f5%2c878%2c155>

Ph.D. dissertation on the incidence of serious Internet attacks.  According
to this research, it happens less often than people claim:
<http://www.cert.org/research/JHThesis/Start.html>

Tired of all of these Microsoft Visual Basic viruses?  Turn off the
Scripting Host entirely:
<http://www.fsecure.com/virus-info/u-vbs/>

Real Networks demonstrates that they just don't learn:
<http://www.vortex.com/privacy/priv.09.15>

Smart electronics that knows its location.  Want to bet that no one has
thought about the security ramifications of this technology?
<http://www.telegraph.co.uk/et?ac=000111464113065&pg=/et/00/5/7/ntac07.html>

Not that I mind the U.S. government studying privacy, but in this case an
18-month study means 18 months of no action:
<http://www.cnn.com/2000/TECH/computing/05/22/new.privacy.study.idg/index.html>

According to a news report, the EU lifted all restrictions on
encryption restrictions, despite the protests of the United States.
<http://www.heise.de/tp/english/inhalt/te/8179/1.html> The truth
wasn't nearly as good.  At a meeting on 22 May, the European Ministers
of Foreign Affairs withdrew the proposal from their agenda at the last
minute.  No reason for this change of heart by European ministers was
given.  Officials from both France and the UK expressed reservations
about the measure, and officials have confirmed that the U.S.
pressured the EU to block the decision.  As far as I know, no official
statement has been made by anyone.
<http://www.wired.com/news/politics/0,1283,36623,00.html>

Good intro article on crypto from IEEE Spectrum:
<http://www.spectrum.ieee.org/pubs/spectrum/0400/enc.html>

XML and how to secure it:
<http://www.zdnet.co.uk/news/2000/20/ns-15500.html>

The FTC finally gives up on Internet privacy self-regulation:
<http://www.zdnet.com/zdnn/stories/news/0,4586,2574082,00.html>
The FTC report:
<http://www.ftc.gov/os/2000/05/index.htm#22>

Social engineering in the real world: using fake IDs to penetrate
government buildings.
<http://www.cnn.com/2000/US/05/25/security.breaches.01/index.html>
The best line is: "'I think any time you expose vulnerabilities it's a good
thing,' said Attorney General Janet Reno...."  This, of course, means that
she is in favor of full disclosure of network vulnerabilities.

Keystroke Surveillance Tool:  A small piece of hardware can covertly record
and store half a million keystrokes of information.  The device can be
hidden in a keyboard or a PS/2 plug, and requires no software to install.
<http://www.zdnet.co.uk/news/2000/12/ns-14347.html>

The myth of open source security:  An essay by the author of the open
source Mailman program explains why open source is not as secure as you
might think -- using security holes in his own code as an example.
<http://developer.earthweb.com/journal/techfocus/052600_security.html>
And Slashdot reactions to the essay:
<http://slashdot.org/articles/00/05/28/1838201.shtml>

The sorry state of the CIA and NSA:
<http://www.washingtonpost.com/wp-dyn/articles/A22957-2000May28.html>

NPR ran a story on the shortwave numbers stations.  Schneier was
interviewed for the story.
<http://www.npr.org/programs/lnfsound/stories/000526.stories.html>

EFF's testimony on the Digital Millennium Copyright Act.  Really good reading.
<http://cryptome.org/dmca-eff.htm>

E-mail virus stolen from a researcher's computer:
<http://www.herald.co.nz/storydisplay.cfm?storyID=138622&thesection=technolo
gy&thesubsection=general>

Pennsylvania makes it crime to spread a computer virus.  I don't know how
this affects Outlook viruses that spread on their own.
<http://www.cnn.com/2000/TECH/computing/06/01/virus.crack.down.idg/index.html>

SANS releases the top ten critical Internet security threats.
<http://www.sans.org/topten.htm>

Evidence from the CD Universe credit-card theft was tainted, so they can't
prosecute:
<http://www.msnbc.com/news/417406.asp?cp1=1>


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

       Counterpane Internet Security News



Counterpane's Managed Security Monitoring service has been running
smoothly for several months now.  We're monitoring customer networks
across the U.S., and are starting to look at expanding to Europe and
Asia.  If you're interested in learning how we can monitor your
network, contact us at (888)  710-8175 or sales () sj counterpane com.

Interview with Bruce Schneier in Information Security Magazine:
<http://www.infosecuritymag.com/jun2000/junqa.htm>

Fast Company magazine profiled Counterpane:
<http://www.fastcompany.com/online/35/ifaqs.html>

Giga Research issues an opinion of Counterpane's monitoring service:
<http://www.counterpane.com/giga.pdf>

Computer Security Incident Handling Conference (First), June 26-30,
Chicago: Bruce Schneier will be speaking on June 27 at 2:00 PM and giving
the keynote address on June 28 at 9:15 AM.
<http://www.first.org/conference/2000/>

PC Week/DCI Security Summit, June 27-29, Boston: Bruce Schneier is
co-chair, and will deliver the keynote address at 9:00 AM on June 29.
<http://www.dci.com/brochure/secbos/>

Black Hat Briefings, July 26-27, Las Vegas: Bruce Schneier will be speaking
in the morning of July 26th.
<http://www.blackhat.com>

The SecurityFocus Web site has an audio interview with Bruce Schneier:
<http://www.securityfocus.com/templates/media.html?id=25>


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

                Java and Viruses



At the JavaONE conference earlier this month, Scott McNealy made an
erroneous comment about Java.  Here's how CNet reported it:

> In his [JavaONE] keynote, [...] McNealy said that
> Java is immune to viruses such as Melissa and "I
> Love You" that have spread through Microsoft Outlook,
> a statement that security experts generally back up.

My guess is that security experts don't back that statement up,
because it's wrong.  McNealy is confusing an application (Microsoft
Outlook) with a programming language (Java).  And he is confusing
design flaws with implementation flaws.

The main problems with the security in Outlook is that it:
   a) defaults to effectively "no security" in many cases.
   b) hides essential risk-assessment information by default (e.g., file
extensions).
   c) is easily told to do things (scripted) by other programs.

All of these are design flaws.  That is, Microsoft Outlook was
designed by Microsoft to have these problems, They are not
implementation flaws:  errors made by the programmers during
development.  The fundamental problem is that the security
implications of the chosen design and feature-set were never examined
in any meaningful way.

None of the above design flaws is a preventable or secured contingency
covered by Java's "sandbox" model, nor its security policy mechanism,
nor any other aspect of Java's security model.  In fact, I could
easily write an e-mail application in Java that had design flaws
identical to Outlook Express.  Nothing in Java nor in its security
model can prevent or even hinder such a design.

What McNealy probably means to distinguish is the permissive nature of
Microsoft Outlook when it comes to executing attachments, and the more
secure nature of the Java sandbox.  Java contains specific provisions
to deal with potentially dangerous applets, and tries to execute them
in a protected mode that severely limits the effects they can have on
other applications and the host computer.  The Java design team has
spent a lot of time worrying about malicious executables and how they
can be prevented from running amok.

The CNet story:
<http://news.cnet.com/news/0-1003-200-2026364.html>


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

           The Doghouse: Infraworks



Yet another company is claiming to have "revolutionary, patented new
technology" to control the use of data on other people's computers.

I quote from their press release:  "It means that you can send digital
files to anyone without fear of unauthorized redistribution.  For
example, you could attach a Word or Excel document in an e-mail to
anyone anywhere, and prohibit them from forwarding it, printing it,
copying it or cutting and pasting any part of it.  You set the
permissions, and the data is deleted when the permissions are
exhausted.  You are in total control of your digital property."

"If hacking is attempted, the file self-destructs.  Just like Mission
Impossible.  No other technology can do this."

Someone remind these nice people that Mission Impossible is fiction.

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


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

       The Data Encryption Standard (DES)



The Data Encryption Standard (DES) has been the most popular
encryption algorithm of the past twenty-five years.  Originally
developed at IBM Corporation, it was chosen by the National Bureau of
Standards (NBS) as the government-standard encryption algorithm in
1976.  Since then, it has become a domestic and international
encryption standard, and has been used in thousands of applications.
Concerns about its short key length have dogged the algorithm since
the beginning, and in 1998 a brute-force machine capable of breaking
DES was built.  Today, modifications to DES, such as triple-DES,
ensure that it will remain secure for the foreseeable future.

In 1972, the NBS (since renamed the National Institute of Standards
and Technology, or NIST) initiated a program to protect computer and
communications data.  As part of that program, they wanted to
standardize on a single encryption algorithm.  After two public
requests for algorithms, they received a candidate from IBM based on
research being done in its Yorktown Heights and Kensington
Laboratories.  Among the people working on this candidate were Roy
Adler, Don Coppersmith, Horst Feistel, Edna Grossman, Alan Konheim,
Carl Meyer, Bill Notz, Lynn Smith, Walt Tuchman, and Bryant Tuckerman.

The algorithm, although complicated, was straightforward.  It used
only simple logical operations on small groups of bits and could be
implemented fairly efficiently in the mid-1970s hardware of the time.
DES is not very efficient in software, especially the 32-bit
architectures that are common today.

Its overall structure was something called a Feistel network, also
used in another IBM design called Lucifer.  DES is a block cipher,
meaning that it encrypts and decrypts data in blocks: 64-bit blocks.
DES is an iterated cipher, meaning that it contains 16 iterations
(called rounds) of a simpler cipher.  The algorithm's primary strength
came from something called an S-box, a non-linear table-lookup
operation by which groups of six bits would be replaced by groups of
four bits.  These table lookups were expressed as strings of
constants.

NBS lacked the ability to evaluate the algorithm, so they turned to
the National Security Agency (NSA) for help.  The NSA did two things:
they changed the constants in the S-boxes, and they reduced the key
size from its original 128 bits to 56 bits.

The revised algorithm, called DES, was published by NBS in March 1975.
There was considerable public outcry, both regarding the "invisible
hand" of the NSA -- the changes they made were not made public, and no
rationale was given for the S-box constants -- and the short key
length.  Originally the key length was supposed to be reduced to 64
bits, but when the standard was published, it turned out 8 of those
bits were "parity bits" used to confirm the integrity of the other 56
bits, and not part of the key at all.

Despite criticism, the DES was adopted as a Federal Information
Processing Standard in November 1976.  It was the first time an
NSA-evaluated encryption algorithm was ever made public, and was one
of the two most important developments that spurred the development of
public cryptography research (the other was the invention of
public-key cryptography).

After becoming a U.S. government standard, DES was adopted by other
standards bodies worldwide, including ANSI and ISO.  It became the
standard encryption algorithm in the banking industry, and was used in
many different applications around the world.  The terms of the
standard stipulated that it would be reviewed and recertified every
five years.  NBS recertified DES for the first time in 1987.  NIST
(NBS after the name change) recertified DES in 1993.  In 1997 they
initiated a program to replace DES: the Advanced Encryption Standard.

The NSA's involvement in the S-box values became clear in the early
1990s.  Two Israeli cryptographers, Eli Biham and Adi Shamir, invented
a powerful cryptanalytic attack called "differential cryptanalysis,"
and showed that the DES S-boxes were optimized to resist this
heretofore unknown attack.  It later became public that the IBM team
had developed this attack themselves while creating Lucifer and DES,
and that the NSA classified their research.

In the late 1990s, it became widely believed that the NSA was able to
break DES by trying every possible key, something called "brute force"
cryptanalysis.  This ability was graphically demonstrated by the
Electronic Frontier Foundation in July 1998, when John Gilmore built a
machine for $250,000 that could brute-force a DES key in a few days.

Years before this, more secure applications had already converted to
an encryption algorithm called triple-DES (also referred to as 3DES).
Triple-DES is the repeated application of three DES encryptions, using
two or three different keys.  This algorithm leverages all the
security of DES while effectively lengthening the key, and is in wide
use today to protect all kinds of personal, business, and financial
secrets.

DES is the most important algorithm ever made.  Because it had an NSA
pedigree, it was widely believed to be secure.  It is also the most
studied encryption algorithm ever invented, and many cryptographers
"went to school" on DES.  Almost all of the newer encryption
algorithms in use today can trace their roots back to DES, and papers
analyzing different aspects of DES are still being published today.


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

              Comments from Readers



From: "J. Christopher Williams" <jcw () datarave com>
Subject: Phil Agre on the Outlook Worms

Phil Agre wrote:
"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."

While many may find the author's above comments relevant to the issue
at hand, branding products as a method of securing their computer
strikes me as one-upmanship.  The fact is there are several ways to
get around such Virii & Worms, some of which do not require additional
products.  Admittedly it would be nice if these features were enabled
by default.  The one item that could be used to prevent viral
infection not mentioned by the above author is the human brain.  Odd,
considering it is the weapon of choice.

"... 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.
..."

The author may be a security or computer expert, but his grasp of
basic grammar is less than firm.  The more accurate grammar conversion
would be "This is an object thrown to the ground, not a free-falling
object."  The statement in and of itself merely assists in defining
what can be called "thrown" and what can be called "free-falling"
object.  It is not misleading unless the reader believes in the kind
of misinformation campaign the author suggests.  To me the author is
seemingly engaging in the same "blame shifting tactic" that he accuses
Microsoft of.

"...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). ..."

My company had fewer than 20 employees infected out of 1,600+
nation-wide employees, yet we closed down our Exchange Servers as
well.  For statistical comparison, every employee at the office where
I work is provided a computer, without exception.  We number 250+
employees with significant growth experienced during the last 90 days
and a forecasted doubling of employee base over the next 90.  Other
offices tend to be similarly equipped, although their growth varies.
The decision to do so was based more upon the potential to infect
non-company computers (i.e., repercussions of infecting a customer and
losing their good will) and the risk of receiving additional
infectious material during the ILOVEYOU window of opportunity.

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

I agree with the balance of the authors letter message, if not its
presentation.  With the exception of the above statement.  The
statement is very anti-individual (or in this case entity) which
equates to prejudiced.

I think the author's message can be summed up in "Microsoft should
protect a customer from his/her-self whether the customer understands
that protection or not."

I personally believe in security.  I believe in encryption keys and
signatures.  I believe in both the pure research & practical
application of encryption theory.  I also believe that it is not "Big
Brother's" place to decide what kind or how much encryption I use.
I'd much rather Microsoft provide a stable operating system with
features into which encryption can be incorporated.  I'd much rather
people like Counterpane provide encryption alternatives & research to
allow me to choose the best solution.

Either way, I don't believe that a "perfect" or "flawless" product
exists.  As Counterpane has said repeatedly:  Security is not a
destination, it is a journey.  Microsoft cannot plug every flaw or
security hole that exists in their operating system or their
applications; what they can do is be responsive to revealed security
flaws.  That is the standard we should hold them to.

To sum up my message:  I believe software development companies should
be held accountable for their negligence.  A feature demonstrably
flawed yet still implemented or not patched yet allowed to continue by
the development company should allow suit for damages by the damaged
party.  Phil's obvious (to me) anti-Microsoft bent leads me to
question his objectivity and therefore the purpose to which he wrote
his article.


From: Bob Smart <Bob.Smart () cmis CSIRO AU>
Subject: ILOVEYOU worm

I believe the message of the ILOVEYOU event has not been well
understood.  John Carder gets it right in the specific case in a
response to James Gleick's SLATE article:  "Windows Scripting Host
gives a Visual Basic script the authority of the user executing the
script, not the authority of the author of the script."

The problem of securely executing content that arrives across the
network is not restricted to Windows.  Mobile code is a fact of life,
whether it be software downloads or Java applets.  The Unix community
have to pay attention to this issue because you can be sure Microsoft
now will.

When our receptionist sent around a Christmas greeting executable
which a friend had sent to her, I naturally didn't run it.  However if
software is properly designed then it should be possible for people to
send such things to their friends.  It should be possible to run them
with no danger of harm: just like a Java applet in a secure JVM.


From: phred () teleport com
Subject: RTM vs. the "Love Bug"

Microsoft claims in its response to Jim Gleick's essay at Slate that the
"Love Bug" situation is somehow akin to the RTM worm.

Errant nonsense.

It's quite simple: RTM devised a stack-smasher and dictionary password
guesser with a clumsy forwarding mechanism and a rickety little
back-propagation communications channel.  No user intervention was
necessary.

The RTM worm was based on program bugs.  The "Love Bug" was based on
Microsoft program *features*.  It makes all the difference.


From: Jeff <jeff () antistatic com>
Subject: Social Engineering and the ILOVEYOU worm

The ILOVEYOU worm was social engineering at a kindergarten level.
Microsoft was lucky that it got handed a "slow pitch".  It could have
been MUCH worse.

If I were the malicious coder I would have added a critical step.
After getting the address book entry, the script should have checked
for the last message sent from that user and used THAT subject line.

1) Alice e-mails Bob with subject line "Picnic on Saturday?"

2) Carl e-mails Bob with the virus.

3) Virus sends copy of itself from Bob to Alice with subject line "Re:
Picnic on Saturday?"

The damage would have been much worse, and have been harder to filter
at the server level.  Add in a level of code morphing, and this could
have completely shut down whole e-mail systems.


From: Peter Houppermans <Peter.Houppermans () pa-consulting com>
Subject: Buffer Overflows

I'm not sure it's just a lack of interest in good quality, it strikes
me that some software houses have decided to ACCEPT that 'kind of OK'
is good enough for sale.  The article below makes some interesting
observations that I can actually agree with, and might point at a
slightly deeper cause:  good design fundamentals.  Buffer overflows
strike me as the result of not properly managed development processes
-- and some would argue the consequence of using C ('providing enough
rope to hang yourself' or, in my opinion, with flexibility and power
comes responsibility).

<http://www2.linuxjournal.com/articles/currents/019.html>

On a more amusing note, MS has found itself exposed to the law, as in
France (and, as far as I can tell, in Europe as a whole) the exclusion
of warranty is not legal -- i.e., null and void.  So, some apparently
enterprising users are taking MS to court of the wonderful virus whose
name we can't mention because string filters will bounce the mail ;-),
claiming negligence as they should have covered this exposure since
the Melissa virus.


From: Joe Harrison <joe-harrison () MailAndNews com>
Subject: Vendor liability for bad software

I am puzzled by your frequent claims that software manufacturers can
uniquely get away with releasing products that are of such poor
quality that they would be considered unsaleably defective in other
contexts.

Perhaps this is the case in the USA but I would have thought that many
(most?) other countries treat software just like any other item in
disputes about fitness for purpose.  Certainly here in the UK vendors
have been successfully sued and precedent is set, your stuff legally
has to work right for whatever it's supposed to do!

Have a look at:
<http://elj.warwick.ac.uk/jilt/cases/97_3stal/stalban.htm>


From: Ray Jones <rjones () pobox com>
Subject: Trusted Clients and Computer Games

You paint a pretty dreary picture of the gaming communities.  Quake
has been having serious problems of late, but Netrek dealt with
trusted clients back in 1992 (they had a rudimentary system in place
before that), and seems to have avoided serious problems since then.

The Netrek community seems to have adapted to Borgs [computer programs
that assist play] via two methods:

1- binary blessing with a nontrivial scheme
2- providing some servers that welcome borgs

The blessing scheme is RSA-based, with the client's private key
obscured in the binary.  This allows the open distribution of the
blessed client key list, so anyone can run a server without having to
be on some trusted list of server gods.  Having borg-friendly servers
provides an approved forum for borg authors to show off their hacking
skills.

The details of the verification aren't that important.  What's
interesting is the attacks that people have used to get around them.
In particular, of the two hacks I've heard of, neither relied on
extracting the key from the binary.  The first used a kernel
modification to allow a client to reopen a socket after the blessed
client had authenticated itself.  The second hack was on the key
generation code (poor random number generation, mea culpa).

It's certainly possible to extract the key, and then embed it in a
borg, but the payoff is low.  Someone is likely to notice and revoke
the key, and borg authors are already able to use their clients in
arenas where they can get some actual competition (borg vs borg).

Admittedly, Netrek has less mindshare than Quake, and is also more
borgable (being more tactical and less strategic than Netrek, IMO).
The lack of attacks might be because fewer people care.  However, the
combination of the two elements above (stick, carrot) seems to have
worked pretty well.  As you write elsewhere in this month's
Crypto-Gram, security is about risk reduction, not threat avoidance.


From: Ian Mason <ian () ian co uk>
Subject: Re: More on Microsoft Kerberos

If, as I did, you download the Microsoft Kerberos self-extracting .exe
but use WinZip to extract it you don't get to be forced to agree to
their so-called contract.  That leaves me free to operate within
normal copyright laws with my copy of it.  Specifically that means
that I can use the contents without any specious trade secret stuff.

It's fairly clear that Microsoft are operating in a fashion that is
anti-competitive.  They claim adherence to a public Kerberos
'standard' but then 'extend' it in an incompatible fashion.  Then,
with a dominant position in the desktop marketplace, make it difficult
to make a compatible server product by restricting access to use of
the details of the extensions.  Perhaps it's time for the IETF et al
to get heavy with them.  Perhaps an action for 'passing-off' of the
Kerberos name.

Here in the EU we have statutes that make it illegal to prevent
reverse engineering for compatibility purposes.  Unfortunately we
don't have a law that prevents a dominant player with a war chest for
feeding lawyers from tying a small player up in court, but then where
does?


From: Graystreak <wex () media mit edu>
Subject: Remotely Disabling Software

Vendors will not have to tunnel through firewalls to remotely disable
software.  Today most, if not all, softwares auto-update themselves.
Look at Norton Anti-Virus' "LiveUpdate" feature for one prominent
method.  Other softwares prompt you to go to a Web site and download
an "update."

Even without advance planning, such auto-updates can be used to
selectively disable users.  This is precisely how Napster effected the
ban on the 300,000+ users identified by Metallica.  If you connected
to Napster with their version 2.5 client you were told to wait while
the 2.6 version downloaded.  When 2.6 was run, suddenly you were
blocked, if you were on the banned list.

Clearly this kind of event was not in Napster's original plans, yet
they were able to implement it smoothly.  I expect Norton and
Microsoft and other software makers to be equally smooth about
programming in user-specific expirations.


From: Ian Mason <ian () ian co uk>
Subject: Cybercrime Treaty

The current wording does not prohibit research.  To fall foul of the
proposed treaty one would have to have an intent to commit an offence
["designed or adapted for the *purpose* of committing any offence"].
If one's purpose was to research vulnerabilities to prevent offenses
then one's purpose is clearly not to commit the offenses.  If you
don't believe me, ask any good lawyer about the concept of 'mens rea'
[literally "criminal mind", usually read as 'criminal intent'] in the
context of the words used.  It doesn't propose to create an absolute
offense -- one where only an 'actus reas', criminal action, regardless
of intention is necessary to prove guilt.  It is legal for me to make,
own and use a crowbar.  It is illegal for me to own one with the
intent to commit burglaries with it.  The treaty addresses only the
latter type of case.

Sorry, but for once, this is a case of the technologists not
understanding the lawyers instead of the other way around as is more
common.


From: Johan Ovlinger <johan () ccs neu edu>
Subject: Lawyer Suing USWest for Insecure DSL Connection

Whilst I agree on principle about vendor liability, this is more a
case of he got what he ordered, but didn't order what he wanted.
Pacific Bell connected his computer to the Internet constantly.
That's what he ordered and that's what he got.  That he failed to turn
off file sharing is his fault.  If anyone is to blame, it would be
Microsoft for making it so deplorably easy to shoot yourself in the
foot like this (not that Red Hat ships with significantly saner
defaults, but they at least make you enter a root password as part of
the install).

I really don't see that Pacific Bell have anything to do with his
file-sharing, unless they turned it on during installation.

I'd like to see this suit dismissed or settled out of court so as not
to set a bad precedent ('cause I hope he'll lose).  Then I'd like to
see some take some of the true offenders to task for the horrible
state of their "security".  Unfortunately (as I'd like to come across
as not to much of an MS basher), the current political climate makes
Microsoft the only viable target.  If they get split up or
significantly slapped, their EULAs will be seen as not worth the paper
they're printed on, thus opening them up to these sorts of class
action lawsuits.

Even if it would never succeed, it would be a grand sight to have a
Fortune 500 class action suit against them for the 10-odd gigabucks
that went lost due to the latest Internet worm, wouldn't it?


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

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.

ISN is sponsored by SecurityFocus.com
---
To unsubscribe email LISTSERV () SecurityFocus com with a message body of
"SIGNOFF ISN".