Slashdot Mirror

The backdoor was basically an eval that ran anything posted to it (according to the Ars article posted up thread). On my web host, Suhosin is enabled by default, and setup to block eval from ever running.

I.e. Even if I had installed this bad version of PhpMyAdmin, I would not have anything to worry about with regards that eval statement. So, security hey. It's hard, but not that hard.

That's not even comparable.

While the Rails bug was pretty bad, it was a design flaw that the developers were not convinced was a design flaw. (It was.)
It was a flaw because it made it easier for the developer to to write insecure. It would be kind of if PHP had a mysql_escape function that should never be used because it didn't really work, or a htmlspecialchars that didn't escape single quotes by default, or... Oh, wait...

This, on the other hand, is a trivial remote code execution flaw, and it works even on perfectly correct code. This is not the page developer's fault, not even a tiny bit. The only thing they could have done to protect themselves is to not use PHP.
And not only did they hold onto this bug forever, when they finally patched it, the patch was wrong.

To be blunt, PHP is a terrible language, and its core developers are mostly incompetent monkeys that are not fit to write security critical C code.
If you are starting a new project, never use it. Just about any other scripting language (Perl, Python, Ruby...) will be better, and have an actually competent programming community to boot.
If you are stuck with an existing project, you should always be running Stefan Esser's Suhosin patch, which hardens it against common programming errors, both on the C and PHP side.

You got me before my morning (afternoon) coffee so here are some haphazard thoughts:

1) You're writing a PHP/MySQL app. It doesn't matter if it's a game or the next big social networking site. There are holes common to all web apps (check out the OWASP Top 10). There are also holes common in PHP code, such as remote file inclusion. There are things you can do wrong with JavaScript. Learn about them, learn about how to prevent them and write your code accordingly. Security should be part of development, not something you tack on afterward. This means using good coding convention (i.e using parametrized queries instead of concatenation, always encoding output, etc) and ensuring that any design decision you make does not compromise the security of your application. Make sure security is multi-layered as well. For example, even if you think your app is 100% free of SQL injection (wrong assumption!), you still need to make sure you've properly hashed user passwords in the database in case they're exposed. (Side note: please don't use MD5 for this; look into bcrypt, or at least many rounds of SHA-256 or such.)

2) Harden your environment. No amount of hardening will stop all attacks, but it may help mitigate their impact, and if you're lucky, it may thwart some script kiddies or automated scripts. Running PHP? Harden the crap out of your php.ini (magic_quotes_gpc, turn off fopen() for URLs, etc). Think about installing the Suhosin patch. Just don't get complacent; there are ways around all these protections and they are not a substitute for secure code! You may also consider a web-app firewall (WAF), in the vein of mod_security, but don't fully rely on these either. If you're publishing code for others to use, don't ever count on your users to implement these same protections in their environment.

3) Web app scanners can help, especially if you're a novice with security, but once again, they will not catch everything (probably not even a lot of things.) There's skipfish, NetSparker and free versions of some of the more commercial scanners.

4) I know your question was whether to publish your code. I say "Yes", but this is a personal opinion -- I just happen to think it will give security dudes more of a chance to audit your code, and attackers will find your vulnerabilities anyway, through poking at your app and fuzzing even if nothing is published.

I hope that helps a little!

I believe that what you're describing is not what the article is about. However, it is an interesting vulnerability. More appears to be here: http://www.hardened-php.net/library/poking_new_holes_with_flash_crossdomain_policy_files.html

OWASP is invaluable for learning the WHY and HOW behind security.

But for an amateur, I think the first best thing he could do is apply the Suhosin patch for PHP: http://www.hardened-php.net/

This lets him worry about the why and how AFTER he's already closed many of the attack vectors a default PHP install leaves open. Especially if he's running below 5.2.x.

Furthermore, PHP has been more security focused since 5.01. You can learn a lot about security just by reading the release notes, even if you don't think you're learning about security!

For example, the filter_input() function. Instead of doing this:

$phone_number = $_POST['phone_number'];

do this:

$phone_number = filter_input(INPUT_POST, 'phone_number', FILTER_SANITIZE_STRING);

That simple change applied to all of your $_POST, $_GET (and/or $_REQUEST) look-ups will shut down most of your application-level attacks.

Any PHP developer should learn and ALWAYS use the new Filter features: http://us2.php.net/manual/en/ref.filter.php

Also, take a look at installing Suhosin, if you have root access to your server. It's a PHP patch that adds more security on the binary level to combat certain common attack vectors like SQL injection (though that said, you should never simply rely on its protection without knowing how these attacks work and how to program defensively).

