CRYPTO-GRAM, August 15, 2000

[InfoSec News <isn () C4I ORG>]

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

                  CRYPTO-GRAM

                August 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:
      Secrets and Lies: Digital Security in a Networked World
      Microsoft Vulnerabilities, Publicity, and Virus-Based Fixes
      News
      Counterpane Internet Security News
      Crypto-Gram Reprints
      European "Crime in Cyberspace" Convention
      The Doghouse:  Authentica
      Bluetooth
      Comments from Readers


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

   Secrets and Lies: Digital Security in a Networked World



I've written a new book.

I started writing this book in 1997; it was originally due to the
publisher by April 1998.  I eventually delivered it in April 2000, two
years late.  I have never before missed a publication deadline: books,
articles, or essays.  I pride myself on timeliness: A piece of writing
is finished when it's due, not when it's done.

This book was different.  I got two-thirds of the way through the book
without giving the reader any hope at all.  And it was about then I
realized that I didn't have the hope to give.  I had reached the
limitations of what I thought security technology could do.  I had to
hide the manuscript away for over a year; it was too depressing to
work on.

I came to security from cryptography, and framed the problem with
classical cryptography thinking.  Most writings about security come
from this perspective, and it can be summed up pretty easily: Security
threats are to be avoided using preventive countermeasures.

For decades we have used this approach to computer security.  We draw
boxes around the different players and lines between them.  We define
different attackers -- eavesdroppers, impersonators, thieves -- and
their capabilities.  We use preventive countermeasures like encryption
and access control to avoid different threats.  If we can avoid the
threats, we've won. If we can't, we've lost.

Imagine my surprise when I learned that the world doesn't work this
way.

I had my epiphany in April 1999: that security was about risk
management, that detection and response were just as important as
prevention, and that reducing the "window of exposure" for an
enterprise is security's real purpose.  I was finally able to finish
the book: offer solutions to the problems I posed, a way out of the
darkness, hope for the future of computer security.

"Secrets and Lies" discusses computer security in this context, in
words that a business audience will understand.  It explains, in my
typical style, how different security technologies work and how they
fail.  It discusses the process of security: what the threats are, who
the attackers are, and how to live in their world.

It'll change the way you think about computer security.  I'm very proud of it.

Information about the book:
<http://www.counterpane.com/sandl.html>

Order the book (at a 20% discount) from Amazon:
<http://www.amazon.com/exec/obidos/ASIN/0471253111/counterpane/>

If you use that URL to order the book from Amazon, a portion of the
purchase price will go to EPIC.


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

   Microsoft Vulnerabilities, Publicity, and Virus-Based Fixes



The latest tale of security gaps in Microsoft Corp.'s software is a
complicated story, and there are a lot of lessons to take away -- so
let's take it chronologically.

On June 27th, Georgi Gunniski discovered a new vulnerability in
Internet Explorer (4.0 or higher) and Microsoft Access (97 or 2000),
running on Windows (95, 98, NT 4.0, 2000).  An attacker can compromise
a user's system by getting the user to read an HTML e-mail message
(not an attachment) or visit a Web site.

This is a serious problem, and has the potential to result in new and
virulent malware.  But it requires Microsoft Access to be installed on
the victim's computer, which, while common, is by no means universal.
A virus that exploits this vulnerability will not spread as widely as,
say, Melissa.  In any case, Microsoft published a fix on July 14th,
and I urge everyone to install it.

On July 17th, SANS promulgated an e-mail warning people of the "most
dangerous flaw found in Windows workstations."  I can't really figure
this e-mail out; it seems to be primarily a grab for press coverage.
Some of it is suspiciously vague: "We developed this exploit further
and realized that this is one of the most serious exploits of Windows
workstations in the last several years"  "Developed"?  How?  No one
says.  Some of it brags:  "Microsoft asked us not to release the
details until they had a fix."  "Release the details"?  But the
original Bugtraq posting was pretty explanatory, and SANS has not
released anything new.

Still, the SANS e-mail received a lot more publicity than the Bugtraq
announcement or the Microsoft patch, so it's hard to complain too
much.

But the SANS announcement had a much more disturbing section:  "It may
be possible to fix this vulnerability automatically, via an e-mail
without asking every user to take action.  The concept is similar to
using a slightly modified version of a virus to provide immunity
against infection.  SANS is offering a $500 prize (and a few minutes
of fame) to the first person who sends us a practical automated
solution that companies can use, quickly, easily, and (relatively)
painlessly to protect all vulnerable systems."  (This paragraph is no
longer on the Web site, which claims that "winning entries have been
received.")

