March To Be Month of PHP Bugs

PHP writes "Stefan Esser is the founder of both the Hardened-PHP Project and the PHP Security Response Team (which he recently left). During an interview with SecurityFocus he announced the upcoming Month of PHP bugs initiative in March." Quoting: "We will disclose different types of bugs, mainly buffer overflows or double free (/destruction) vulnerabilities, some only local, but some remotely triggerable... Additionally there are some trivial bypass vulnerabilities in PHP's own protection features... As a vulnerability reporter you feel kinda puzzled how people among the PHP Security Response Team can claim in public that they do not know about any security vulnerability in PHP, when you disclosed about 20 holes to them in the two weeks before. At this point you stop bothering whether anyone considers the disclosure of unreported vulnerabilities unethical. Additionally a few of the reported bugs have been known for years among the PHP developers and will most probably never be fixed. In total we have more than 31 bugs to disclose, and therefore there will be days when more than one vulnerability will be disclosed."

great...

[blantonl]

Looks like this will also be "Month-of-me-working-harder-to-make-sure-my-site-i s-patched- and-updated-and-not-exploited-by-script-kiddies"

Install modsecurity

[HxBro]

I recently installed modsecurity http://www.modsecurity.org/ [modsecurity.org] for apache along with the rules from http://www.gotroot.com/ [gotroot.com] and it's done a good job of blocking attacks on my server including a lot of the php mail() injection attempts, whilst it has shown up a few false positives like someone posting a message with sql keywords e.g. "select" "from", it is certainly worth installing even if you have to monitor the logs for a bit afterwards to watch for the false positives and alter the rules accordingly.

Whilst it probably won't solve a lot of the problems with php and security it does help protect the server especially when you don't have control over what your users are uploading to their web space.

Re:even if...

[Alphager]

He began his crusade when he founded the security-team: He wants a secure PHP. He left the security-team out of frustration that the main devs didn't care about security (leaving security-critical bugs unfixed for ages). This month of PHP-bugs is his effort to put pressure on the devs to finally make security a priority.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Your site is likely already compromised.

[Anonymous Coward]

Most likely, you're correct.

Still, there are precautions to take when running a common PHP-based app. First off, use Xen. Set any filesystem to read only (through Xen) that you can get away with. When installing PHP, only install the modules the script actually uses. Second, install mod_security and enable every possible protection. Third, install Suhosin (hardened php, Debian Etch has it packaged). Fourth, edit the php.ini file and enable safe mode and disable every possible feature you can get away with. Fifth, for the DB create multiple accounts. Use the permissions properly. Set it so that the user the script has only can update the specific tables it has to, deny it from everything else.

Still, it will only be a matter of time before it's compromised but at least those steps help. Make sure to make regular database and file backups from the Dom0 so it will be easier to restore the site.

PHP really needs to enforce proper security. In 5.x it's OO is actually pretty nice and I like doing development with it, but I've dropped it for Java due to constant security issues.

Re:great...

[miyako]

This comment reflects what seems to be one of the biggest misconceptions in computer security. People seem to be under the impression that vulnrabilities are magically conjured into existance when the bugs are made public.
The fact is that the bugs have really been there the whole time, and just because we didn't know about it doesn't mean that some nefarious person didn't know about it.
Now, script kiddies might not know about the vulnrabilities until they are made public, but they are called script kiddies because they use scripts- usually written by someone who has an inkling of what they are doing.

Re:We audited PHP for some of our projects.

[clawoo]

Not to start a little argument over PHP and Python, but you're comparing apples with oranges here. You are saying that PHP is insecure, its semantics are undesirable and so are its standard libraries, database interfacing, interpreter and performance, and then you come along saying how awesome Django is, disregarding that actually you're comparing a language with a framework.

There are a handful [cakephp.org] of decent [xisc.com] PHP frameworks [symfony-project.com] out there, with others coming along [zend.com], which you can take and compare with Django, but please don't bash the language because you don't like its semantics, you have something personal with it or you didn't take the time to choose a decent framework.

Regarding the database interfacing support, I beg to differ, I believe PHP has been supporting a large number of databases for a longer while than most of the other web scripting languages out there today.

Look on the open/bright side.

[kale77in]

The bright side, it seems to me, is that PHP's openness means even if the developers are slack, the bugs can still be disclosed without IP litigation threats.

Also, he's given the developers a week or two of warning before March. If there's anything *that* serious in there, actually known to the developers, the fix could conceivably be ready by the time the bug is announced.

I run PHP sites, and I'd rather see the bugs public and being patched, than known only to the developers (we hope).

Re:Your site is likely already compromised.