Speaking of which, PHP itself has a page on SQL injection and how to avoid it, which I recommend that you read and commit to memory if you don't already know about it. Especially for new developers in the PHP world, SQL injection is the number one security pitfall, and if you're uneducated about it, it's very easy to create insecure applications.

If you would like, I am a very experienced developer with about eight years of PHP experience. I can go through your code with you and tell you where you might be able to improve security. My rate is $30 / hour, but it probably won't take too long to give recommendations. If you're interested, please contact me at my first name at jamiearseneault.com.

mod_security and Hardened PHP can help with preventing future attacks that people don't yet know about.
Also, using something like GRSec, or SELinux can further restrict what people could do if they did end up with a shell on your webserver. Although whether it's worth the effort to set up for everyone is another question.

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, 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. 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

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, 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. 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

What's up with this logo: http://www.hardened-php.net/globals-problem

He releases patches instead.

Instead of changing concepts midway through they have added security layers and APIs that need to be *explicitly* set - meaning that like Windows (was?) they have a policy of being open per default and having to be explicitly made secure, instead of closed by default and enabling only what you need.

That's what I think Stefan Esser means when he says "safer from the inside". Many things in PHP are inherently flawed and can only be remedied through changes in concept and nothing else.

Add to that stuff like $GLOBALS overwrite (more details here) that are/were essentially a WONTFIX. No wonder Essner is getting frustrated.

The "news" is that Stefan Esser unsubscribed from the security@php.net mailing list.

Stefan Esser will continue to work on PHP security through maintaining the Hardened PHP project [1] which is a patchset to PHP which enables some low level security features into the language, as well as the suhosin extension [2] for PHP which can be used without patching PHP and "protects servers and users from known and unknown flaws in PHP applications and the PHP core".

I am personally of the "full disclosure" security mindset, so if there was indeed an issue with the response time of the "PHP Security Response Team" then some outside pressure would be a good thing.

More about this on Zeev's blog [3].

[1] http://www.hardened-php.net/
[2] http://www.hardened-php.net/suhosin.127.html
[3] http://www.suraski.net/blog/index.php?/archives/15 -Stefan-Esser-quits-securityphp.net.html

The "news" is that Stefan Esser unsubscribed from the security@php.net mailing list.

Stefan Esser will continue to work on PHP security through maintaining the Hardened PHP project [1] which is a patchset to PHP which enables some low level security features into the language, as well as the suhosin extension [2] for PHP which can be used without patching PHP and "protects servers and users from known and unknown flaws in PHP applications and the PHP core".

I am personally of the "full disclosure" security mindset, so if there was indeed an issue with the response time of the "PHP Security Response Team" then some outside pressure would be a good thing.

More about this on Zeev's blog [3].

[1] http://www.hardened-php.net/
[2] http://www.hardened-php.net/suhosin.127.html
[3] http://www.suraski.net/blog/index.php?/archives/15 -Stefan-Esser-quits-securityphp.net.html

The perception that PHP is insecure is based on the fact that it was in the past incredibly insecure, not just because of bad programmers, but by design as a language/deployment environment. Perhaps it was too long ago for you top recall, but it used to be that register_globals was on by default. register_globals was inherently insecure, and including it in the language at all was a huge security compromise, and pathetically enough since there are still PHP packages out there that depend on it, it has not been removed from PHP.

Also letting include() take a URL is batshit crazy. While handy (like most security compromises), it means that if anyone can figure out a way to sneak a string in to that include call, then they can import any malicious code they want. register_globals was often a handy way to do that in the past...

There are a few other things that I think are a sign of poor security design, but most would likely just cause language wars, so I will leave it to those above to illustrate that PHP, especially in its earlier incarnations had a poor design with respect to security.

PHP itself has had its fair share of security vulns, for instance:

http://www.hardened-php.net/advisory_202005.79.htm l
http://www.hardened-php.net/advisory_152005.67.htm l
http://www.hardened-php.net/advisory_142005.66.htm l
http://www.sans.org/newsletters/risk/display.php?v =3&i=50#widely4
http://www.sans.org/newsletters/risk/display.php?v =3&i=23#other1
http://www.sans.org/newsletters/risk/display.php?v =3&i=28#widely4
http://www.sans.org/newsletters/risk/display.php?v =3&i=48#exploit1

There are more, but I am too lazy to find a more complete list, and that is enough to illustrate the point.

