Slashdot Mirror

← Back to Stories (view on slashdot.org)

PHP 4.3.8 Released, Fixing Remote Security Hole

Posted by timothy on from the constant-progress dept.

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."

20 of 30 comments (clear)

  1. Not frontpage? by Anonymous Coward · · Score: 3, Insightful

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

  2. not exploitable everywhere? by brlewis · · Score: 2, Interesting
    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.
    1. Re:not exploitable everywhere? by Inominate · · Score: 3, Informative

      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.

  3. Temporary solution? by ptaff · · Score: 2, Informative

    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.

  4. what does this cover? by mabu · · Score: 2

    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?

    1. Re:what does this cover? by xeer · · Score: 3, Informative

      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 Oh, and get yourself an accelerator. I use PHP Accelerator although it's not open sourse unfortunately.

  5. Secure yourself with this... by apachetoolbox · · Score: 1

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

    1. Re:Secure yourself with this... by Anonymous Coward · · Score: 1, Informative

      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.

    2. Re:Secure yourself with this... by apachetoolbox · · Score: 1

      i completely misread the advisory

    3. Re:Secure yourself with this... by MadAhab · · Score: 1
      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'."

      --
      Expanding a vast wasteland since 1996.
  6. Mac OS X / Marc Liyanage distribution by jpkunst · · Score: 1

    As far as I can tell, the popular PHP distribution from Marc Liyanage for Mac OS X (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

  7. Disappointed by macdaddy · · Score: 1, Redundant

    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 on Windows machines. Why was this not on the main page, Slashdot Editors?

    1. Re:Disappointed by coyote4til7 · · Score: 1

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

      --

      the clock on the wall says 4 til 7
    2. Re:Disappointed by macdaddy · · Score: 1

      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."

    3. Re:Disappointed by gad_zuki! · · Score: 1

      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

  8. OSS elitism by gad_zuki! · · Score: 1

    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.

    1. Re:OSS elitism by macdaddy · · Score: 1

      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 list can (and is!) posted to by anyone including spammers. Genius in action I tell you. They also ignore complaints to postmaster. *sigh*

  9. Hype? by bobsledbob · · Score: 1
    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 allocation routine in IMAP extension. (Ilia)
    * Fixed bug #28632 Prevent open_basedir bypass via MySQL's LOAD DATA LOCAL. (Ilia)
    If this is a big deal, I'd like to know from the source itself. Otherwise, it makes me question of e-matters isn't making it out to be worse than it is.

    --
    Beware of geeks bearing formulas.
    1. Re:Hype? by Anonymous Coward · · Score: 1, Informative
      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.
  10. Hardened PHP by apachetoolbox · · Score: 1

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

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