Re: Attack vectors through Unassigned Code Points in IDN

From: Mark Davis (mark.edward.davis@gmail.com)
Date: Wed Mar 18 2009 - 12:35:57 CST

  • Next message: John H. Jenkins: "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> 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] *On
    > Behalf Of *Shawn Steele (???)
    > *Sent:* Wednesday, March 18, 2009 10:00 AM
    > *To:* Chris Weber ; 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] *On
    > Behalf Of *Chris Weber
    > *Sent:* Pōʻ, Malaki 17, 2009 10:06 PM
    > *To:* 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 gets pushed
    > way out of view in the Address Bar.
    >
    >
    >
    > https://www.google.comᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚ.phreedom.org/%E1%85%9A%E1%85%9A%E1%85%9A%E1%85%9A%E1%85%9A%E1%85%9A%E1%85%9A%E1%85%9A%E1%85%9A%E1%85%9A%E1%85%9A%E1%85%9A%E1%85%9A%E1%85%9A%E1%85%9A%E1%85%9A.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 - 12:37:33 CST