So while it's true that there are a lot of bad security habits that many PHP programmers have used, PHP's bad reputation is something they have earned all by themselves.

The perception that PHP is insecure is based on the fact that it was in the past incredibly insecure, not just because of bad programmers, but by design as a language/deployment environment. Perhaps it was too long ago for you top recall, but it used to be that register_globals was on by default. register_globals was inherently insecure, and including it in the language at all was a huge security compromise, and pathetically enough since there are still PHP packages out there that depend on it, it has not been removed from PHP.

Also letting include() take a URL is batshit crazy. While handy (like most security compromises), it means that if anyone can figure out a way to sneak a string in to that include call, then they can import any malicious code they want. register_globals was often a handy way to do that in the past...

There are a few other things that I think are a sign of poor security design, but most would likely just cause language wars, so I will leave it to those above to illustrate that PHP, especially in its earlier incarnations had a poor design with respect to security.

PHP itself has had its fair share of security vulns, for instance:

http://www.hardened-php.net/advisory_202005.79.htm l
http://www.hardened-php.net/advisory_152005.67.htm l
http://www.hardened-php.net/advisory_142005.66.htm l
http://www.sans.org/newsletters/risk/display.php?v =3&i=50#widely4
http://www.sans.org/newsletters/risk/display.php?v =3&i=23#other1
http://www.sans.org/newsletters/risk/display.php?v =3&i=28#widely4
http://www.sans.org/newsletters/risk/display.php?v =3&i=48#exploit1

There are more, but I am too lazy to find a more complete list, and that is enough to illustrate the point.

So while it's true that there are a lot of bad security habits that many PHP programmers have used, PHP's bad reputation is something they have earned all by themselves.

The perception that PHP is insecure is based on the fact that it was in the past incredibly insecure, not just because of bad programmers, but by design as a language/deployment environment. Perhaps it was too long ago for you top recall, but it used to be that register_globals was on by default. register_globals was inherently insecure, and including it in the language at all was a huge security compromise, and pathetically enough since there are still PHP packages out there that depend on it, it has not been removed from PHP.

Also letting include() take a URL is batshit crazy. While handy (like most security compromises), it means that if anyone can figure out a way to sneak a string in to that include call, then they can import any malicious code they want. register_globals was often a handy way to do that in the past...

There are a few other things that I think are a sign of poor security design, but most would likely just cause language wars, so I will leave it to those above to illustrate that PHP, especially in its earlier incarnations had a poor design with respect to security.

PHP itself has had its fair share of security vulns, for instance:

http://www.hardened-php.net/advisory_202005.79.htm l
http://www.hardened-php.net/advisory_152005.67.htm l
http://www.hardened-php.net/advisory_142005.66.htm l
http://www.sans.org/newsletters/risk/display.php?v =3&i=50#widely4
http://www.sans.org/newsletters/risk/display.php?v =3&i=23#other1
http://www.sans.org/newsletters/risk/display.php?v =3&i=28#widely4
http://www.sans.org/newsletters/risk/display.php?v =3&i=48#exploit1

There are more, but I am too lazy to find a more complete list, and that is enough to illustrate the point.

So while it's true that there are a lot of bad security habits that many PHP programmers have used, PHP's bad reputation is something they have earned all by themselves.

You're mixing up replies.

The reply by Chris Shiflett you point to is in response to a much earlier comment by Stefan Esser. It is not a reply to the comments Stefan made with regards to his book.

Many people will suggest otherwise, but they are often those who lack a formal education and background in designing secure, scalable, high-reliability software systems.

I have an M.S. in Computer Science, spent my first three years as a professional developer working on the development of a secure (TCSEC B3 targeted) operating system, then another year and a half on a firewall project based on a secure OS. I've also worked in the telecom and space sciences fields for well-known companies such as Hughes, IBM, and TRW, designing and developing secure and reliable software. These days I work for a small company, still doing my best to design and develop secure and reliable software - now in PHP.

I don't claim to be a security expert - I've met some of the experts and they're far beyond where I'll ever be on the topic. But I certainly don't fit your description of uneducated or inexperienced. And I find your claims wrt PHP bogus.

Taking a quick look at the http://www.hardened-php.net/advisories.15.html"> advisories for the "Hardened PHP" project you mention, I see 1) issues with applications written in PHP - not the language's fault; 2) people doing stupid things with the language (for example, leaving phpinfo() called in deployed scripts), which is not a language issue; or 3) addressing implementation bugs, which is no different than those found in other languages - except that with PHP we call something a "PHP bug" that in, for instance, C, would be a "libc bug".

