Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 13 Jul 2015 17:37:49 -0400 (EDT)
Subject: Re: CVE Request - tidy 0.99 / tidy5 heap-buffer-overflow

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

(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

  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)


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.