This is a really, really dumb idea, and we should put a stop to this
kind of thinking immediately.  Every once in a while someone comes up
with the idea of using viruses for good.  Writing a virus that
exploits a particular security vulnerability in order to close that
vulnerability sounds particularly poetic.

Here's why it's such a bad idea.  First, there's no audit trail of the
patch.  No system administrator wants to say: "Well, I did try to
infect our systems with a virus to fix the problem, but I don't know
if it worked in every case."

Second, there's no way to test that the virus will work properly on
the Internet.  Would it clog up mail servers and shut down networks?
Would it properly self-destruct when all mail clients were patched?
How would it deal with multiple copies of itself?

And third, it would be easy to get wrong and hard to recover from.
Experimentation, most of it involuntary, proves that viruses are very
hard to debug successfully.  Some viruses were written to propagate
harmlessly, but did damage because of bugs in their code.
Intentional experimentation proves that in your average office
environment, the code that successfully patches one machine won't work
on another, sometimes with fatal results.  Combining the two is
fraught with danger.  Every system administrator who's ever automated
software distribution has had the "I just automatically, with the
press of a button, destroyed the software on hundreds of machines at
once!" experience.  And that's with systems that you can *stop*;
self-propagating systems don't even let you shut them down when you
find the problem.

In any case, the SANS announcement was made even more confusing by the
announcement of another Microsoft vulnerability at the same time...one
that I think is even more serious than the one SANS publicized.  (The
vulnerability was first discovered on July 2nd, but was independently
discovered and published on Bugtraq on July 18th.)

A buffer overflow in Microsoft Outlook or Outlook Express allows an
attacker to execute arbitrary code on a victim's machine just by
sending him an e-mail.  In Outlook Express, the victim doesn't even
have to open the e-mail, or preview it.  All he has to do is download
it.  In Outlook, he has to read it.

That's the bad news.  The good news is that it only is a vulnerability
for users who have POP or IMAP installed; those using Outlook's
default corporate configuration are not vulnerable.  (Home users who
link to commercial ISPs are much more likely to be vulnerable.)  So
again, a virus that exploits this vulnerability would be dangerous and
unpleasant, but would not spread unchecked.

Microsoft has a fix.  Originally (on July 18th) it required you to
upgrade your version of Outlook or Outlook Express, but two days later
Microsoft did the right thing and issued a patch.  (In typical
Microsoft fashion, it isn't a patch for all versions, although they
claim that at the link site.  If you're running Outlook Express 4.0,
your only option is to install the upgrade; the patch for the 4.0
version is "coming soon.")  SANS issued another e-mail on July 21st,
with more dire warnings: "Please fix this before you go home today.
And if you have gone home, go back to the office and fix it."  In my
opinion, this warning blew the threat completely out of proportion,
and was irresponsible to send.  SANS made it sound like a virus attack
already in progress, not a new vulnerability that someday might be
exploited.  And right on the heels of the previous warning, it got
lost in the noise.  When I received the second SANS e-mail, I thought
it was another reminder for the first vulnerability.  I'll bet that
many users were similarly confused, and ignored it as well.

There are several lessons here.

1.  Computer programs have two sorts of vulnerabilities, nicely
illustrated by these two attacks.  First, they have vulnerabilities
connected to the basic design of the operating system they run on and
the way it chooses to interlink programs; the Access attack
demonstrates this.  Second, they have vulnerabilities based on coding
mistakes; the buffer overflow problem is an example.

2.  It's not enough to release a patch.  The press often gets this
wrong.  They think the sequence is: vulnerability publicized, patch
released, security restored.  In reality, it doesn't work that way.
You don't regain security until you install the patch.  Even though
both of these vulnerabilities have been patched, I predict attack
tools that use them.  Many users just won't bother installing these
patches.  For publicizing the two vulnerabilities, SANS is to be
commended.

3.  Sensationalizing vulnerabilities will backfire.  Both of these
vulnerabilities are serious, but neither is monumental.  Calling
something "the most dangerous flaw" leads people to trivialize other
flaws.  I worry about the public being completely unable to determine
what is important.  We've seen viruses that fizzle, and others that
run rampant.  We've seen vulnerabilities that look serious but don't
amount to anything, and ones that are trivial and exploited again and
again.  SANS needs to be a voice of reason, not of hyperbole.