If you've got specific claims, please, put them out. But all I see in this thread so far is vague allegations. Or maybe trolling.

The Hardened-PHP project is one place to look.

Of course, the best option for serious work is to probably just avoid PHP, and stick with solutions that have proven themselves to be well-designed and far more secure.

PHP is popular because it's easy to jump into and fairly easy to learn, not because it's an efficient stable development platform. PHP also has a history of security problems almost as long as Microsoft.

Indeed. A truer statement has rarely been stated.

From an engineering standpoint, PHP is abysmal. Many people will suggest otherwise, but they are often those who lack a formal education and background in designing secure, scalable, high-reliability software systems.

The Hardened-PHP project is a perfect example of what is wrong with PHP. It's not that the Hardened-PHP project itself is bad (it's a very good thing!). The problem is that the core PHP developers have not taken such basic security concerns into consideration. The fact that they have to rely on a third party to provide such integral and necessary functionality is a very bad sign.

http://www.hardened-php.net/

hehe, Drupal sites have become fairly popular to hack lately. Or better yet here is the list of those getting hit by the Lupper worm. Wow, I hooked a live on here. Schweet mother of god. *pulls in* Ok, let's make the reality check. You haven't really accomplished anything. Except what? Me going to OpenBSD? I was working on that already? You have proven to my Microsoft fundy here, that Linux is just as insecure as Windows. Why? Becuase Drupal runs on both of those OS's. And to his fundamentalist ass, he believes that. Unlike many of the people here, I like to focus on other things than update all 300+ software pieces that Gentoo thinks I need. And yes, you are a dick. You could have replied with something intersting and started a debate. You could have emailed me and said something about my lack of... vigilance. Instead, you attempted to boaster your E-Penis size and try to make yourself think you are cool... or something. In less than a few hours I had that content removed and (some of) the issues fixed. So, apparantly you are online right now. How about we have a chat. Choose a medium (other than MSN --- and don't get me started on that). I'm off to consume fiene and work on the BSD boxen.

don't know if you were fishing for some input or not but here's my take on the vulns. i pay the bills writing PHP and not doing security work so...

http://www.hardened-php.net/advisories/012004.txt

#1 - pack() - make sure any user input to this function is thoroughly validated (duh, like all user input)

#2 - unpack() - same for pack() check for unvalidated input being passed to this function

#3 - safe_mode_exed_dir bypass - this one can only be exploited by a local user

#4 - safe_mode_bypass - file path gets truncated so that it could point to a file not allowed by safe_mode

#5 - path trunc in realpath() - similar to #4

#6 - serialize() - unvalidated input could cause bad things (duh, back to user input validation)

#7 - unserialize() - same root cause as #6, though potentially more harmful (i think, again, check user input)

so with enough user input validation, all of these are No Big Deal. without user validation the apps were vulnerable before these were discovered.

Because it breaks badly coded webapps - no more remote includes: http://www.hardened-php.net/documentation.php
Also, looks like it's tested only on Linux.

...
Unfourtunately PHP does prepend a "cd [currentdir] ;" to any
executed command when a PHP is running on a multithreaded unix ... (from the linked article.)

Apparently php doesn't!

They were announced before today, just read the dates.

You're probably not subscribed to any security mailing lists.

To Harden PHP while you're at it.

I've been working on an article about fault tolerance, which is related to security in important ways. It all comes down to complexity. Computer science is, its essence, the management of complexity. A programming system of the size of PHP must incorporate as much support for fault tolerance at its own internal level of complexity as possible, because the system is too complex itself for any programmer to understand the security implications of all possible interactions between different components of the PHP runtime system, and all the libraries. In short, as several admins pointed out from their own point of view, you can't depend on your own code, much less that of 500 others on the same server.

Looking at the Documentation Page for Hardened PHP, the project is adding some very good changes to the underlying runtime environment and constraints on programmers. Based on my first glance I would be pleased, and not at all surprised, if some of these are incorporated into the main PHP in some form down the road, once it's been ironed out for a while. I'm glad to see folks actively using it.

As for the various mod-perl advocates who don't grok PHP, I personally dislike working in Perl, which seems to me to be a collection of all the things that were thrown out of other languages because they promote bad programming practice. That's OK, I understand it has power and flexibility, but Perl code too often looks like sneezing to me. Different strokes, see.

The security issues raised by this project are certainly matched by many of the same or equivalent ones in Perl. IMHO, both PHP and Perl have become too big. It is a truism that the probability of failure increases geometrically with the size of a system.