[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 27 Sep 2011 00:38:50 +0200
From: Johannes Schlüter <johannes@...lueters.de>
To: Vincent Danen <vdanen@...hat.com>
Cc: oss-security@...ts.openwall.com, Rasmus Lerdorf <rasmus@....net>, Zeev
Suraski <zeev@...d.com>, security@....net, Stas Malyshev
<smalyshev@...arcrm.com>
Subject: Re: Re: CVE request: is_a() function may allow
arbitrary code execution in PHP 5.3.7/5.3.8
On Mon, 2011-09-26 at 09:05 -0600, Vincent Danen wrote:
> * [2011-09-25 19:22:19 +0200] Pierre Joye wrote:
>
> >On Sun, Sep 25, 2011 at 6:38 PM, Rasmus Lerdorf <rasmus@....net> wrote:
> >> 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?
> >
> >Yes, and that's why it is a very very minor problem. However it was
> >not happening before the code change. The few cases where the class
> >names&co have been sanitize before and the developer did not think
> >about cases like the one describe in the blog post. I think it is even
> >more rare combination, but it was not happening before our change.
>
> Thanks for all the discussion around this.
>
> Pierre has it right... prior to the change, whether it was intended or
> not, documented or not, PHP did things a certain way and users could
> (for better or worse) rely on a certain behaviour to do "the right
> thing" (right in the context of their application, even if it is wrong
> in the context of writing good PHP code). 5.3.7 changed that, which
> left applications that used this "feature" in a vulnerable state.
The old code didn't make code secure. There was still a high chance that
an attacker might exploit such a broken __autoload() function. If there
is an security issue it is the existence of allow_url_include.
> It's unfortunate for everyone that PHP gets so many CVEs assigned to it
> for trivial little things. I look at every CVE assigned for safemode
> or open_basedir bypass flaws... technically speaking, I would never
> consider those to be flaws because those functions are not meant to be
> sandboxing features or high security features, as outlined on PHP's
> page, however they do get CVEs assigned.
>
> Even though PHP does not consider those features to be security
> protection features, CVEs are still assigned. You would expect that
> most people would not rely on those features as security features, which
> means those "bypass" flaws should never really affect people in a
> security context, but the sad reality is that they do. CVE does not
> distinguish between good programming habits or bad ones. Flaws like
> this, that are only exposed due to bad programming in applications,
> still end up with CVEs assigned at the language level.
Well, I accept most of the safe_mode things. safe_mode is a way to also
limit "bad people" with local file access. Which is a different level.
(While nowadays virtualization etc. can be used to solve that need)
johannes
> I don't think those CVEs reflect poorly on PHP -- I think most people
> who know PHP, realize that people do dumb stuff and that a language like
> PHP makes it easier to do dumb stuff.
>
> In this case, I think this particular issue is more worthy of a CVE than
> the open_basedir/safemode-related CVEs (and there are _lots_ of those).
>
> ref: http://www.php.net/security-note.php
>
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.
