[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEr-gPHFmE_q+2wLhMvOCsM5VJd6_3tH1L+31evHW0gnaVCQ7A@mail.gmail.com>
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
