RE: Attack vectors through Unassigned Code Points in IDN

From: Chris Weber (chris@casabasecurity.com)
Date: Wed Mar 18 2009 - 16:23:21 CST

  • Next message: John H. Jenkins: "Re: Attack vectors through Unassigned Code Points in IDN"

    My question is - why would these code point ranges U+115A..U+1160 and U+11A3..U+11A7 render as white space in Mac and Windows? This isn't just a product of Firefox, which I agree handles this poorly. In any application (e.g. notepad) they show as white space. I would expect them to map to a box or other no-glyph-exists fallback.

    =Chris

    -----Original Message-----
    From: Chris Weber [mailto:chris@casabasecurity]
    Sent: Wednesday, March 18, 2009 1:48 PM
    To: Mark Davis
    Cc: Phillips, Addison; Shawn Steele; Chris Weber; unicode@unicode.org
    Subject: Re: Attack vectors through Unassigned Code Points in IDN

    I think this answers my question. I'm presenting on Unicode and IDN
    security at CanSecWest tomorrow and was just verifying that IDNA does
    allow clients to lookup unassigned code points.

    This attack is in subdomain labels, beyond the registrars' control. I
    agree it's a bug in Firefox and in general the browsers need to get a
    handle on how they handle IDN.

    My other question is this - why on Mac and Windows do these code point
    ranges render as invisible white space? I would expect them to map to a
    box or other no-glyph-exists fallback glyph.

    thanks,
    Chris

    > 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%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 - 16:26:57 CST