[Bug 1301928] New: libxml2: out-of-bounds read in htmlParseNameComplex()

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301928

Bug ID: 1301928
           Summary: libxml2: out-of-bounds read in htmlParseNameComplex()
           Product: Security Response
         Component: vulnerability
          Keywords: Security
          Severity: medium
          Priority: medium
          Assignee: [e-mail]
          Reporter: [e-mail]
                CC: [e-mail], [e-mail],
                    [e-mail],
                    [e-mail],
                    [e-mail], [e-mail],
                    [e-mail], [e-mail],
                    [e-mail]

An out-of-bounds read flaw was reported in libxml2's htmlParseNameComplex()
function:

http://seclists.org/oss-sec/2016/q1/199

A remote attacker could provide a specially crafted XML file that, when
processed by an application linked against libxml2, could cause the application
to disclose crash.

[Bug 1301928] libxml2: out-of-bounds read in htmlParseNameComplex()

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301928

Martin Prpic  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends On|                            |1301929
         Depends On|                            |1301930
         Depends On|                            |1301931

--- Comment #1 from Martin Prpic  ---

Created libxml2 tracking bugs for this issue:

Affects: fedora-all [bug 1301929]

Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1301929
[Bug 1301929] libxml2: out-of-bounds read in htmlParseNameComplex()
[fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1301930
[Bug 1301930] mingw-libxml2: libxml2: out-of-bounds read in
htmlParseNameComplex() [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1301931
[Bug 1301931] mingw-libxml2: libxml2: out-of-bounds read in
htmlParseNameComplex() [epel-7]

[Bug 1301928] libxml2: out-of-bounds read in htmlParseNameComplex()

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301928

--- Comment #2 from Martin Prpic  ---

Created mingw-libxml2 tracking bugs for this issue:

Affects: fedora-all [bug 1301930]
Affects: epel-7 [bug 1301931]

[Bug 1301928] libxml2: out-of-bounds read in htmlParseNameComplex()

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301928

Martin Prpic  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |1301932

[Bug 1301928] libxml2: out-of-bounds read in htmlParseNameComplex()

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301928

Martin Prpic  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
              Alias|                            |CVE-2016-2073

[Bug 1301928] CVE-2016-2073 libxml2: out-of-bounds read in htmlParseNameComplex()

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301928

Martin Prpic  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|libxml2: out-of-bounds read |CVE-2016-2073 libxml2:
                   |in htmlParseNameComplex()   |out-of-bounds read in
                   |                            |htmlParseNameComplex()

[Bug 1301928] CVE-2016-2073 libxml2: out-of-bounds read in htmlParseNameComplex()

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301928

Cedric Buissart  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #3 from Cedric Buissart  ---
Below is my current understanding of this issue (which, I believe, is identical
to 1304636) :

The issue is when a word starts with normal ASCII chars and jumps to UTF
multibytes chars.

The issue is in htmlParseNameComplex. More precisely, in the while{} loop. The
following happens :

vars:
len: the size of the word, in bytes. this is used to be able to get back to the
begining of the word (i.e.: 'ctxt->input->cur - len')
c : the current character (can be multibytes)
l : the size in bytes of character c

The while loop will find the end of the word. The expectation is the following
: 'ctxt->input->cur' points to the end of the word, and len contains the word's
length in byte, thus ctxt->input->cur - len points to the beginning of the
word.

htmlCurrentChar() is called during the process (via macro CUR_CHAR), and
returns the next character (possibly multibytes) along with its size (l is
updated).
While in htmlCurrentChar(), if the character is multibytes/non-ASCII, this will
lead to a change of encoding via the function xmlSwitchToEncodingInt().
During this switch, xmlBufShrink() is called. The purpose of this function is
to remove the beginning of an XML buffer, via memmove. But this is done from
the current character, not from the begining of the word. Thus, in the process,
ctxt->input->cur will point to the begining of the string, and thus
'ctxt->input->cur - len' will point before the beginning of the string.

The number of bytes to be removed is based on the following calculation :
[parserInternals.c:1202] processed = input->cur - input->base;
In order to keep the current word, htmlParseNameComplex's 'len' value should be
removed here too so that the shrinking stops at the begining of the word
instead of the current character.

i.e.: my understanding is that xmlBufShrink() should not shrink beyond the
beginning of the current word

==============

Breakpoint 2, xmlBufShrink__internal_alias (buf=0x602550, len=len@entry=14) at
buf.c:386
386     xmlBufShrink(xmlBufPtr buf, size_t len) {
(gdb) bt
#0  xmlBufShrink__internal_alias (buf=0x602550, len=len@entry=14) at buf.c:386
#1  0x00007ffff7aa8764 in xmlSwitchInputEncodingInt (ctxt=0x6045b0,
input=0x605b30, handler=0x6023e0, len=45) at parserInternals.c:1194
#2  0x00007ffff7aa9b59 in xmlSwitchToEncodingInt (len=<optimized out>,
handler=<optimized out>, ctxt=0x6045b0) at parserInternals.c:1272
#3  xmlSwitchEncoding__internal_alias (ctxt=ctxt@entry=0x6045b0,
enc=enc@entry=XML_CHAR_ENCODING_8859_1) at parserInternals.c:1100
#4  0x00007ffff7ae7425 in htmlCurrentChar (ctxt=0x6045b0, len=0x7fffffffdc54)
at HTMLparser.c:518
#5  0x00007ffff7ae77d5 in htmlParseNameComplex (ctxt=0x6045b0) at
HTMLparser.c:2515
#6  htmlParseName (ctxt=ctxt@entry=0x6045b0) at HTMLparser.c:2483
#7  0x00007ffff7aa0a73 in htmlParseDocTypeDecl (ctxt=ctxt@entry=0x6045b0) at
HTMLparser.c:3398
#8  0x00007ffff7aed52d in htmlParseTryOrFinish (terminate=<optimized out>,
ctxt=<optimized out>) at HTMLparser.c:5440
#9  htmlParseChunk__internal_alias (ctxt=0x6045b0, chunk=<optimized out>,
size=<optimized out>, terminate=0) at HTMLparser.c:6070
#10 0x00000000004007f4 in main (argc=1, arg=0x7fffffffdec8) at foo.c:25

Before the shrink :
(gdb) p *ctxt->input
$9 = {buf = 0x602500, [...], base = 0x6025a0 "<!DOCTYPE
html\342\t</</body></html>", cur = 0x6025ae "\342\t</</body></html>", end =
0x6025c1 "", length = 0, line = 1, col = 15, consumed = 0, [...]}

After the shrink:
(gdb) p *ctxt->input
$15 = {buf = 0x602500, [...], base = 0x6025a0 "\342\t</</body></html>", cur =
0x6025ae "tml>", end = 0x6025c1 "", length = 0, line = 1, col = 15, consumed =
0, [...]}

The final input, after readjustement :
(gdb) p *ctxt->input
$23 = {buf = 0x602500, [...], base = 0x605d50 "â\t</</body></html>", cur =
0x605d50 "â\t</</body></html>", end = 0x605d64 "", length = 0, line = 1, col =
15, consumed = 0, [...]}