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

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