4.  Writing a virus to exploit a vulnerability is a bad idea, even if
the goal of that virus is to close that vulnerability.  Viruses, by
their very nature, spread in a chaotic and unchecked manner; good
system administration is anything but.

5.  There are still lots of serious vulnerabilities in Microsoft
products, and in the interactions between products, waiting to be
discovered.

The Access/IE vulnerability:
<http://www.securityfocus.com/bid/1398>
<http://www.computerworld.com/cwi/story/0,1199,NAV47_STO47273,00.html>

The SANS announcement:
<http://www.sans.org/newlook/resources/win_flaw.htm>

Microsoft's "workaround":
<http://www.microsoft.com/technet/security/bulletin/MS00-049.asp>

The Outlook vulnerability:
<http://www.securityfocus.com/bid/1481>

Reports on the vulnerability:
<http://www.securityfocus.com/news/62>
<http://www.computerworld.com/cwi/story/0,1199,NAV47_STO47323,00.html>

Microsoft's fix:
<http://www.microsoft.com/windows/ie/download/critical/patch9.htm>
<http://www.microsoft.com/technet/security/bulletin/ms00-043.asp>

This article originally appeared in:
<http://www.zdnet.com/zdnn/stories/comment/0,5859,2609398,00.html>


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

                      News



Java security: trusted security providers.
<http://metalab.unc.edu/javafaq/reports/JCE_1.2.1.html>

I had nothing to do with this, but thought it was funny:
<http://segfault.org/story.phtml?id=396f3e5c-0958dfa0>

Quantum cryptography and gravity waves:
<http://www.newscientist.com/news/news_224738.html>

Snake-oil alert!  Even TISC gets taken once in a while.
<http://tisc.corecom.com/newsletters/213.html>

Building the perfect virus.  An interesting and disturbing article:
<http://www.hackernews.com/bufferoverflow/99/nitmar/nitmar1.html>

The U.S. announces new crypto regulations:
<http://www.wired.com/news/politics/0,1283,37617,00.html>
White House statements:
<http://cryptome.org/us-crypto-up.htm>

Kevin Mitnick teaches social engineering:
<http://www.zdnet.com/zdnn/stories/news/0,4586,2604480,00.html>

Password Safe:
<http://www.zdnet.com/sp/stories/column/0,4712,2586895,00.html>

If you think cookies are bad, meet Web bugs:
<http://www.ntsecurity.net/Articles/Index.cfm?ArticleID=9543>

Meanwhile, Microsoft adds cookie privacy features to Internet Explorer:
<http://www.wired.com/news/business/0,1367,37703,00.html>
They claim to be the first browser to do so, but Netscape has had these
features for a while:
<http://www.wired.com/news/business/0,1367,37723,00.html>

A URL scam.  A Web site in Rumania, paypai.com, was masquerading as
paypal.com.  The scam was to send PayPal users e-mails asking them to
log in, with the fake URL in the e-mail message.  The user clicked on
the e-mail link and got the fake page, which looked like the real
page.  Then the user entered his username and password, which the fake
site stole.

<http://www.zdnet.com/zdnn/stories/news/0,4586,2606152,00.html?chkpt=zdhpnew
s01> <http://www.msnbc.com/news/435937.asp> Then, days after this
story broke, people start getting e-mails asking them to click on
<http://www.paypal.x.com> to see if they'd won a sweepstakes.  X.com
recently purchased Confinity, the creators of PayPal...but who is
going to know that?  I thought the X.com e-mail was another scam, and
I'll bet others did, too.  This is an excellent illustration of the
problems of lousy authentication on the Internet.

Gregory Benford on the future of privacy:
<http://www.wired.com/news/technology/0,1282,37610,00.html>

I assume you've all read about the FBI's Carnivore Internet wiretapping
device.  Here are some essays you may have missed:
<http://www.sfgate.com/cgi-bin/article.cgi?file=/chronicle/archive/2000/07/2
1/ED64284.DTL>
<http://www.crypto.com/papers/opentap.html>

Review of personal firewalls:
<http://securityportal.com/cover/coverstory20000717.html>

A good editorial on the problems with the U.S. electronic signature law:
<http://www.nwfusion.com/columnists/2000/0724works.html>

Good article on intrusion-detection systems and the problems of false
positives:
<http://www.zdnet.com/eweek/stories/general/0,11011,2606343,00.html>

Cybercrime and law enforcement: an academic legal paper.  Interesting reading.
PDF:  <http://www.sinrodlaw.com/CyberCrime.pdf>
MS Word format:  <http://www.sinrodlaw.com/cybercrime.doc>

