oss-security - Re: CVE Request - tidy 0.99 / tidy5 heap-buffer-overflow

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20150713213749.9F6046C0164@smtpvmsrv1.mitre.org>
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-----

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.