Bug 1228297 (CVE-2015-5522, CVE-2015-5523) - CVE-2015-5522 CVE-2015-5523 tidy: heap buffer overflow in ParseValue()
Summary: CVE-2015-5522 CVE-2015-5523 tidy: heap buffer overflow in ParseValue()
Alias: CVE-2015-5522, CVE-2015-5523
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 1228298 1228299
Blocks: 1228300
TreeView+ depends on / blocked
Reported: 2015-06-04 14:47 UTC by Vasyl Kaigorodov
Modified: 2021-06-11 21:04 UTC (History)
5 users (show)

Fixed In Version: Tidy 4.9.31
Doc Type: Bug Fix
Doc Text:
It was discovered that tidy did not properly process certain character sequences. By tricking an application that is using tidy into processing a specially crafted HTML document, a remote attacker could exploit this flaw to cause a crash or, possibly, execute arbitrary code with the privileges of the affected application.
Clone Of:
Last Closed: 2021-06-11 21:04:12 UTC

Attachments (Terms of Use)

Description Vasyl Kaigorodov 2015-06-04 14:47:37 UTC
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:

$ printf "\x3c\x61\x20\x62\x3d\x3c\x61\x20\x3c\x3f\x78\x6d
\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
allocated by thread T0 here:
    #0 0xb72af18c in __interceptor_malloc
    #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

Comment 1 Vasyl Kaigorodov 2015-06-04 14:48:39 UTC
Created tidy tracking bugs for this issue:

Affects: fedora-all [bug 1228298]
Affects: epel-all [bug 1228299]

Comment 2 Stefan Cornelius 2015-06-17 11:06:19 UTC
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.

Comment 3 Stefan Cornelius 2015-06-17 11:12:32 UTC

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/.

Comment 4 Vasyl Kaigorodov 2015-07-15 15:34:21 UTC
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.

Comment 5 Product Security DevOps Team 2021-06-11 21:04:12 UTC
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):


Note You need to log in before you can comment on or make changes to this bug.