Hardened PHP

Frank Kreuzbach writes "Yesterday the Hardened-PHP Project has announced its existence on the PHP-general mailinglist. It is the first public patch for PHP which adds security hardening features. It is meant as a proactive approach to protect servers against known and unknown weaknesses within PHP scripts or the engine itself. It enforces restrictions on include statements, adds canary protection to allocated memory and other internal structures and protects against internal format string vulnerabilities. It has syslog support and logs every attack together with the originating ip."

Comments

Call Me Crazy But....

[CptSparrow]

From the site:

to protect your servers on the one hand against a number of well known problems in hastily written PHP scripts

Wouldn't a better defense be to simply write good code?

Re:Call Me Crazy But....

[Karamchand]

Think about web space providers, usually they can't really control which scripts are executed on their servers by the customers. PHP's safe mode is cute already, but this can be an additional layer of security.

Re:Call Me Crazy But....

[The_Mystic_For_Real]

Of course the best way to secure anything is to take the time to write good code, but the reality is that many pages have to be put together in a limited amount of time by people with very little experience. I think that it is a good thing to see people in the security community keeping this in mind.

is this just an excuse to write sloppy code

[burritoKing]

it's certainly a step in the right direction, however as most vulnerabilitiesseem to come about as a result of poorly written code shouldn't the community be trying to educate newer (and some more experienced) PHP users.

Re:is this just an excuse to write sloppy code

[mumblestheclown]

i couldn't disagree more.

as the japanese car makers discovered (or at least the idea came to prominence) in the 1950s, ANYBODY (even people with 93 PhDs) who assembles something makes mistakes occasionally. the trick is to limit the number of modalities that allow for mistakes. a person who is asked to make a wheel fairing in three minutes using simple hand tools will make far more mistakes than one who has a dedicted stamping machine.

in fact, the japanese cars excelled in quality, worker satisfaction, and in the competitive marketplace for many years in large part that their idea that a) errors are natural stochastic processes b) the rate of errors in an any process is more determined by the design of the process than some inherent quality of the worker and therefore c) when a mistake is made, analyze the process, don't blame the worker as this will lead to d) continuous improvement and also empower workers to speak up.

even the most experienced PhP programmer can make an error. education helps, but fixing the system is a better idea.

Re:is this just an excuse to write sloppy code

[Kiryat Malachi]

It's more than that, though. Mechanical and electrical engineers (usually) learn a concept called design for manufacturability, which encompasses things like designing such that when you try to fit tab A into slot B, it is physically impossible to fit them in the wrong way. For the non-engineer, good examples of this are keyed ATA-IDE connectors; the old ones weren't keyed, and you had to check the cable for the red wire and the board for the 1 pin, to make sure you had it in right. Now you just line the slot with the tab and its correct. That's DFM, and the idea is that you physically CANNOT fuck it up, making a 75 IQ and a 150 IQ functionally equivalent.

Its all about the process, and very little about the worker, if you designed the process right. Similarly, if Hardened PHP can make it so that exploitable code simply can't run, you've cut down your probability of breach whether you have great programmers or George W. writing your code.

Laziness

[kevmo]

From what I can see this project doesn't do much against protect lazy coders. The features listed are easily protected against by writing non-sloppy code.

I'm not sure that this project is a good thing, as if someone gets used to it and switches to a server without it they might be in trouble.

Re:Laziness

[HeghmoH]

This is a common theme, the "Security problems only occur because of lazy/sloppy/stupid coders, and the solution is to become better coders" theme.

The problem is that it's complete BS. Even the most wizardly coder will make mistakes. The only way to be secure is to have lots of code reviews, and then things still get through; look at holes in SSH or Apache. Tools like this certainly don't hurt, and they might just help. "Don't make mistakes" is not an option.

Re:Phew!

[hattig]

I assume this like how they used canaries to test for gas in mines? If the canary died, then it was dangerous to be in that area.

