[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEZPtU5smwcEAhWaBXx=Za7yJuGpK4gEwvanoC_7uEP7OfOUkw@mail.gmail.com>
Date: Sun, 25 Sep 2011 16:10:12 +0200
From: Pierre Joye <pierre.php@...il.com>
To: Zeev Suraski <zeev@...d.com>
Cc: Vincent Danen <vdanen@...hat.com>,
"oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>, "security@....net" <security@....net>,
Stas Malyshev <smalyshev@...arcrm.com>
Subject: Re: CVE request: is_a() function may allow arbitrary code execution
in PHP 5.3.7/5.3.8
On Sun, Sep 25, 2011 at 3:47 PM, Zeev Suraski <zeev@...d.com> wrote:
> There aren't any security issues in PHP in that context. Assigning a CVE to PHP in that context would create the impression that there is indeed an issue in PHP here.
> It's not a matter of who's 'guilty' in terms of positioning - but in terms of where the actual security issue resides. And it does not reside in PHP.
>
> So I agree with Stas, it doesn't make sense to have a CVE here. Otherwise, almost every change we make, including bug fixes, could somehow result in some faulty piece of code somewhere becoming vulnerable to something.
The whole point is that some code was not having any issue before this
change. If the check was done earlier using is_a then this unexpected
behavior will happen, and that actually causes a security issue in
existing working code. The example in the blog post is very good one,
it clearly shows that the impact on existing code is not only about
wrongly implemented autoloader, or someone not disabling
allow_url_fopen (I can imagine local file include being an issue as
well under some circumstances).
All in all, there is no shame or bad image to get a new CVE for
something like that, I even see it as a good thing as it will:
1. clearly explain the is_a issue and how it can impact existing code
(with the hope that our users will review/fix their code)
2. bring to the light again some good practices
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
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.
