Date: Mon, 13 Jul 2015 19:42:24 -0500 From: Fernando Muñoz <fernando@...l-life.com> To: cve-assign@...re.org Cc: oss-security@...ts.openwall.com, security@...ian.org Subject: Re: CVE Request - tidy 0.99 / tidy5 heap-buffer-overflow AFAIK Debian did not assign any. I didn't get any response when I reported it to Debian for a couple of weeks, so I went ahead and found the tidy-html5 fork, which is based on the same project and developed by the same people, reported it directly to them. After that I contacted Debian security again and they asked me to request a CVE here. Thanks. On Mon, Jul 13, 2015 at 4:37 PM, <cve-assign@...re.org> wrote: > -----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