=?iso-8859-1?Q?Re: Re: Another confusable security hole?=

From: =?iso-8859-1?Q?Marc Brugui=E8res?= (marcbruguieres@ifrance.com)
Date: Thu Nov 03 2005 - 10:26:36 CST

  • Next message: Hans Aberg: "Re: Superscripts"

    Philippe Verdy <verdy_p@wanadoo.fr> avait écrit :

    > From: "Marc Bruguières" <marcbruguieres@ifrance.com>
    > > Elliotte Harold:
    > >> Paul Battley found an issue involving Unicode characters that look like
    > >> periods used to disguise executables on Mac OS X:
    > >> http://po-ru.com/articles/osx-trojan/
    > >> I think if I were Apple I'd probably just ban these characters in file
    > >> names.
    > >
    > > Which characters? Different from those that ICANN will want to ban? How
    > > many ways of plugging the holes? Shouldtn't his be solved *as much as
    > > possible* in Unicode, rather looks like there are more and more
    > > confusables being encoded (for example Ancient Greek Musical Signs,
    > > Arabic diacritics, etc.).
    > For Apple, it is simple to solve: it must just signal along with all icons,
    > if this is really a safe thumbnail,

    I'm sure every software editor may come up with a reasonable solution (when it has time and resources).

    The question is rather that each should have to handle confusables its own way because Unicode may have let those confusable be encoded while their character identity (their look and behaviour) were identical. This could mean more spoofing opportunity and more spoofing handling as needed if less confusables had been coded in the first place.

    For sure some confusable are unavoidable (A = Latin, Greek, Cyrillic although their behaviour is different after a toLowerCase(), here there is a good technical reason to code a confusable), but I'm not at all convinced that Unicode has not encoded a bit too quickly confusables which have no behavioral differences and Unicode washes its electronic hands by thinking that security and spoofing will be dealt with somewhere else. This somewhere else will have to be "manywheres else" and more complex because of this perceived indifference in removing confusable (through unification) in the standard itself.


    This archive was generated by hypermail 2.1.5 : Thu Nov 03 2005 - 10:30:14 CST