This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug locale/19519] iconv(1) with -c option hangs on illegal multi-byte sequences (CVE-2016-10228)


https://sourceware.org/bugzilla/show_bug.cgi?id=19519

--- Comment #11 from Arjun Shankar <arjun.is at lostca dot se> ---
> echo -en '\x80' | iconv -f us-ascii -t us-ascii//translit//ignore -c
> echo -en "\x0e\x0e" | /usr/bin/iconv -c -f IBM1364

I have not investigated the second reproducer, but I am quite sure that it is
completely unrelated to the first one.

The first one is caused by incorrect parsing of the "//" marked suffixes
(//translit and //ignore). The problem is that the second suffix is being
dropped when parsing. This is why the order matters. The case reported, i.e.:

$ echo -en '\x80' | iconv -f us-ascii -t us-ascii//translit//ignore -c

is one where the "//translit" suffix is actually irrelevant because the input
does not have characters that can/should be transliterated, but its presence as
the first suffix leads to the actually relevant "//ignore" suffix (0x80 is not
valid ASCII) being *ignored* by iconv, leading to a hang.

This is why, these four similar cases:

$ echo -en '\x80' | iconv -f us-ascii -t us-ascii//ignore//translit -c
$ echo -en '\x80' | iconv -f us-ascii -t us-ascii//ignore -c
$ echo -en '\x80' | iconv -f us-ascii -t us-ascii -c
$ echo -en '\x80' | iconv -f us-ascii -t us-ascii//translit -c

do not hang. The '//ignore' suffix being first (or implied via -c) gets picked
up by the program and it correctly outputs nothing, and  the "//translit", if
present, is dropped (incorrectly) - but this has no effect for this particular
input on the program's running because like I mentioned earlier: there is
nothing to be transliterated in the input. Note that '-c' actually appends the
"//ignore" to the target encoding suffix if no suffixes are present, and
",ignore" if one or more suffixes are already present. If two suffixes are
passed during input, then the ',ignore' appended because of '-c' will get
dropped along with the second suffix, which may or may not lead to hang
depending on whether the first suffix is //ignore.

The hang in case of a missing "//ignore" suffix (well, not really missing here
but ignored by the program) afterwards during execution is a separate problem
(that I haven't investigated).

I'm going to write a patch to fix the problem with the parsing at the right
place(s), and then tackle the hangs separately.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]