Editorial on why computer security is "different" from the rest of IT:
<http://www.zdnet.com/enterprise/stories/main/0,10228,2607345,00.html>

"Tangled Web: Tales of Digital Crime from the Shadows of Cyberspace":  an
excellent book on cybercrime by Richard Power:
<http://www.amazon.com/exec/obidos/ASIN/078972443X/counterpane/>

William Friedman filed a patent application for an Enigma-like encryption
device in 1933.  The Patent Office awarded the patent this month.
<http://www.patents.ibm.com/details?&pn=US06097812__&s_all=1>
It looks like a patent for the M-229, or maybe the M-134a.  It's hard to tell.

Draconian cyber-surveillance in the UK:
<http://www.mercurycenter.com/svtech/news/indepth/docs/dg071100.htm>

Good article on the liability of programmers who write malware, from Salon:
<http://salon.com/tech/feature/2000/08/07/yoink_napster/index.html>

Is the Web in for more attacks?
<http://www.zdnet.com/zdnn/stories/news/0,4586,2612050,00.html>

Security vulnerability in Adobe Acrobat.  An attacker could create a
pdf file that, when viewed, exploits a buffer overflow and runs
arbitrary code on the victim's machine.  Here's the patch:
<http://www.adobe.com/misc/pdfsecurity.html>
Interesting note on the page:  "There have been reports of fraudulent
security patches being distributed through e-mail.  Adobe will
distribute patches only through the Adobe Web site and not by e-mail."
No word, though, on how we are supposed to authenticate the Web site.

The debate continues on script kiddies:
<http://www.nwfusion.com/news/2000/0727holes.html>

Excellent article on non-repudiation:
<http://firstmonday.org/issues/issue5_8/mccullagh/index.html>


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

       Counterpane Internet Security News



Forbes profiled Counterpane, Bruce Schneier, and his new book:
<http://www.forbes.com/tool/html/00/jul/0731/feat.htm>

The Applied Cryptography Source Code Disk Set can now be exported to
any country except these seven embargoed nations: Cuba, Iran, Iraq,
Libya, North Korea, Sudan, and Syria.  For details, visit:
<http://www.counterpane.com/scode.html>


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

              Crypto-Gram Reprints



A Hardware DES Cracker:
<http://www.counterpane.com/crypto-gram-9808.html#descracker>

Biometrics: Truths and Fictions:
<http://www.counterpane.com/crypto-gram-9808.html#biometrics>

Back Orifice 2000:
<http://www.counterpane.com/crypto-gram-9908.html#BackOrifice2000>

Web-Based Encrypted E-Mail:
<http://www.counterpane.com/crypto-gram-9908.html#Web-BasedEncryptedE-Mail>


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

    European "Crime in Cyberspace" Convention



The Council of Europe recently released a draft of a document called
the "Draft Convention on Cybercrime." This document is meant as an
international treaty governing "cybercrime," and attempts to
standardize laws to make prosecuting hackers easier (some countries
have no laws specifically governing computer attacks).

It's a well-intentioned effort, but one provision has the potential to
seriously harm security research.  It's the provision that makes
attack tools illegal.

I've talked about this already with respect to similar American laws.
A long list of security professionals sent a letter regarding this
issue:

"We are concerned that some portions of the proposed treaty may
inadvertently result in criminalizing techniques and software commonly
used to make computer systems resistant to attack.  Signatory states
passing legislation to implement the treaty may endanger the security
of their computer systems, because computer users in those countries
will not be able to adequately protect their computer systems and the
education of information protection specialists will be hindered.

"Critical to the protection of computer systems and infrastructure is
the ability to

        Test software for weaknesses
        Verify the presence of defects in computer systems
        Exchange vulnerability information

"System administrators, researchers, consultants, and companies all
routinely develop, use, and share software designed to exercise known
and suspected vulnerabilities.  Academic institutions use these tools
to educate students and in research to develop improved defenses.
Our combined experience suggests that it is impossible to reliably
distinguish software used in computer crime from that used for these
legitimate purposes.  In fact, they are often identical.

"Currently, the draft treaty as written may be misinterpreted
regarding the use, distribution, and possession of software that could
be used to violate the security of computer systems.  We agree that
damaging or breaking into computer systems is wrong and we
unequivocally support laws against such inappropriate behavior.  We
affirm that a goal of the treaty and resulting legislation should be
to permit the development and application of good security measures.
However, legislation that criminalizes security software development,
distribution, and use is counter to that goal, as it would adversely
impact security practitioners, researchers, and educators."

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

