Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20141011215942.638773AE013@smtpvbsrv1.mitre.org>
Date: Sat, 11 Oct 2014 17:59:42 -0400 (EDT)
From: cve-assign@...re.org
To: siddharth@...hat.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: Request for CVE assignment for tigervnc affected by similar flaws as in CVE-2014-6051 and CVE-2014-6052 of libvncserver

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> I would want to get different CVE's assigned for tigervnc as it is
> affected by similar flaws of libvncserver ( CVE-2014-6051 and
> CVE-2014-6052 ).
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1151307
> https://bugzilla.redhat.com/show_bug.cgi?id=1151312

First, in general, when asking for a CVE assignment for an issue
"similar" to an existing CVE, it is very useful to provide an
additional statement or reference indicating why the issue should not
be mapped to the existing CVE. A difference in the product name does
not always require a separate CVE.

In this case, 1151307 is noted as similar to CVE-2014-6051.
CVE-2014-6051 is a frequently seen type of mistake (width * height
leads to integer overflow) and it's entirely plausible that this
mistake would occur independently in different codebases that have
related purposes.

Use CVE-2014-8240 for 1151307.


Also, 1151312 is noted as similar to CVE-2014-6052. CVE-2014-6052 is a
frequently seen type of mistake: essentially, there's a number that
can be sent in a manner compatible with a protocol specification, and
the number might even be sensible in an environment with huge
resources, but the number is used for a malloc argument without
checking whether malloc succeeds. (In other words, it's not
necessarily worthwhile to validate the number before calling malloc.)
It's entirely plausible that this mistake would occur independently in
different codebases that have related purposes.

Use CVE-2014-8241 for 1151312.


MITRE didn't try to find the specific vulnerable TigerVNC code in an
attempt to prove that that code wasn't a derivative of LibVNCServer.
We happened to notice a piece of code that may or may not be related
to CVE-2014-8241, and decided that it didn't look like a derivative.
Specifically:

  https://github.com/TigerVNC/tigervnc/blob/d1a853bca7a70467915b3759aa9de5e63a5e8edb/vncviewer/X11PixelBuffer.cxx#L109

    xim->data = (char*)malloc(xim->bytes_per_line * xim->height);
    if (!xim->data)
      throw rfb::Exception(_("Not enough memory for framebuffer"));

looks different from:

  https://github.com/newsoft/libvncserver/commit/85a778c0e45e87e35ee7199f1f25020648e8b812

- -- 
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)

iQEcBAEBAgAGBQJUOaflAAoJEKllVAevmvmsOGkIAJ9vhzofyFb6Sw8taa8+4j7X
chPwQrbtDDXzGCd+VDW6Khf2juw8PZgSCKSpoXU8foQLRiWTTxyoEX092g8Cne9m
69/f4EuT203AAsUo7IoBviJtRDi+lG9LqTr5VPgXhGShux/4QtTsET/Ad6a7veXX
MibDxzS9mkyNs9rxu6gwYYVsSvsRRbIxA4pSIj/Jl3GMdeyyI8AcF9tA5NNGn7og
uzRhtllCnaybov4as3gm2m8xz7S3CcawJmW63J8Wl3Knj8zZcL7S1G2lPT7dUmlm
7hmunL9l74txt+Ik0M/r8VyGHDMHjkM6hLmnbnbOS0gYzRNH4JTNb/afBYWhiEM=
=5TIi
-----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.