@(#)Mordred Labs advisory - Integer overflow in PHP str_repeat() function

[Sir Mordred]

//@(#) Mordred Security Labs advisory

Release date: April 1, 2003
Name: Integer overflow in PHP str_repeat() function
Versions affected: all versions
Risk: average
Author: Sir Mordred (mordred@s-mail.com)

I. Description:

PHP is a widely-used general-purpose scripting language that is
especially suited for Web development and can be embedded into HTML.
Please visit http://www.php.net for more information about PHP.

II. Details:

The function str_repeat(string input, int multiplier) returns input
repeated multiplier times.

The implementation of this function suffers from a simple integer overflow
caused by
a very long second argument and could allow a local/remote attacker in the
worst case to gain control over the web server.

The following short script will illustrate this vulnerability:

$ cat t.php
<?php
str_repeat(str_repeat("A", 0x2000), 0x40000000);
?>

III. Platforms tested

Linux 2.4 with Apache 1.3.27 / PHP 4.3.1

IV. Vendor response

Vendor has been contacted.


__________________________________________________ ______________________
This letter has been delivered unencrypted. We'd like to remind you that
the full protection of e-mail correspondence is provided by S-mail
encryption mechanisms if only both, Sender and Recipient use S-mail.
Register at S-mail.com: http://www.s-mail.com

[Jedi/Sector One]

On Thu, Apr 03, 2003 at 08:39:03AM +0200, Goran Krajnovic wrote:
> This is a bit pointless, IMHO. 99% of PHP installations run the PHP code with
> the user-id of the web server process (usually a low privilege user like
> 'nobody' or 'apache').
[snip snip]
> If an attacker has the opportunity to execude PHP code of his choice on a
> target server [1], he does not need to exploit a buffer overflow in PHP just to
> get the privileges of the web server user

You missed an important point.

Hosting services offering a PHP interpreter to untrusted people rely on
PHP features to restrict their field of action.

Specifically, the open_basedir and safe_mode features are a must to avoid
people going outside their home directory with PHP scripts.

If arbitrary code can be run through a PHP vulnerability, these
restrictions disappear. People can walk through files that are supposed to
be inaccessible.

Given that many people just chmod -R 777 their directories when their
script doesn't work and leave plaintext SQL passwords everywhere, this is
definitely ann issue.

Also don't forget that all PHP extensions aren't always enabled. For
instance, the socket extension is typically disabled by most hosting service
providers for obvious reasons.

Once and again, a vulnerability in the PHP interpreter can bypass this
restriction and gain access to other machines of the LAN, run DOS agents, etc.

Of course, one shouldn't rely 100% on PHP userland security barriers, this
is where tools like NetBSD/OpenBSD's systrace can really add another
efficient layer of security.

--
__ /*- Frank DENIS (Jedi/Sector One) <j@42-Networks.Com> -*\ __
\ '/ <a href="http://www.PureFTPd.Org/"> Secure FTP Server </a> \' /
\/ <a href="http://www.Jedi.Claranet.Fr/"> Misc. free software </a> \/

[Jon Ribbens]

Javi Lavandeira <javi@isr.co.jp> wrote:
> You seem to be forgetting about PHP's safe_mode, disable_functions
> and open_basedir directives. If configured properly, a user in a
> server with PHP support should not be able to execute commands, read
> other users' files or do anything outside his directory. Even though
> PHP is running with the privileges of the web server, the user
> doesn't have these privileges (again, if properly configured). Many
> ISPs configure PHP in this way.
>
> *IF* the overflow really exists *AND* is exploitable, I would be
> very worried, because *THEN* users could gain the privileges of the
> web server and do things they shouldn't be doing.

Then you should be very worried. Back in September 2000, Zeev Suraski
(PHP developer and co-author of Zend, the PHP4 scripting engine) said:
(http://marc.theaimsgroup.com/?l=php-...96815200329214)

> safe mode is indeed falsely advertised as being safe. It's very
> likely to contain bugs. As far as I'm concerned, it should be
> clearly advertised as something that would prevent the casual user
> from doing stuff he's not supposed to do, but isn't suitable for
> protecting against hackers.