GNOME Bugzilla – Bug 744980
Out of bounds memory access in libxml2
Last modified: 2016-06-15 04:54:19 UTC
Hey, There appears to be an out-of-bounds read in libxml2 (2.9.2). This normally won't cause a crash, but is visible under ASAN or Valgrind. One way to repro would be: $ printf '<!DOCTYPEd[<!ENTITY\nS\t""><!ENTITY %%\nN\t"<!ELEMENT<![INCLUDE0"<!ENTITYL%%N;' >test.xml $ ./xmllint_asan test.xml Copy of the test case: http://lcamtuf.coredump.cx/afl/demo/libxml2_oob.xml ==17901==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60300000ea56 at pc 0x46cfc5 bp 0x7fffffffc420 sp 0x7fffffffc400 READ of size 1 at 0x60300000ea56 thread T0 #0 0x46cfc4 in xmlParseConditionalSections (/home/lcamtuf/afl/TEST_ASAN/xmllint_asan+0x46cfc4) #1 0x46d7b3 in xmlParseMarkupDecl (/home/lcamtuf/afl/TEST_ASAN/xmllint_asan+0x46d7b3) #2 0x4772a3 in xmlParseInternalSubset (/home/lcamtuf/afl/TEST_ASAN/xmllint_asan+0x4772a3) #3 0x48e9b1 in xmlParseDocument (/home/lcamtuf/afl/TEST_ASAN/xmllint_asan+0x48e9b1) #4 0x4abe06 in xmlDoRead (/home/lcamtuf/afl/TEST_ASAN/xmllint_asan+0x4abe06) #5 0x4ac022 in xmlReadFile (/home/lcamtuf/afl/TEST_ASAN/xmllint_asan+0x4ac022) #6 0x40aa34 in parseAndPrintFile (/home/lcamtuf/afl/TEST_ASAN/xmllint_asan+0x40aa34) #7 0x411f43 in main (/home/lcamtuf/afl/TEST_ASAN/xmllint_asan+0x411f43) #8 0x7ffff61fcaf4 in __libc_start_main (/lib64/libc.so.6+0x21af4) #9 0x402f08 (/home/lcamtuf/afl/TEST_ASAN/xmllint_asan+0x402f08) 0x60300000ea56 is located 1 bytes to the right of 21-byte region [0x60300000ea40,0x60300000ea55) allocated by thread T0 here: #0 0x7ffff6f4a6a8 in __interceptor_malloc (/usr/local/lib64/libasan.so.1+0x6d6a8) #1 0x5f6d98 in xmlStrndup (/home/lcamtuf/afl/TEST_ASAN/xmllint_asan+0x5f6d98) #2 0x412e50 in xmlCreateEntity (/home/lcamtuf/afl/TEST_ASAN/xmllint_asan+0x412e50) #3 0x41320a in xmlAddEntity (/home/lcamtuf/afl/TEST_ASAN/xmllint_asan+0x41320a) #4 0x41373a in xmlAddDocEntity (/home/lcamtuf/afl/TEST_ASAN/xmllint_asan+0x41373a) #5 0x725290 in xmlSAX2EntityDecl (/home/lcamtuf/afl/TEST_ASAN/xmllint_asan+0x725290) #6 0x45ae8f in xmlParseEntityDecl (/home/lcamtuf/afl/TEST_ASAN/xmllint_asan+0x45ae8f) #7 0x46d437 in xmlParseMarkupDecl (/home/lcamtuf/afl/TEST_ASAN/xmllint_asan+0x46d437) #8 0x4772a3 in xmlParseInternalSubset (/home/lcamtuf/afl/TEST_ASAN/xmllint_asan+0x4772a3) #9 0x48e9b1 in xmlParseDocument (/home/lcamtuf/afl/TEST_ASAN/xmllint_asan+0x48e9b1) #10 0x4abe06 in xmlDoRead (/home/lcamtuf/afl/TEST_ASAN/xmllint_asan+0x4abe06) #11 0x4ac022 in xmlReadFile (/home/lcamtuf/afl/TEST_ASAN/xmllint_asan+0x4ac022) #12 0x40aa34 in parseAndPrintFile (/home/lcamtuf/afl/TEST_ASAN/xmllint_asan+0x40aa34) #13 0x411f43 in main (/home/lcamtuf/afl/TEST_ASAN/xmllint_asan+0x411f43) #14 0x7ffff61fcaf4 in __libc_start_main (/lib64/libc.so.6+0x21af4)
Okay, I can reproduce this, so not windows specific at all. The parser tries to cope a bit more with errors on the input and there are times, like on non terminated entities that it's preferable to stop parsing, even if that means less error reporting. I pushed 2 patches upstream to cope with the relevant errors: https://git.gnome.org/browse/libxml2/commit/?id=a7dfab7411cbf545f359dd3157e5df1eb0e7ce31 and https://git.gnome.org/browse/libxml2/commit/?id=9b8512337d14c8ddf662fcb98b0135f225a1c489 thanks ! Daniel
D'oh, sorry about the Windows tag, must have misclicked.
No problem. Looking at the document you're making an XML fuzzer and feeding libxml2, right ? Did you hit this issue early on or after a while ? Assuming I'm right, would you provide the fuzzer, I have already a bit of systemic testing in libxml2 "make check" and I toyed with the idea of a fuzzer in the past but never really had the time ! If you're into that sort of things have a look at testlimits in libxml2 code source :-) thanks, Daniel
The fuzzer is http://lcamtuf.coredump.cx/afl/ :-) It's not XML-specific, but uses a dictionary of XML syntax tokens + instrumented binaries to figure out the right way to put them together. The exact invocation is: ./afl-fuzz -i testcases/others/xml -t 10 -o out_xml -x testcases/_extras/xml ./xmllint @@ The library is compiled with: CC=/path/to/afl-gcc ./configure --disable-shared --without-threads AFL_HARDEN=1 make clean all It did take a couple of days to get to this find, so it's probably not very suitable for discrete release checks, but may be nice to run on a continuous basis.
Are you planning on getting a CVE assigned for this issue?
Is it needed to assign CVE for this issue ?
I think so. This is user input that can result in a crash (per comment #1) which makes it a potential denial of service and that is a vulnerability.
Is it still not fixed completely? It is reported again in : https://bugzilla.gnome.org/show_bug.cgi?id=756456
Daniel, CVE-2015-7941 & CVE-2015-7942 are assigned by Mitre, can you help how to proceed further?
Gaurav how can we have 2 CVEs for a single issue, please clarify, thanks, Daniel
Please see below reply by mitre: Use CVE-2015-7941 for the discussion in 744980 up to and including https://bugzilla.gnome.org/show_bug.cgi?id=744980#c7 (this includes a7dfab7411cbf545f359dd3157e5df1eb0e7ce31 and 9b8512337d14c8ddf662fcb98b0135f225a1c489). Use CVE-2015-7942 for https://bugzilla.gnome.org/show_bug.cgi?id=744980#c8 and https://bugzilla.gnome.org/show_bug.cgi?id=756456#c0 (i.e., the finding by a different person, Kostya Serebryany). CVE-2015-7942 is for https://bugzilla.gnome.org/show_bug.cgi?id=756456 Let me know if there is some doubt. Thanks, Gaurav Gupta
This CVE will Affect before 2.9.2 versions also ?