Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Thu, 20 May 2010 18:26:26 +0200
From: Jan Lieskovsky <>
To: "Steven M. Christey" <>,
        oss-security <>
CC: Tim Bunce <>, Rafael Garcia-Suarez <>,
        Tom Lane <>
Subject: CVE-2010-1974 reject request (dupe of CVE-2010-1168) and CVE-2010-1447
 description modification request

Hi Steve,

   this is due:

     a, [1]

        This is duplicate CVE identifier for the Perl module flaw,
        CVE-2010-1168 identifier has been originally assigned to:


     b, [3]

        The description of this incorrectly states, it's PostgreSQL issue, but the true
        source code base, responsible for this deficiency is Perl's
        implementation. The source of this confusion is:

Attached are advisories from my original posts to vendor-sec channel for all four issues:
i, CVE-2010-1168 Perl's 2.25 and below deficiency, when handling
    implicit methods:

ii, CVE-2010-1169 PostgreSQL's PL/Perl deficiency, present due dependency / use of
     Perl's extension module:

iii, CVE-2010-1170 PostgreSQL's PL/Tcl deficiency by handling autoload():

iv, CVE-2010-1447 Perl's 2.27 and below deficiency (see attached archive for
     more information)

Flaw history:
   1, Red Hat Security Response Team has been notified on 2010-03-18 with the details
      of this issue. Later CVE-2010-1168 has been assigned to this (but in that moment
      wasn't aware Rafael did already pseudo-published flaw details on his blog:
   2, Later Tim Bunce identified similar deficiency in PostgreSQL's PL/Perl implementation.
      CVE-2010-1169 identifier has been assigned to this:

   3, Later Tom Lane identified similar deficiency in PostgreSQL's PL/Tcl implementation -- this
      is what CVE-2010-1170 has been assigned for:

   4, And finally, Tim Bunce and Rafael Garcia-Suarez recognized a yet another deficiency
      in Perl's implementation, allowing to bypass the Perl's Safe compartment constrains,
      by evaluation of unsafe code, returning returning references to subroutines, whose truly
      execution was delayed to happen later, outside of the Safe compartment.

Have checked today with Tim, there isn't any new perl extension module issue (besides CVE-2010-1168
and CVE-2010-1447 cases), which would desire a new CVE id (CVE-2010-1974 is dupe of CVE-2010-1168).

Steve, could you please:
   a, reject CVE-2010-1974 ( as a duplicate
      CVE identifier for CVE-2010-1168 and,
   b, update description of CVE-2010-1447 (
      so it would reflect the true reason of the flaw, it was originally assigned for.

Hope this clarification is sufficient. In case of any doubt / need of further background information,
related with above four issues, please ask.

Thanks && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Response Team

P.S.: Re-sending the message again, this time without patches, as first time the post exceeded the
       limit for maximum size of the msg accepted by OSS mailer. Apologize to people in the Cc-list
       for the unintended spam :(.

View attachment "CVE-2010-1168-advisory.txt" of type "text/plain" (2297 bytes)

View attachment "CVE-2010-1169-advisory.txt" of type "text/plain" (1700 bytes)

View attachment "CVE-2010-1170-advisory.txt" of type "text/plain" (1372 bytes)

View attachment "CVE-2010-1447_advisory.txt" of type "text/plain" (2462 bytes)

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.