Letter from dozens of security professionals criticizing the report:
<http://www.cerias.purdue.edu/homes/spaf/coe/TREATY_LETTER.html>

An essay questioning the report:
<http://securityportal.com/topnews/cybercrime20000719.html>


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

            The Doghouse:  Authentica



This is just another company that believes it can secure digital
content on another user's computer.  Of course it's snake oil, and
normally I wouldn't bother even listing them.  But they 1) use my
name, and 2) profoundly don't get it.

Question 11 of their FAQ reads:  "How secure is information I've
protected with PageVault?  According to Bruce Schneier, an encryption
expert, it would take one trillion dollars worth of computers a
trillion years to break 128-bit encryption -- the kind used in
PageVault.  And, once they had accomplished that, they would only have
a key for a single page of one document.  Now they'd need to do it all
over again for each successive page of every document."

What does breaking the encryption have to do with breaking the system?
Haven't these people learned anything from the DeCSS story?

The quote is from:
<http://www.authentica.com/products/faq.html#pagevault>

The Web site:
<http://www.authentica.com>

Why this kind of thing won't work, ever:
<http://www.counterpane.com/crypto-gram-0005.html#TrustedClientSoftware>


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

                    Bluetooth



Sometime in the 1950s, various governments realized that you could
eavesdrop on data-processing information from over a hundred feet
away, through walls, with a radio receiver.  In the U.S., this was
called TEMPEST, and preventing TEMPEST emissions in radios, encryption
gear, computers, etc., was a massive military program.  Civilian
computers are not TEMPEST shielded, and every once in a while you see
a demonstration where someone eavesdrops on a CRT from 50 feet away.

Soon it will get easier.

Bluetooth is a short-range radio communcations protocol that lets
pieces of computer hardware communicate with each other.  It's an
eavesdropper's dream.  Eavesdrop from up to 300 feet away with normal
equipment, and probably a lot further if you try.  Eavesdrop on the
CRT and a lot more.  Listen as a computer communicates with a scanner,
printer, or wireless LAN.  Listen as a keyboard communicates with a
computer.  (Whose password do you want to capture today?)  Is anyone
developing a Bluetooth-enabled smart card reader?

What amazes me is the dearth of information about the security of this
protocol.  I'm sure someone has thought about it, a team designed some
security into Bluetooth, and that those designers believe it to be
secure.  But has anyone reputable examined the protocol?  Is the
implementation known to be correct?  Are there any programming errors?
If Bluetooth is secure, it will be the first time ever that a major
protocol has been released without any security flaws.  I'm not
optimistic.

And what about privacy?  Bluetooth devices regularly broadcast a
unique ID.  Can that be used to track someone's movements?

The stampede towards Bluetooth continues unawares.  Expect all sorts
of vulnerabilities, patches, workarounds, spin control, and the like.
And treat Bluetooth as a broadcast protocol, because that's what it
is.

Bluetooth:
<http://www.bluetooth.com>

A list of Bluetooth articles, none of them about security:
<http://www.zdnet.co.uk/news/specials/1999/04/bluetooth/>

One mention of security:
<http://www.zdnet.co.uk/news/2000/24/ns-16164.html>

An essay about the Bluetooth hype:
<http://www.idg.net/ic_199451_797_9-10000.html>

Recent article on TEMPEST:
<http://www.zdnet.com/zdnn/stories/news/0,4586,2612547,00.html>


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

             Comments from Readers



From: "Carl Ellison" <cme () acm org>
Subject: Security of Social Security Numbers

The SSN story <http://news.cnet.com/news/0-1005-200-340248.html>
misses the point.  The fault isn't in release of SSNs.  That's still a
problem because it facilitates data aggregation, but the identity
theft problem is the stupidity of companies and agencies that accept
information anyone can acquire as a means to authenticate someone.

The net is making this worse, squared.

1. because of the net, this information is now more widely and easily
available, making the attacker's job easier.

2. to take advantage of the net, companies want to do their
authentication on-line.

So, is the answer digital signatures and ID certificates?  ID CAs are
as subject to these two points as any other company.

This is a serious problem in the way people do business.

The assumptions being challenged here have been on shaky ground for a
long time (e.g., since the rise of cities).  However, with the speed
of change due to the Internet, we can see the effects more clearly.