[Anonymous Coward]

You're absolutely correct.

However, you'll probably run into a situation where the customer demands a certain poorly written php app. In those cases you have to go through the extra effort and deal with the inevitable compromise.

PHP is a nice language, but it needs to enforce proper security. If that security breaks apps, tough shit. Fix the broken apps.

Re:So, PHP means ?

[onerob]

Register Globals has been off by default for years.

Please don't let us see the return of \'magic quotes\'

A Couple Easy Precautions

[corychristison]

I've been running PHP for some time now, I try to use the latest and greatest, but sometimes I am a little behind.

Here are a few simple precautions for PHP configuration:

• Do not(!) install cURL. I know it is useful, but has a lot of security problems!
• Disable register globals [default as of 4.2.0]
• Safemode is worthless and a little too restricting, use OpenBaseDir.
• disable_functions = exec,system,passthru,shell_exec,proc_open,proc_clo se,proc_terminate,proc_nice,proc_get_status (may be more, off the top of my head :-)

These are what I can think of off the top of my head. This allows full compatability with all major scripts [mostly due to not using SafeMode] but still holds a fair bit of protection from people executing scripts and pushing them to run in the background. Had this happen to me a few years ago. I was hosting someone as a favour, and I'm not sure if they did it, or they were running some crappy code and it was exploited. Either way, their account was suspended.

Re:Take PHP outside web pages altogether.

[FreakTrap]

$a = array (1, 2, 3, 4);
foreach ($a as &$b) $b++;
foreach ($a as $b) $b++;
print_r ($a);

It is increment twice because after the first loop, $b is still a pointer to the fourth element of $a. Continuing in the code, the second loop will assign the fourth value of $a each value of $a, then increment it. Try debugging it like so:

$a = array (1, 2, 3, 4);
foreach($a as &$b){
$b++;
}
print_r($a);
foreach($a as $b){
print_r($a);
$b++;
print_r($a);
}
print_r($a);

... and you will see what it is doing. Solution: unset your variables before you re-use them.

$a = array (1, 2, 3, 4);
foreach ($a as &$b) $b++;
unset ($b)
foreach ($a as $b) $b++;
print_r ($a);

And for the $$ thing, it seems to do exactly what it is intended for...

[Simple]
$a = "Hello World";
$b = "a";
echo $$b;
//outputs 'Hello World'

[Complex]
$var0 = "Hell";
$var1 = "o wo";
$var2 = "rld!";
$i = "var0";
while(intval($i[3]) <= 2){
echo $$i;
$i[3] = intval($i[3])+1;
}
//outputs 'Hello World!'

From the PDO docs page:

[yem]

Warning

If your application does not catch the exception thrown from the PDO constructor, the default action taken by the zend engine is to terminate the script and display a back trace. This back trace will likely reveal the full database connection details, including the username and password. It is your responsibility to catch this exception, either explicitly (via a catch statement) or implicitly via set_exception_handler().

The default behavior in case of database problems is to display the host, username and password in the browser? Good grief.

Re:Why was register_globals there in the first pla

[SimHacker]

If there isn't a problem with register_globals, then why are they finally taking it out of the language? Of course the real questions are: why did it take so long to remove from the language, and why was it ever there in the first place? That is even more evidence of extremely bad judgement on the part of the PHP designers, that they mad such a bad mistake in the first place, and took so long to admit they made a mistake and correct it. They still try to blame it on "bad developers", but that's the only kind of developers they have left any more, because anyone with any sense or choice in the matter has moved on to better languages like Python and Ruby.

Doing a google search for register_globals site:www.us-cert.gov shows 112 references to security vulnerabilities having to do with register_globals. Is that enough evidence that register_globals is a bad idea?

The register_globals flag should not even be an option, backwards compatibility be damned. When you have security holes like "Unsafe termination of parse_str() may result in the register_globals directive turned back on [hardened-php.net], you're screwed even when you turn it off, because PHP turns it back on internally, then wets its pants before turning it back off, so it leaves it on for the rest of the lifetime of the web server.

That terrible bug was found AND FIXED by Stefan Esser (the person who this thread is about, in case you didn't bother to read the article), yet some piss-water-carrying PHP fan-boys are still attacking him as a "traitor".

Here is another article he wrote about PHP security problems having to do with register_globals and a lot of other stupid flaws that should have never existed in the first place: Zend_Hash_Del_Key_Or_Index Vulnerability [hardened-php.net]. If you don't like it when people blame the Zend Corporation for so many of the problems in PHP, then maybe you should ask Zend to stop putting their company name into all those functions that are the root cause of so many security problems.

-Don