RE: Attack vectors through Unassigned Code Points in IDN

From: Shawn Steele (???) (Shawn.Steele@microsoft.com)
Date: Wed Mar 18 2009 - 13:16:03 CST

  • Next message: Shawn Steele (???): "RE: Attack vectors through Unassigned Code Points in IDN"

    Its kind of a personal perspective as to whether lookup of unassigned code points is good behavior or not. My opinion (rather obviously) is that the unknowns aren't worth the risk considering we'll service the APIs when necessary.

    I figure with Windows Update, for consumers of my APIs they'll get updated in a reasonable time (assuming the IETF "we" ever make any progress on IDNA"2008" ;) Some people turn off WU, but that's a different problem.

    Not sure this is a Unicode thread though :)

    - Shawn

    ________________________________
    From: Mark Davis [mark.edward.davis@gmail.com]
    Sent: Wednesday, March 18, 2009 11:35 AM
    To: Phillips, Addison
    Cc: Shawn Steele (???); Chris Weber; unicode@unicode.org
    Subject: Re: Attack vectors through Unassigned Code Points in IDN

    IDNA forbids registration of unassigned code points, but allows lookup with them by clients (eg browsers). The goal was to allow users to supply characters that were of a later Unicode version than their client software supports, and yet have the lookup work where the registry supports that later version of Unicode.

    I agree with Shawn, there are plenty of techniques like https://www.google.com.secure.net or https://www.google.com-secure.net; as far as I'm concerned, it is a deficiency in the browser if it doesn't signal these kinds of problems to the user.

    Mark


    On Wed, Mar 18, 2009 at 10:50, Phillips, Addison <addison@amazon.com<mailto:addison@amazon.com>> wrote:

    Dropping unassigned code points would mean that newly assigned characters in Unicode could not be used without a browser update. So maybe that *isn’t* a good idea. Registering a name with unassigned code points is a bad idea (users will have a difficult time using the address and the name’s semantics/meaning/display would change when the character is assigned).



    Addison



    Addison Phillips

    Globalization Architect -- Lab126



    Internationalization is not a feature.

    It is an architecture.



    From: unicode-bounce@unicode.org<mailto:unicode-bounce@unicode.org> [mailto:unicode-bounce@unicode.org<mailto:unicode-bounce@unicode.org>] On Behalf Of Shawn Steele (???)
    Sent: Wednesday, March 18, 2009 10:00 AM
    To: Chris Weber ; unicode@unicode.org<mailto:unicode@unicode.org>
    Subject: RE: Attack vectors through Unassigned Code Points in IDN



    (speaking as myself)



    Sounds like a Firefox bug. Unassigned code points should cause an error since they aren’t assigned. If they were dropped, then at the least, the shortened name should show up in the address bar.



    For most users this probably doesn’t matter much since you can easily contrive URLs that look real at a quick glance or to someone not familiar with URLs, eg: https://www.google.com.secure.net would fool many users.



    -Shawn



    From: unicode-bounce@unicode.org<mailto:unicode-bounce@unicode.org> [mailto:unicode-bounce@unicode.org<mailto:unicode-bounce@unicode.org>] On Behalf Of Chris Weber
    Sent: Pōʻ, Malaki 17, 2009 10:06 PM
    To: unicode@unicode.org<mailto:unicode@unicode.org>
    Subject: Attack vectors through Unassigned Code Points in IDN



    In I’m reading RFC 3491 correctly, then IDNA allows for unassigned code points to exist in strings and domain names. This makes spoofing attacks possible when one these code points don’t have associated glyphs and basically show up as white space. This seems to be the case with some ranges like U+115A..U+115E under. In this case the following URL provides an attack vector in Firefox, because the domain nottrusted.org<http://nottrusted.org> gets pushed way out of view in the Address Bar.



    https://www.google.comᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚ.phreedom.org/>





    My question is – was this the intended behavior of IDNA to allow unassigned code points in IDN? Or is this more related to a font rendering issue?



    7. Unassigned Code Points in Internationalized Domain Names



       If the processing in [IDNA] specifies that a list of unassigned code

       points be used, the system uses table A.1 from [STRINGPREP] as its

       list of unassigned code points.



    Thanks,

    -Chris



    This archive was generated by hypermail 2.1.5 : Wed Mar 18 2009 - 13:18:20 CST