Re: Remote exploit in Gallery 1.3.1, 1.3.2, 1.3.3, 1.4 and 1.4.1

[Matus UHLAR - fantomas <uhlar () fantomas sk>]

This mail is meaned to blame, not to flame...

On 27.01 14:29, Bharat Mediratta wrote:
> Starting in release 1.3.1, Gallery includes code to simulate the
> behaviour of register_globals in environments where that setting
> is disabled.  We do this by extracting the values of the various
> $HTTP_ global variables into the global namespace.  We check
> for the presence of certain types of malicious data before doing
> this, but our checks are inadequate.

According to PHP documentation
(http://www.php.net/manual/en/security.registerglobals.php) the
register_globals variable now defaults to off because of security reasons.

I can't understand, why, instead of fixing scripts not to use that feature
and thus to be more secure, should anyone try to emulate that unsafe
option by script (and possibly make it even more insecure, as it was
exactly done). That seems absurd and non-sense to me:

"Argh! They removed a thing it because it's unsecure. Let's get it back..."

> A clever hacker can circumvent our checks by crafting a URL like
> this:
>
>     http://example.com/gallery/init.php?HTTP_POST_VARS=xxx
>
> this causes our register_global simulation code to overwrite
> the HTTP_POST_VARS which, when it in turn is extracted will
> deliver the payload.  If the payload compromises $GALLERY_BASEDIR
> then the malicious user can perform a PHP injection exploit and
> gain remote access to your box as the webserver/PHP user id.

I hope that PHP coders will have their lesson now.

-- 
Matus UHLAR - fantomas, uhlar () fantomas sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Linux - It's now safe to turn on your computer.
Linux - Teraz mozete pocitac bez obav zapnut.