Date: Mon, 13 Jul 2015 17:37:49 -0400 (EDT) From: cve-assign@...re.org To: fernando@...l-life.com Cc: cve-assign@...re.org, oss-security@...ts.openwall.com, security@...ian.org Subject: Re: CVE Request - tidy 0.99 / tidy5 heap-buffer-overflow -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 One complication here is that the CVE request was sent to oss-security without mentioning that a CVE request had been sent privately to one Linux distribution a few weeks before that. See: https://github.com/htacg/tidy-html5/issues/217#issue-84488886 I contacted Debian about the issue on May 17, so far I have not received a response about a CVE assignment. ... Date: Sun, May 17, 2015 at 8:11 PM Subject: tidy heap-buffer-overflow To: security@...ian.org (added security@...ian.org to the Cc line) Our only question for Debian is: did Debian already assign any CVE ID(s) for this? If not, then MITRE will. (To clarify: we're definitely not suggesting that Debian did something wrong. At least from MITRE's perspective, Debian isn't required to process CVE requests in arbitrary private reports about software shipped by Debian, and especially not in cases where the report is about code that's also shipped by the upstream author. The only issue is that Debian is allowed to process the CVE request if they want to. In that situation, they can choose the public disclosure date, and MITRE should/would typically not be informed about the vulnerability or its CVE ID before the public disclosure date. Probably none of this caused any significant problem in the current case. However, in general, the existence of a previous CVE request is important.) Now, going back to the vulnerability report itself: we think two CVE IDs might be best. The original discovery was about memory corruption, and then the vendor mentioned an attack variation in which a small file can lead to a 4 Gb allocation, which potentially would be successful on some platform and cause a DoS. In other words, the first CVE would be for https://github.com/htacg/tidy-html5/issues/217 with: AddressSanitizer: heap-buffer-overflow WRITE of size 1 tmbstr cp = s = (tmbstr) TidyAlloc( allocator, 1+len ); Notice the plus 1, so it arrives at TidyAlloc with a ZERO!!! Now it seems malloc does not mind a zero value, malloc(0), and dutifully returns a pointer Then tmbstrndup does the corruption, with - while ( len-- > 0 && (*cp++ = *str++) ) /**/; Of course ( len-- > 0 ) will be true until the 4294967295 expires ;=)) But thankfully the corruption stops when a 0 is reached in the lexer with (*cp++ = *str++). As indicated in this case it is storing the attribute "href", but that is 4+ bytes of corruption. The second CVE would be for https://github.com/htacg/tidy-html5/issues/217#issuecomment-108565501 with: 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 We'll try to send these CVE IDs tomorrow if there's no other information and no duplication. - -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington Road, Bedford, MA 01730 USA [ PGP key available through http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (SunOS) iQEcBAEBAgAGBQJVpC8NAAoJEKllVAevmvmsePwIAK9BAACprS1lfeOqHqbJ1xAb 0gKqEsEyh1kyYsC0gJPYIPGSesMEcymL902i1vs0+hiMkkcN1oxPWNMxNDSPwaXi 0yJnGJCddezkkHIBhgaIr7YbDkCWhWEJGEnq5eoe7gssWuZnlGuReQXBFmaSilI8 GLM0UX68n7jUgen5wNzivw/Yxrrur8BUwz+w09QEFQVv5HxEE6xj6O891yzeaw6g VowSDOzYtB7TZQHLA4lvT7Q8Ux38jdjE4v5XcHkGHdTw9mwkBk0Qi6m7ku7txsNf 78bZPZt8Zm6eKK3z+kdtRyY1begfOyqfWCdr8SlpRFRisCXdd1C/jiFgrKfyvg4= =6u7g -----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