Message-ID: <422EFEAA.10600.16BB1CBA@localhost>
Date: Wed, 09 Mar 2005 13:48:26 +1300
From: Nick FitzGerald <nick@...us-l.demon.co.uk>
To: bugtraq@...urityfocus.com
Subject: Re: houghts and a possible solution on homograph attacks


Sven Putteneers wrote:

> If this patch would be widely used, we'd lose the all the advantages
> associated with IDN.

I think that was the point.

IDN was not a very clever idea from the start -- it breaks the "don't 
allow the obvious to not be what it appears to be" (aka "don't surprise 
the user", etc, etc) rule which is one of the very most important rules 
of any kind of technology/human interface.  When you do break that rule 
you get all kinds of "obvious" problems down the track, including very 
many that should have been obvious at the outset, to the designer of 
the system or functionality that did the breaking.

Such stupid and eternally regrettable design decisions have often been 
strongly commercially motivated.

> Maybe it's better to attack this problem on the browser side and have a

Given IDN would seem to be here to stay, I'd say that will be the only 
place we can attack it...

> configuration switch to enable or disable IDN. We could disable it as a
> "reasonable default", but those who need it, could enable it.
> Upon enabling the option, a warning dialog could pop up that warns the
> user about the security problems associated with IDN ("don't enable this
> unless you know what you're doing" stuff).
> 
> That way the majority of the users would be safe from IDN attacks
> (phishing comes to mind) and those who really want IDN would have to
> click through a warning dialog telling them why enabling it may not be
> such a good idea.

Such warnings have far from sufficient efficacy.  Much history shows 
that the folk who will most likely "stupidly ignore" such warnings are 
precisely the ones that would derive (most) benefit from the warnings 
_had they heeded them_ (i.e. the folk who really need this protection 
are the ones that will turn it off).  The "let's pop up a warning 
message" approach to truly hard problems such as this is a commonly 
seen approach that shows the developer's total lack of understanding 
_and_ caring about the actual problem.

Without having thought too hard about all this, a better browser-side 
solution may be to not allow domain names with a mixture of ASCII and 
IDN characters (I mean to the left of the unavoidably ASCII (??) top 
level country, .com, .mil, .org, .net, etc domain name components).  If 
you have a Korean or Japanese or Mandarin or whatever domain name, then 
there should be no need for any ASCII characters in it.  There may be 
problems with this idea with Central European names, where much of the 
ASCII character set is employed along with a few special characters, 
and with domain names that incorporate numerals.  If IDN can be used to 
encode characters from the ASCII character set too then these problems 
are moot, but we end up back where we started in terms of mixed 
ASCII/IDN-only chars being the "problem".

Of course, not allowing mixed ASCII/IDN does not entirely remove the 
problem of "IDN-spoofing" -- for most suitably long domain names 
(perhaps those with more than five _different_ caracters?) it is 
probably a safe bet that there will not be a suitable set of IDN 
homographs* possible to spoof your domain name, but for shorter ones...


*  Being the semi-pedant that I am, "homograph" was always the wrong 
term for these IDN spoofing tricks.  A homograph is a pair of words (or 
presumably more) that are spelt the same but have different meanings.  
What we are talking about here are two (or more) words that are spelt 
differently but look the same -- perhaps "pseudograph", if not the 
right word, is certainly better.)




-- 
Nick FitzGerald
Computer Virus Consulting Ltd.
Ph/FAX: +64 3 3267092

Powered by blists - more mailing lists