GNOME Bugzilla – Bug 751631
xmlParseXMLDecl: out of bounds heap read on 0xff char in xml declaration
Last modified: 2015-11-21 04:30:00 UTC
Created attachment 306264 [details] sample input causing oob The attached file will cause an out of bounds read access in libxml2. Can be tested by compiling with address sanitizer (-fsanitize=address) and using xmllint. Found with american fuzzy lop on latest git and 2.9.2. This looks similar to #751603 but it is a different issue (and still happens on latest git with the fix for that bug attached). The file contains an unfinished xml declaration (<?xml versionencoding="ISO88598") followed by a 0xff byte. Address Sanitizer stack trace (on git head code): ==2538==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62100001c900 at pc 0x00000059a6d9 bp 0x7ffdbe003260 sp 0x7ffdbe003258 READ of size 1 at 0x62100001c900 thread T0 #0 0x59a6d8 in xmlParseXMLDecl /f/libxml2/parser.c:10678:2 #1 0x59b801 in xmlParseDocument /f/libxml2/parser.c:10783:2 #2 0x5bed44 in xmlDoRead /f/libxml2/parser.c:15307:5 #3 0x5beff6 in xmlReadFile /f/libxml2/parser.c:15369:13 #4 0x50114d in parseAndPrintFile /f/libxml2/xmllint.c:2401:9 #5 0x4f8c0f in main /f/libxml2/xmllint.c:3759:7 #6 0x7fcf5cae4f9f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.20-r2/work/glibc-2.20/csu/libc-start.c:289 #7 0x44cd26 in _start (/mnt/ram/xml/xmllint+0x44cd26) 0x62100001c900 is located 0 bytes to the right of 4096-byte region [0x62100001b900,0x62100001c900) allocated by thread T0 here: #0 0x4d3cf2 in malloc (/mnt/ram/xml/xmllint+0x4d3cf2) #1 0x7c5c10 in xmlBufCreate /f/libxml2/buf.c:137:32 SUMMARY: AddressSanitizer: heap-buffer-overflow /f/libxml2/parser.c:10678 xmlParseXMLDecl Shadow bytes around the buggy address: 0x0c427fffb8d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c427fffb8e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c427fffb8f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c427fffb900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c427fffb910: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0c427fffb920:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c427fffb930: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c427fffb940: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c427fffb950: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c427fffb960: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c427fffb970: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==2538==ABORTING
Okay, also unrelated to the version string brokeness as thinkpad:~/XML -> cat libxml2-oob-heap-xmlParseXMLDecl-2-1.xml <?xml version="1.0" encoding="ISO88598"� thinkpad:~/XML -> exhibit the same problem. Simplest is that if encoding conversion failed while we convert the beginning of the buffer while processing the encoding declaration then aborting there is the safest thing to do. Fixed in git: https://git.gnome.org/browse/libxml2/commit/?id=709a952110e98621c9b78c4f26462a9d8333102e thanks for the report ! Daniel
Shall we raise CVE request for this bug ?
Does it crash for the user, i.e. with a normal compiled version, not for me at least with provided reproducer and gcc: thinkpad2:~ -> /usr/bin/xmllint libxml2-oob-heap-xmlParseXMLDecl-2.xml libxml2-oob-heap-xmlParseXMLDecl-2.xml:1: parser error : expected '=' <?xml versionencoding="ISO88598"� ^ libxml2-oob-heap-xmlParseXMLDecl-2.xml:1: parser error : Malformed declaration expecting version <?xml versionencoding="ISO88598"� ^ libxml2-oob-heap-xmlParseXMLDecl-2.xml:1: parser error : Blank needed here <?xml versionencoding="ISO88598"� ^ encoding error : input conversion failed due to input error, bytes 0xFF 0x00 0x78 0x6D libxml2-oob-heap-xmlParseXMLDecl-2.xml:1: parser error : switching encoding: encoder error � ^ libxml2-oob-heap-xmlParseXMLDecl-2.xml:1: parser error : Blank needed here � ^ encoding error : input conversion failed due to input error, bytes 0xFF 0x00 0x78 0x6D I/O error : encoder error libxml2-oob-heap-xmlParseXMLDecl-2.xml:1: parser error : parsing XML declaration: '?>' expected ^ libxml2-oob-heap-xmlParseXMLDecl-2.xml:1: parser error : internal error: Huge input lookup ^ thinkpad2:~ -> So for me there is no need for a CVE, where is the vulnerability if there is no exploit ? Daniel
Based on my experience it's been the policy of the CVE-assigners to consider out of bounds reads in libraries always to be CVE-worthy, because they could be vulns (e.g. through leaking memory to an attacker), even if there's no described exploit scenario. One may argue if that makes sense (my personal take on this has been lately that I care much less about what's CVE-worthy or not than I care about getting things fixed). What I'd find more important than the question whether this should get a CVE is whether we can have a new release that will ship the fix for this issue soon (and a couple of similar bugs that have been reported lately).
I will try to get a release real soon, but there are more bugs under embargo Daniel
So part of 2.9.3 upstream release, people as seriously invited to update considering the number of CVEs and bugs fixed Daniel