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
This archive was generated by hypermail 2b30 : Fri Apr 04 2003 - 12:18:36 PST