Subject: [idn] Re: Unicode and Security

From: John Hudson <[email-masked]>
Date: Thu, 07 Feb 2002 13:04:46 -0800

At 10:21 2/7/2002, Elliotte Rusty Harold wrote:

>I'm not sure Unicode can be fixed at this point. The flaws may be too
>deeply embedded.

What flaws? The fact that glyphs in different scripts may be similar or
identical in some typefaces, and misrepresentation is possible because
Unicode separately encodes these glyphs as distinct characters? I'm
sorry,
but that is the nature of writing systems, and Unicode's encoding of
these
characters is inherited from existing standard character sets. Is this a
flaw? Is this as great a flaw as glyph-based encoding would have been?
Is
it as great a flaw as hampering backwards compatibility with other
encodings would have been?

In your examples, you seem to ignore two things:

1. The software industry has already devised mechanisms to protect
against
e-mail forgery, e.g. private-public key encryption.

2. What you describe is criminal fraud and there are laws to protect
against such 'spoofing' and to punish those who perpetrate it.

John Hudson

Tiro Typeworks www.tiro.com
Vancouver, BC [email-masked]

>... es ist ein unwiederbringliches Bild der Vergangenheit,
das mit jeder Gegenwart zu verschwinden droht, die sich
nicht in ihm gemeint erkannte.

>... every image of the past that is not recognized by the
present as one of its own concerns threatens to disappear
irretrievably.
                                               Walter Benjamin

---

From: David Starner <[email-masked]>
Date: Thu, 07 Feb 2002 13:09:01 -0800

On Thu, Feb 07, 2002 at 12:22:18PM -0500, Elliotte Rusty Harold wrote:
> Interestingly, my attack works with a single character representation
> (Unicode). It is not dependent on multiple charsets.

It also works with EUC-JP (and other Japanese charsets), all 8-bit
Russian representations, all 8-bit Greek representations . . .

>  The problem needs to be fixed closer to the source.

How about a solution that doesn't involve the destruction of Unicode as
a useful tool? The fact that MD5 sums matching doesn't prove that the
files match is not a bug in MD5 sums. Likewise, the fact that glyphs may
look alike in a _character_ is not a bug in the character encoding.

--
David Starner - [email-masked], dvdeug/jabber.com (Jabber)
Pointless website: http://dvdeug.dhis.org
What we've got is a blue-light special on truth. It's the hottest thing
with the youth. -- Information Society, "Peace and Love, Inc."

---

From: Barry Caplan <[email-masked]>
Date: Thu, 07 Feb 2002 10:16:26 -0800

At 12:22 PM 2/7/2002 -0500, Elliotte Rusty Harold wrote:
>I've been thinking about security issues in Unicode, and I've come up
with
>one that's quite scary and worse than any I've heard before. It uses
only
>plaintext, no fonts involved, doesn't require buggy software, and works
>over e-mail instead of the Web. All it requires added to the existing
>infrastructure is internationalized domain names. So in the hope that
this
>becomes a self-defeating prophecy, here's the scenario:
>
><snip>"Can you please update me on your budget?" Bob, noticing that the
>e-mail appears to come from Alice, whom he knows and trusts, fires off
a
>reply with his confidential information. Only it doesn't go to Alice.
It
>goes to me. I can then reply to Bob, asking for clarification or more
>details. I can ask him to attach the latest build of his software. I
can
>carry on a conversation in which Bob believes me to be Alice and spills
>his guts. This is very, very bad.

This is precisely the problem digital signing is meant to solve. Signing
means that Alice has encrypted the message with her private key before
sending to Bob. Bob then unencrypts the message using Alice's public
key.
If the message does not unencrypt, then Bob should not trust that the
message is from Alice. This algorithm works independent of transport
mechanism (email, etc.), or domains. Alice's key stays with Alice,not
with
the domain. Of course, how you exchange trusted keys in the first place
is
another matter, but I am sure this is all covered on a security FAQ
somewhere.

>E-mail forgery has been a problem for a long time, but it's always been
>one-way. You couldn't trick somebody into sending you a reply because
>doing so required using a different e-mail address than the one they
>expected, thus revealing the message as forged.

There are many many ways to get a response from someone via email, even
if
the address is not recognized or forged. Most involve social engineering
approaches more than anything else. My mailbox filled with spam will
attest
the that!

>With a Unicode enabled mailer, that's no longer true. If the fonts Bob
>(not me, but Bob) chooses for his e-mail program do not make a clear
>distinction between an o and an omicron, this works. There are lots of
>other attacks. The Cyrillic and Greek alphabets provide lots of options
>for replacing single letters in Latin domain names.

Unless all messages are signed (technically feasible) , then there is no
trust at all. When Outlook/Exchange supports, in fact requires, messages
to
be signed, then this problem will start to dwindle away, at least in the
email realm.

Of course if there is a method to judge the level of trust for properly
signed messages that arrive from folks you don't know (a human
failability), then knowing the origin of the message might not help much
either. My inbound spam can be verifiably signed, but it is still spam.

>In other words, it's not our fault. Blame the client software. Sounds
>distressingly like the Unicode Consortium's approach to these issues.
>(Unicode).

Your attack is only a social engineering attack, not a technical
weakness
inherent in any protocol, or character set (even though there may be
such
issues)