If we're going to fix this problem, we need to fix human habits, not
technology.  It is human habit to believe that names work and that
your knowledge of someone's past implies that you are that person,
etc.  We haven't built the human habits to respond to the new truths
-- that names are not valid identifiers and that everyone in the world
will have very good knowledge of the past of anyone they choose to
access.


From: "Mat Butler" <winged () voidnet com>
Subject: Full Disclosure versus hiding of information

I read with some interest your thoughts on the New York Times versus
John Young (the PDF obfuscation scandal), and realized that the ideas
presented by the "obfuscate sensitive information" crowd are a lot
like the same ones used by the U.S. government and military when
referring to classified information -- only those who 'need to know'
have access to it.

The problem comes in, in the public sector, when it's realized that
those who "need to know" have not had to submit to a security
clearance investigation.  This is more pronounced when the people who
legitimately need access to the information to secure their systems
are part of the "computer underground," and trade information for
favors from their acquaintances... and information about security
vulnerabilities travels fast in such circles.

The argument, broken down in simple form:

1) Security vulnerabilities are told to people who need to know --
webserver operators, system administrators, etc.

2) Trust of the people who "need to know" cannot be verified, since
there's no background checks done, and there's no centralized
information store about all sysadmins anyway.  (There's organizations
like SAGE, which espouse principles like the SAGE Code of Ethics, but
there's no requirement that anyone live up to those codifications.)

3) So, essentially, you're giving this information to people you do
not trust, and cannot validate that anyone else trusts.

In addition to this, even when the person who "needs to know" -should-
be notified, he or she often isn't -- this can be seen in every
Windows NT installation that hasn't gone through the steps to secure
its IIS.  (And, surprisingly, very few organizations actually have
security notification mailing lists for their products -- and even
more surprisingly, the sysadmins who run or are responsible for those
softwares rarely subscribe to them.)  So even when the company -is-
informed of the vulnerability, they often release a patch that's never
seen by those who need it.

It's better to fling the information far and wide, and get it into as
many discussion circles/professional organizations/sysadmin
professional contacts as possible, since it's the only way to ensure
that the largest number of interested parties can at least know what's
out there.  (Now, if they choose to not implement the knowledge, I
would think that that's probably their own, or their company's,
responsibility.)


From: Sean Lambert <seanl () metaip checkpoint com>
Subject: Cyber Group Network Corp.

> > From the July 15, 2000 CRYPTO-GRAM:

> The Cyber Group Network Corp claims to have a technology
> that allows you to locate a stolen computer, remotely retrieve
> information from it, and the destroy it.  Sounds a bit far fetched.
> But they take "security by obscurity to new heights:  "According to
> Nish Kapoor, a spokesperson for The Cyber Group Network, the patent
> pending technology that makes all this possible is being
> manufactured and developed at a remote, top-secret location
> identified only as 'Area 74.'"  Wow.
> <http://www.newsbytes.com/pubNews/00/151921.html>

Most readers will ponder the implications of this tool to users and
thieves.  How useful would it be?  Would I prefer tracking or
meltdown?  If I was going to steal it, how would I disable it?

I pondered it from another angle: bored hackers with a wireless
handheld and a GPS.  Could someone walk by your office building and
send the meltdown command to all of your computers?  Could some random
person track you wherever you go?  Is it possible that someone would
set up a Web site where your location (within 5 feet!) is displayed on
a map?

But don't worry, this tool is being developed in a location so secret
that Nish Kapoor, a spokesperson for The Cyber Group Network, doesn't
even know where it is.  That takes all my worries away.

Just be careful who you cut off in traffic if you have one of these in
your laptop.


From: Markus Kuhn <Markus.Kuhn () cl cam ac uk>
Subject: Re: Security Risks of Unicode

> I don't know if anyone has considered the security implications of this.
[...]
> - Somebody uses UTF-8 or UTF-16 to encode a conventional character in a
> novel way to bypass validation checks?

Thanks for reminding your readers about the security issues
surrounding the UTF-8 encoding of Unicode and ISO 10646 (UCS).

For some time, this and related issues have been of considerable
concern to us folks on the linux-utf8 at nl.linux.org mailing list,
who try to guide and accelerate the eventually inevitable migration of
the Unix world from ASCII and ISO 8859 to UTF-8 (which the Plan9
operating system has demonstrated it successfully almost a decade
ago). New UTF-8 decoders deployed in for instance GNU glibc 2.2,
XFree86 4.0 xterm, and various other standard tools have been
carefully designed to reject so-called overlong UTF-8 sequences as
malformed sequences, in order prevent that these UTF-8 decoders can be
abused by attackers to by-pass critical ASCII substring tests that are
applied earlier in the processing pipeline.

