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

30 comments

  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 Anonymous Coward · · Score: 0

      WRONG!

      It is exploitable through register_globals functionality. This makes it exploitable nearly everywhere...

      And the session extension is also nearly everywhere used...

    2. Re:not exploitable everywhere? by Anonymous Coward · · Score: 0

      Geez, I hope PHP 4.1.2 isn't vulnerable to this or I may have to seriously think about moving away from my Cobalt RaQ 4r's for hosting since Sun no longer offers security updates. Damn.

    3. 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. I don't know about you guys... by Anonymous Coward · · Score: 0

    But I have never believed a security vulnerability unless they release a proof-of-concept, or at least a 10-15 page white paper on how the exploit is done so that people can actually verify it for themselves. If admins can see that that real damage is done, first hand, it will make them that much more likely to upgrade.

    1. Re:I don't know about you guys... by Anonymous Coward · · Score: 0

      There is a cure for your problem.

      Do not believe it and cry later when you got 0wned.

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

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

    2. Re:what does this cover? by Anonymous Coward · · Score: 0

      I thought --enable-inline-optimization was now a default? I admit I pass the switch to configure anyway. APC is pretty good for acceleration with PHP4, you can find it in PECL.

  6. 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 Anonymous Coward · · Score: 0
      We've all done that ;-) These are my current settings, somebody correct me if this is wrong, this leaves us open to DOS but both our web servers are due to be swapped out tommorow anyway.
      max_execution_time = 2 ; our scripts are much faster
      max_input_time = 2 ; sucks to be on dialup
      memory_limit = 0 ; default is 8MB, set to 0 to disable

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

  8. perl by sporty · · Score: 0, Troll

    Too bad you (proverbial you) weren't using perl. A bit more mature and all..

    --

    -
    ping -f 255.255.255.255 # if only

    1. Re:perl by Anonymous Coward · · Score: 0

      That's just swell, too bad you (actually you) aren't using COBOL. A bit more mature and all.

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

  10. 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*

    2. Re:OSS elitism by Anonymous Coward · · Score: 0

      I'd found out here and made config changes before the advisory hit my mailserver (via bugtraq). It should have still been frontpage, people have definately missed this.

  11. 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.
  12. WTF? by Anonymous Coward · · Score: 0

    For an advisory that is 2 days old, if it's as serious as it SOUNDS there seems little action on it.

    For example redhat up2date shows nothing new. Nor do most other sites with packages for apache/php.

    I'm not even clear if I'm vulnerable or not on a Solaris host that has Apache with mod_php.

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