Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 13 Jul 2015 19:42:24 -0500
From: Fernando Muñoz <>
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.


On Mon, Jul 13, 2015 at 4:37 PM,  <> wrote:
> 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:
>   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:
> (added 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
> 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
> 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 ]
> Version: GnuPG v1.4.14 (SunOS)
> 0gKqEsEyh1kyYsC0gJPYIPGSesMEcymL902i1vs0+hiMkkcN1oxPWNMxNDSPwaXi
> 0yJnGJCddezkkHIBhgaIr7YbDkCWhWEJGEnq5eoe7gssWuZnlGuReQXBFmaSilI8
> GLM0UX68n7jUgen5wNzivw/Yxrrur8BUwz+w09QEFQVv5HxEE6xj6O891yzeaw6g
> VowSDOzYtB7TZQHLA4lvT7Q8Ux38jdjE4v5XcHkGHdTw9mwkBk0Qi6m7ku7txsNf
> 78bZPZt8Zm6eKK3z+kdtRyY1begfOyqfWCdr8SlpRFRisCXdd1C/jiFgrKfyvg4=
> =6u7g

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