It is still very unfortunate that even the latest Unicode 3.0 standard
(ISBN 0-201-61633-5) contains at the end of section 3.8 on page 47 the
following paragraph: "When converting from UTF-8 to a Unicode scalar
value, implementations do not need to check that the shortest encoding
is being used. This simplifies the conversion algorithm."

This paragraph encourages the fielding of sloppy and dangerous UTF-8
decoders that will for example convert all of the following five UTF-8
sequences into a U+000A line-feed control character:

   0xc0 0x8A
   0xe0 0x80 0x8A
   0xf0 0x80 0x80 0x8A
   0xf8 0x80 0x80 0x80 0x8A
   0xfc 0x80 0x80 0x80 0x80 0x8A

A "safe UTF-8 decoder" should reject them just like malformed
sequences for two reasons: (1) It helps to debug applications if
overlong sequences are not treated as valid representations of
characters, because this helps to spot problems more quickly. (2)
Overlong sequences provide alternative representations of characters,
that could maliciously be used to bypass prior ASCII filters. For
instance, a 2-byte encoded line feed (LF) would not be caught by a
line counter that counts only 0x0A bytes, but it would still be
processed as a line feed by an unsafe UTF-8 decoder later in the
pipeline.

UTF-8 is known to be ASCII compatible, because every existing ASCII
file is already a correct UTF-8 file and non-ASCII characters do not
introduce additional occurrences of ASCII bytes. But from a security
point of view, ASCII compatibility of UTF-8 sequences must also mean
that ASCII characters are *only* allowed to be represented by ASCII
bytes in the range 0x00-0x7F and not by any other byte combination. To
ensure this often neglected aspect of ASCII compatibility, use only
"safe UTF-8 decoders" that reject overlong UTF-8 sequences for which a
shorter encoding exists, for example by substituting it with the
U+FFFD replacement character.

It is not true that the check for overlong UTF-8 sequences would add
any significant speed penalty or complexity to the UTF-8 decoder, as
for example my implementation of the decoder found in the XFree86 4.0
xterm version illustrates. The key to understanding how to implement a
safe UTF-8 decoder both simply and efficiently lies in realizing that
an UTF-8 sequences is overlong if and only if it contains one of the
following one or two byte long bit patterns:

   1100000x (10xxxxxx)
   11100000 100xxxxx (10xxxxxx)
   11110000 1000xxxx (10xxxxxx 10xxxxxx)
   11111000 10000xxx (10xxxxxx 10xxxxxx 10xxxxxx)
   11111100 100000xx (10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx)

A UTF-8 decoder robustness test file that allows developers to check
quickly an UTF-8 decoder for its safety is available on

   <http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txt>

For instance, major Web browsers still fail the test in section 4.1.1.

More information on UTF-8 under Unix are available on

   <http://www.cl.cam.ac.uk/~mgk25/unicode.html>


From: Curt Sampson <cjs () cynic net>
Subject: Re: Security Risks of Unicode

I have to say I'm rather appalled by your "Security Risks of Unicode"
article.  You have identified a type of security vulnerability in some
systems, and pointed out that Unicode may increase the incidence of
this type of vulnerability, but completely missed the source of the
vulnerability.

As we've seen from your examples of non-Unicode systems that have
experienced security failures, these problems do not stem from using
any particular character set or character set interpretation.  They
stem from doing what I like to call "validity guessing," rather than
true validity checking.

The key factor in all of these cases is that we have two separate
programs (the validity checker and the application itself) using two
separate algorithms to interpret data.  This is what introduces the
potential for a security breach: if ever the two programs do not
interpret a data stream in exactly the same way (and this can easily
happen if the two programs are not maintained by the same person or
group), it may become possible to convince the application to do
something the validator does not want to allow.

When it comes to security, guessing just isn't good enough.  This is
why, when we have parameters from external sources, we use the exec()
system call to run programs under Unix rather than the system()
library function.  We don't pass random data to the shell for
interpretation because we can never be sure how a particular
implementation of a particular shell on a particular system will
interpret it.  (We can't even be sure of what shell we're using --
/bin/sh may be any of a number of different programs.)

As long as we shift the blame for badly designed security systems to
external standards that are not the source of the problem, we will
have insecure systems.  Security is something that needs to be built
in to systems from the beginning, not tacked on with separate programs
at the end.


