Re: CVE request: is_a() function may allow arbitrary code execution in PHP 5.3.7/5.3.8

[Rasmus Lerdorf <rasmus () php net>]

On 09/25/2011 04:10 PM, Pierre Joye wrote:
> On Sun, Sep 25, 2011 at 3:47 PM, Zeev Suraski <zeev () zend 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:

I didn't read the thread from the beginning, but is there an actual
exploit here? Presumably the autoloader code in question isn't doing an
fopen/eval to execute the code and since allow_url_include is disabled
by default, remote includes aren't an issue in the default install. So
are we talking about the tiny number of people who have explicitly
enabled allow_url_include and are running the code with this bad autoloader?

-Rasmus