So from that, I assume that "canary protection" is actually running a kind of honeytrap for common PHP exploits, and if one is triggered ("dies") then it does some computery equivalent of ("lets get the fuck out of this mine").

This is all speculation based upon the name though.

Bad Coding = Security Holes

[wellard1981]

I don't think the PHP engine is to blame, it's more of an issue with the PHP script developers to make sure they plug all the holes -- sure that's not always possible, however take PHPNuke as an example of poor PHP scripting, SQL injects are possible though a number of the modules. You have to add a high number of 3rd party patches to make the thing secure.

This Hardened PHP is just hand holding the developer into a false sence of security.

This is a Good Thing(R)

[Anonymous Coward]

Well believe it or not, in a lot of cases, PHP code just cannot be trusted. There may be vulnerabilities outside of PHP that can allow an attacker to place their own scripts on the server. When for instance, the ftp access password is cracked, someone can do just about anything if php hasn't been secured. With extra security measures, your site might be lost, but the server won't be compromised any further than that. For instance, on my server, functions like system and popen are disabled.

Besides, if everyone writed only really nice code, why would there be RSBAC and PaX?
Trust is a weakness.

A patch?

[mabu]

After going over the site, Hardened PHP appears to be a patch to the existing PHP. Why don't the authors just petition the folks developing PHP to include these patches in an upcoming version?

The problem I have with this project is that it's likely PHP-version dependent, and once you implement it, you have two different sources you have to synchronize code for (not unlike Apache+Mod_SSL). I'd rather not have twice as much work to incorporate these features if necessary.

Perspective

[cnf]

I think it is funny how most /. readers demonstrate how they think from a user perspective, and not from an admin perspective.

Now don't get me wrong, I understand, it's *hard* to think as an admin if you have never *been* one. But when you are an admin on a machine, you don't think "My users will just have to learn how to code secure, then there is no problem."
Sorry folks, just ain't gonna happen!
Joe home who wrote a site just to show off his holliday pictures thinks its swell how easy php is, and he doesn't really care about becoming fluent in php, as long as his little enviroment runs!

Sure, you can try and educate your user, but if you maintain a 500+ user server, security is in YOUR hands. only ONE of your users need make an error, and the whole machine might go down. And the "poor coding is the only reason for security holes" just doesnt cut it there.

Harden your servers, admins. Make the internet a fun place to be.

Re:Already in use

[onlyjoking]

Case in point. I started with Perl, learnt mod_perl then had to switch to PHP for most of my client work because most of them were using hosts which didn't provide mod_perl. This is the biggest drawback with Perl. Great language but brain-dead in the marketing department. Perl has lost ground in the web development sphere because it depends on mod_perl to compete with mod_php for performance. Perl templating engines (Mason, Apache Template, Embperl) allow you to do what PHP can do (and much more) but you're saddled with finding a host who will "risk" offering mod_perl. The authors of O'Reilly's "Practical mod_perl" even went so far as to advise explicitly against offering mod_perl in a shared hosting environment. Hence PHP replaces Perl in shared hosting environments.

Mention this on comp.lang.perl.misc and you get flamed for referring to Perl as a web developmnent tool. Well, if the Perl community only sees Perl as a tool for large web projects then so be it but they're making a big mistake. There should be a decent Perl templating engine which can run as an Apache module without exposing the Apache API, so that it would just do the one job well. Until this happens PHP will simply wipe Perl off the map in shared hosting environments.

Hopefully Perl 6//Parrot/Ponie will come up with something to break the inertia as bog-standard Perl CGI is irrelevant these days. Hell, many hosts don't even allow you free reign with installing CPAN modules.

Re:Already in use

[onlyjoking]

Regardless of Apache versions mod_perl is still a much bigger risk because it exposes the Apache API. By contrast mod_php exists, it seems, merely to give PHP its speed boost. This is what Perl needs.