[pmwiki-users] pmwiki exploit

[Patrick R. Michaud]

On Wed, Sep 06, 2006 at 05:38:09PM +0530, V.Krishn wrote:
> On Wednesday 06 September 2006 14:47, Thomas -Balu- Walter wrote:
> > On Wed, Sep 06, 2006 at 01:26:39PM +0530, V.Krishn wrote:
> > > >     php_flag register_globals off
> > >
> > > Thanks for the warnings.
> > > Its amazing how my webspace provider had left this variable on. If I am
> > > not mistaken this variable got to be off by default in PHP 4.2 and above.
> >
> > There are still a lot of applications that need to have this on. So most
> > providers enable it...

If I were a provider, I'd seriously consider simply turning
register_globals off globally and then selectively turning it on
for those applications that need it.

I've always known that register_globals is a very bad thing, but 
this latest exploit shows just how fragile things can be when it's
enabled.  In PmWiki's case, PmWiki has always known of the danger of
register_globals, and so one of the very first things PmWiki does is
to check if register_globals is enabled and then explicitly unset()
any variables that register_globals might have set.  (This technique
is described in the PHP FAQ [1].)

Unfortunately, there's a bug in many versions of PHP/Zend where
an attacker can send a specific query string that will cause PHP's
internal unset() function to fail.  As a result, PmWiki's efforts
to use unset() to undo the effects of register_globals are
circumvented, and an attacker gets access to the $FarmD variable
and can use it to run arbitrary scripts.

PmWiki 2.1.21 closes this particular vulnerability, but I'll
be adding even more countermeasures around it in future versions.
It *never* occurred to me that PHP's unset() function might not work.  :-|

> I guess so, but I think the best way would be each application has its 
> required settings in their own .htaccess at its root folder. I might be 
> mistaken,  or is it that the server is still at risk if only one application 
> is secured?

With a bug like this one, if any application on the server can be 
exploited then the whole server is essentially at risk.

Pm

References:
1.  http://us2.php.net/manual/en/faq.misc.php#faq.misc.registerglobals