Barry

---

From: David Starner <[email-masked]>
Date: Thu, 07 Feb 2002 13:09:59 -0800

---

From: Asmus Freytag <[email-masked]>
Date: Thu, 07 Feb 2002 13:12:04 -0800

>>Interestingly, my attack works with a single character representation

Substituting Greek for Latin works just as well with 8859-7 as with
Unicode. And (as I have argued separately) it will have to work with any
workable multilingual character set.

For the record it's worth noting that Unicode as a rule requires
additional
and strong justification before encoding characters that duplicate the
appearance of an existing character (but may have a different function).
The reason for that is not security, but the fact that such duplication
always carries with it the risk of unintentional misidentification and
therefore corrupt data. Such risk is mitigated for the characters from
different scripts (or different alphabets) since data entry methods
(keyboards) would normally allow access for only the proper character.
(If
I set my keyboard to Greek, I won't get the Latin "A" by accident).

Exceptions are found in some areas of punctuation. But good editing
software can make the distinction visible.
A security conscious browser could alert users to mixed Latin/Greek URLs
in
precisely the same way.

A./

---

From: Asmus Freytag <[email-masked]>
Date: Thu, 07 Feb 2002 16:28:30 -0800

At 01:21 PM 2/7/02 -0500, Elliotte Rusty Harold wrote:

>deeply embedded. The real solution may involve waiting until companies
and
>people start losing significant amounts of money as a result of the
flaws
>in Unicode, and then throwing it away and replacing it with something
else.

This sounds nice and dramatic, but misses the point that the kinds of
issues you highlighted are absolutely common to *all* character sets
containing Latin and Greek, or Latin and Cyrillic characters, suggesting
that you are simply grandstanding here, instead of trying to find real
solutions to your problem.

Earlier, you accused Unicode of being in denial about security issues:
It
is you who is in denial about some underlying realities, among which is
that there are security issues that cannot be "fixed" by designing a
'better' character set. You remind me of the people who keep on
designing
perpetual motion devices, even after the laws of thermodynamics proved
the
futility of such efforts.

If you are interested in advancing security you would stop from barking
up
this blind alley and focus your energy on attacking the problems with
other
means. Plenty of suggestions have been made in this space over the last
few
days. Some of all of these should be explored.  But if we learned
anything
useful in this exchange, it is that no security scheme should be
designed
so that it is dependent on the character encoding as primary defense
against spoofing. Doing so would burden the character encoding with a
task
it will never be capable of fulfilling, since it would mean seriously
compromising support for the tasks for which it was created in the first
place.

A./

---

From: [email-masked]
Date: Sat, 09 Feb 2002 16:48:33 -0800

<p0433010ab8884ddfb787@[192.168.254.4]>
<p04330110b88860b92563@[192.168.254.4]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
From: Lars Marius Garshol <[email-masked]>
Date: 09 Feb 2002 21:52:17 +0100
In-Reply-To: <p04330110b88860b92563@[192.168.254.4]>
Message-ID: <[email-masked]>
Lines: 53
X-Mailer: Gnus v5.5/Emacs 20.2
Sender: [email-masked]
Precedence: bulk

* Elliotte Rusty Harold
|
| Let's say I register microsoft.com, only the fifth letter isn't a
| lower-case Latin o. It's actually a lower case Greek omicron.

I'll grant you that this is possible, perhaps even likely, and that it
may cause problems, but I'm far from convinced that this in any way
supports the "there are security problems in Unicode" thesis.

There are many characters which look alike, and yet are different,
which can cause problems of this kind. There are for example already
viruses which exploit the visual similarity between 1 and l in the
Windows system font to keep themselves from being discovered in file
listings.

So if this really is considered a problem it would seem to me that you
would need to deal with the problem of [email-masked],
[email-masked], and [email-masked] looking very similar to
[email-masked] in lots of fonts. To exploit this, all you need to
know is what email client someone uses, and usually every email they
write will have that information in its headers.

It seems to me that this problem really needs some other fix than the
merging of all similar-looking characters in all character sets. I
just can't see that working.

Similarly, the "security problems" caused by using Unicode encoding
tricks to hide or mangle text in, say, contracts, is no different from
using HTML or CSS (or whatever) tricks to achieve the same effect, and
yet nobody is talking about security problems with HTML or CSS. See
[1] for one way of dealing with it that is now being worked on.

So while I accept that there is a problem it does not seem to me that
Unicode is the problem. To me the problem seems to be the complexity
of the relationship between the bytes sent to the user and what the
user actually sees and reacts to. That complexity is not going to
disappear, and aspects of the same "problem" exist with just about any
information representation, so clearly the solution must be something
other than changing all of these syntaxes/formats/encodings.

In the specific case you cite, for example, a better solution might be
for the user's email client to keep track of all the user's contacts
and for it to indicate in some clearly visible way whether the current
email comes from one of them or not. Whether it uses string matching
of email addresses or digital signatures to do that doesn't really
matter; it solves the problem in your example either way.

[1] <URL: http://www.w3.org/TR/xmldsig-core/#sec-Seen >

--
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
ISO SC34/WG3, OASIS GeoLang TC        <URL: http://www.garshol.priv.no >