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