From: Henry Spencer <henry () spsystems net>
Subject: Re: Security Risks of Unicode

You have a point about potential input-validation attacks in Unicode,
given the much greater complexity of the character set... but I think
you have missed a couple of more important points.

Trying to analyze the input string for metacharacters, odd delimiters,
etc.  is basically a mistake.  I speak as someone who's written code
to do this, by the way -- it always smelled like a kludge to me, and
now I understand why.

First, prepending an input validator to a complex interpreter is a
fundamentally insecure approach.  Unless you are prepared to impose
truly severe restrictions on which features of the interpreter are
available -- in which case, why bother with the interpreter at all? --
the validator becomes an attempt to reinvent the interpreter's parser
and some of its semantic analysis.  This is an inherently error-prone
approach, as shown by various successful input-validation attacks.
The validator is a complex piece of software which must achieve and
maintain an exact relationship with the interpreter, which is all the
more difficult if the interpreter is ill-documented (as most complex
interpreters are) and constantly changing (ditto).

The right way -- the *only* right way -- to deal with this problem is
to insist that such interpreters include a show-only mode ("process
this input and tell me what it would make you do BUT DON'T DO IT").
This can be awkward for interpreters with complex programmability and
interactions with their environment; it may amount to actually running
the interpreter, but in a controlled and monitored environment with
dummy resources.  There can still be bugs -- unintended differences
between the show-only mode and the real mode -- but if the interpreter
is well organized, almost all of the show-only work is being done by
the real code rather than a cheap independently-maintained fake, and
there is at least a fighting chance that the behaviors will match.

(A do-only-safe-things mode is also of interest, but not as
satisfactory.  Definitions of safety may not match, and interpreter
bugs are arguably more likely to affect the outcome.)

Second, less confidently, I have to wonder whether elaborate parsing
isn't a mistake anyway.  When the context is program talking to
program, it would be better to define the simplest format possible, so
that parsing becomes trivial and there is no room for
misunderstandings.  This need not imply either binary data formats or
simple semantics; for example, one can send a complex tree structure
in prefix or postfix notation, one node per (text)  line.  Of course,
all too often the option isn't available because the format is
predefined by a 700-page standard, but the possibility is worth
bearing in mind.


From: Michael Smith <smithmb () usa net>
Subject: Re: Security Risks of Unicode

Speak of the devil...

Apparently, the dangers of Unicode you discussed in the latest
Crypto-Gram are not far off.  It's already going into use for domain
names:  "Asian-language domain names now available," at
<http://www.cnn.com/2000/TECH/computing/07/17/asian.domains.idg/index.html>.


From: Johan Ihren <johani () pdc kth se>
Subject: Re: SOAP

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

I don't really agree with this statement.  I think tunneling protocols
are a rather obvious consequence of the faith in firewalls as the
right solution to both having the cookie and eating it too, as in
being connected to the Internet, while being safe from its dangers.

If the security one hoped to gain from deploying a firewall with the
HTTP port open is somehow compromised by tunneling other stuff over
HTTP then the real problem lies in the firewall (or possibly one's
faith in its abilities), not merely in the other protocol.

The point with the firewall is basically that "outside" is dangerous
while "inside" is presumably insecure.  But it would be too expensive
to go around securing all machines and services on the inside.  So
instead a firewall is deployed to ensure that although the stuff on
the inside is insecure it still won't get compromised by the dangers
on the outside.

If the firewall doesn't catch "creative" new protocols tunneling on
top of whatever ports/protocols are open then the firewall was a
faulty solution providing a dangerous illusion of security.

In principle it doesn't really matter whether the protocol is designed
in Redmond or by anonymous crackers, although in reality stuff from
Microsoft are likely to get installed on a somewhat larger fraction of
machines than stuff from other sources.

So pointing out the consequences to the designer of one particular
tunneling protocol is of course fine.  But even at best that won't do
more than alleviate the pain of knowing that regardless of what ports
are closed in the firewall, as long as some port servicing a
sufficiently complicated protocol (like HTTP) is left open it will be
possible have unknown communication between unknown software on the
inside and unknown software on the outside with (at best) unknown
results.

But wasn't that exactly what the firewall was meant to stop?

Or, to put this another way: whatever security is provided by a
firewall isn't improved by a software design rule that forbids
tunneling through the firewall over other protocols.


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

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 hosted by SecurityFocus.com
---
To unsubscribe email LISTSERV () SecurityFocus com with a message body of
"SIGNOFF ISN".