PHP 4.3.8 Released, Fixing Remote Security Hole

christian klink writes "While it was already reported on Slashdot, that PHP5 was released, it was not mentioned that the PHP developers have also announced the release of PHP 4.3.8 which is supposed to fix a major remote security hole in nearly all PHP installations. Additionally this new version adds a workaround for another Internet Explorer bug. The bugs were found by security specialist Stefan Esser of e-matters who is also a member of the PHP developers."

Not frontpage?

[Anonymous Coward]

A remote vulnerability that affects about 50% of all Apache servers world wide and not frontpage?

not exploitable everywhere?

[brlewis]

It sounds like this hole cannot be exploited unless you've enabled certain extensions. I'm actually no longer using a host where PHP is turned on...never used PHP itself. Now I'm on Jetty with a UML host. Just curious about the hole...is my assessment correct?

One of such places is f.e. within the fileupload code, but is only triggerable on Apache 2 servers that are vulnerable to CAN-2004-0493, another one is only reachable if variables_order was changed to have the "E" in the end, a third one is within session extension which is activated by default but the vulnerability can not be triggered if the session functionality is not used. A fourth place is within the implementation of the register_globals functionality. Although this is deactivated by default since PHP 4.2 it is activated on nearly all servers that have to ensure compatibility with older scripts. Other places might exist in not default activated or 3rd party extensions.

Re:not exploitable everywhere?

[Inominate]

register_globals is almost always on, except for small sites with all recently developed code.

And sessions are also very commonly used.

Basicly everyone who uses PHP uses one if not both of these.

Temporary solution?

[ptaff]

A temporary workaround (while distributions update their packages) is to disable the memory_limit parameter. Though it can bring other weaknesses on a server (DoS by memory exhaustion), it's a lesser pain than remote code execution.

what does this cover?

[mabu]

I am under the impression this vulnerability only affects Apache 2.x? So 1.3.x tree is safe?

Are there PHP config options to address this scenario?

Re:what does this cover?

[xeer]

No, apache 1.3 sites are vulnerable, but you can protect yourself from the memory limit problem temporarily by disabling it as suggested above.

As people are going to be recompiling PHP it's probably timely to recommend the "--enable-inline-optimization" switch which should be passed to the configure script. More to be found here [phplens.com] Oh, and get yourself an accelerator. I use PHP Accelerator [php-accelerator.co.uk] although it's not open sourse unfortunately.

Secure yourself with this...

[apachetoolbox]

Add "expose_php=Off" to your php.ini file. Then update mod_php when you can.

Re:Secure yourself with this...

[Anonymous Coward]

What does that have to do with anything? Do IIS worms check to see what httpd you're running before delivering the payload?

I turned off memory_limit and set max_execution to 2 seconds for our sites but this still leaves us open to DOS attack (entire server is being swapped out for one running PHP5 - tommorow). We are a special case, everybody else should patch ASAP.

This is a serious hole, please don't give out incorrect information.

Re:Secure yourself with this...

[apachetoolbox]

i completely misread the advisory

Re:Secure yourself with this...

[MadAhab]

What does that have to do with anything? Do IIS worms check to see what httpd you're running before delivering the payload?

HHOS. That poster's advice is like saying "Since car thieves like your radio so much, put a sign on your car saying 'No radio'."

Mac OS X / Marc Liyanage distribution

[jpkunst]

As far as I can tell, the popular PHP distribution from Marc Liyanage for Mac OS X [entropy.ch] (still at version 4.3.6) is not vulnerable: it seems to be compiled without memory_limit support. ini_get_all() does not return a value for memory_limit, and memory_get_usage() returns Fatal error: Call to undefined function: memory_get_usage().

I haven't tested the built-in Mac OS X php version.

JP

Disappointed

[macdaddy]

I'm extremely disappointed with the Slashdot editors not putting this article on the main page. This is a critical security hole in a very common tool, even increasing common [netcraft.com] on Windows machines. Why was this not on the main page, Slashdot Editors?

Re:Disappointed

[coyote4til7]

Showed up for me when I went to the main slashdot page. Maybe you need to adjust your preferences?

Re:Disappointed

[macdaddy]

I'm running with the default settings on Slashdot. That means that no authors, topics or sections are excluded from from the homepage. I also have default Slashdot Slashboxes. That doesn't really matter though because this critical security hole should have made the main page on the default settings. I don't see a check box in the prefs for "Show me critical security vulnerabilities that everyone should know about."

Re:Disappointed

[gad_zuki!]

Its not on the main page if you are using default settings, but this is:

Ballmer - Xbox 'Can Take Sony' In Next Generation

And the Atak worm.

sigh

OSS elitism

[gad_zuki!]

That's what it is. Every MS hole gets on the front page and rightly so, but something like half the PHP installations world-wide are at risk and slashdot buries it?

I use linux too, like most people here, and would have really appreciated seeing this earlier.

Re:OSS elitism

[macdaddy]

Quite possibly. Still though they usually post the more damning Linux vulnerabilities too. Wasn't there a root sploit in the kernel a while back that made the front page? I don't know why they didn't bother reporting this one. Sucks though. Good thing I let Freshmeat mail me when PHP (a project I subscribed to) gets updated. Joining the PHP mailing lists is utterly useless. They are over run with spam and either not administrated at all or are administrated by incompotent boobs. The announcement lis

Hype?

[bobsledbob]

For such a large security hole, why isn't php.net placing more emphasis on upgrading? The way e-matters.de makes it out, it would be simple to craft an attack. But, all I find on the 4.3.8 is:

* Fixed strip_tags() to correctly handle '\0' characters. (Stefan)
* Improved stability during startup when memory_limit is used. (Stefan)
* Replace alloca() with emalloc() for better stack protection. (Ilia)
* Added missing safe_mode checks inside ftok and itpc. (Ilia)
* Fixed bug #28963 Fixed address all

Re:Hype?

[Anonymous Coward]

PHP Development Team would like to announce the immediate availability of PHP 4.3.8. This release is made in response to several security issues that have been discovered since the 4.3.7 release. All users of PHP are strongly encouraged to upgrade to PHP 4.3.8 as soon as possible.

I suggest that you learn to read.

Additionally Stefan Esser from e-matters is one of the PHP Developers and one of their securiy team members, so he is the source itself.

Hardened PHP

[apachetoolbox]

http://www.hardened-php.net/

Written by the same guy that discovered the php4 exploit, he's also a php developer.