CVE Request -- perl-CGI two ids, perl-CGI-Simple one id (CVE-2010-3172 already assigned for Bugzilla part)

[Jan Lieskovsky <jlieskov () redhat com>]

Hi Steve, vendors,

   Masahiro Yamada reported:
   [1] https://github.com/digg/stream/issues#issue/1
   [2] https://bugzilla.mozilla.org/show_bug.cgi?id=600464

   the following deficiency (from [2]):
   Search result of b.m.o. does not escape "--------- =_aaaaaaaaaa0": it is used
   as boudary of multipart/x-mixed-replace.

   Attackers can inject boundary of multipart/x-mixed-replace.
   It may be able to be used for HTTP Header injection.

   It has been fixed in new perl-CGI v3.50 upstream version via the following commit:
   [3] http://www2.rbfh.de/cgi/cgit.cgi/perl5.git/commit/?id=84601d63a7e34958da47dad1e61e27cb3bd467d1

   The Changelog from [3] mentions:
   [SECURITY]
    1. The MIME boundary in multipart_init is now random
       Thanks to Byron Jones, Masahiro Yamada, Reed Loden, and Mark Stosberg

    Since perl-CGi is different code base than Bugzilla, we suspect a new CVE id is required
    for this issue? Steve, could you please allocate one? (id #1)

    2. Further improvements to handling of newlines embedded in header values.
       An exception is thrown if header values contain invalid newlines.
       Thanks to Michal Zalewski, Max Kanat-Alexander, Yanick Champoux
       Lincoln Stein, Frederic Buclin and Mark Stosberg

       Chris, Mark, could you please provide more details about the issue? Is it
       related to CVE-2010-3172?

       Steve, could you please allocate CVE id for this? (id #2)

  Yet, back to CVE-2010-3172, Masahiro mentions in [2], that perl-CGI-Simple is prone
  to same deficiency, as CVE-2010-3172 in Bugzilla was:
  [4] https://bugzilla.mozilla.org/show_bug.cgi?id=600464#c13

  Looks, like it was already fixed in perl-CGI-Simple too:
  [5] https://bugzilla.mozilla.org/show_bug.cgi?id=600464#c31

  Relevant perl-CGi-Simple patch:
  [6] https://github.com/AndyA/CGI--Simple/commit/e4942b871a26c1317a175a91ebb7262eea59b380

  Steve, could you allocate new CVE id for this issue? (id #3)

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