bugtraq - An Alternate View of Recently Reported PHP Vulnerabilities

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date: Thu, 3 Apr 2003 23:28:58 -0500 (EST)
From: "Steven M. Christey" <coley@...us.mitre.org>
To: bugtraq@...urityfocus.com
Subject: 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