91296 - UTF-8 decoder accepts overlong sequences

Status: VERIFIED INVALID

(Core :: Internationalization, defect)

Description

[Christopher Hoess (gone)]

In Section 4, a number of overlong UTF-8 sequences are included in the document,
which should be rejected by the UTF-8 decoder.  Failure to do so opens the
possibility of an attack based on concealing line feeds, etc. in overlong
sequences.  The document contains a number of UTF-8 "edge cases", not all of
which may have security implications.

Comment 1

[Mitchell Stoltz (not reading bugmail)]

Interesting...sounds like this could be a security problem. Reporter, could you
provide a demonstration of how this could be exploited?

Reassigning to I18n, I believe that's the right component.

Comment 2

[nhottanscp]

Reassign to ftang.
I think this has already been done by jgmyers.

Comment 3

[Christopher Hoess (gone)]

Unfortunately, I can't provide a demonstration, as I don't have a hex editor on
hand, but I can describe approximately how to construct one.  Using one of the
overlong character representations in the document, construct a line feed,
rather than a slash character.  Feed this string into some input where linefeeds
are normally stripped (some/all URLs?), and see if the character is, in fact,
stripped.

Even if this doesn't present a security risk, the commentary in the document
suggests that such representations are to be discouraged (as they can be used to
exploit unwary UTF-8 decoders); perhaps we should refuse to decode to discourage
their use (which, AFAIK, is minimal, but someone could always write a broken
creation tool...) 

Comment 4

[Frank Tang]

I don't think there are a REAL security hole here. I know unicode.org recently
change the definitation of UTF-8 as specified in
http://www.unicode.org/unicode/reports/tr27/

Comment 5

[Frank Tang]

We should list all the code in mozilla which do utf8 conversion here first. 

Comment 6

[John G. Myers]

I've long since fixed this in the two UTF-8 decoders I've found.  Once in the 
intl UTF-8 decoder, once in the string code.  The fixed code decodes overlong 
sequences to REPLACEMENT CHARACTER.

Please be specific as to which test cases in section 4 the current code 
interprets incorrectly.

Comment 7

[Frank Tang]

Christopher Hoess:
ok, we believe that we already fix this issue. if you still think mozill have
this issue, then please provide step by step test cases and reopen it. Thanks

Comment 8

[Yuying Long]

Verified.  Re-open it in case you see the problem again.