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

Phew!

[Dark Lord Seth]

adds canary protection

Is that protection against canaries? Protection with Japanese kunf-fu canaries? Or protection for canaries? I mean, the kung-fu canaries have potential...

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.

Re:Phew!

[CTho9305]

It's a way to protect against buffer overflows. You put some known data on the stack, and before returning from each function call, make sure that data hasn't been changed. Most buffer overflow exploits work by overwriting part fo the stack, and canary protection will detect that the stack has been changed, so the exploit code will not run.

Re:Phew!

[Anonymous Coward]

I keep a canary in my bathroom for that very reason.

Already in use

[Noose For A Neck]

I do some development and site administration work for a high traffic porn site, and I can tell you that we've been using Hardened PHP since before the project announcement (I'm friends with one of the developers). It works OK so far, but the server starts to get worn out after a while, after being particularly abused by a day's peak traffic.

Re:Already in use

[Ieshan]

Two Questions:

1) I've heard some complaints about PHP on "high traffic" sites, is it easier on you guys because you're primarily serving static pages? I mean, I'm not a big porn freak, but it seems to me that most porn sites wouldn't be overly dynamic, since most of the content doesn't change once it's posted. Maybe some of the userauth stuff is PHP based, and maybe a site forum, but I don't really see what else would need to be supar-dynamic.

2) Maybe this seems like a naive post - and maybe it's offtopic, mods, have your way - but with all the free porn that's constantly bombarding my mailbox and my computer screen with flashing messages, how do you all make money?

I mean, what's "high traffic"? 20 paying users? Where *are* all these people that don't get the same spams for free porn that I do?

Maybe the free porn isn't actually free, and that's why people pay.

Re:Already in use

[a1cypher]

Actually, I am a PHP developer for some major porn sites. The sites that I work with, however, arent the end user sites that people pay to view, I work with the sites where porn webmasters go to buy their content.

Surprisingly, it has to be fairly dynamic. Most of the work that my software has to do is in posting the content for the first time. You upload a zip, and the software will extract the zip taking the images makes thumbs and full sized samples with embedded watermarks. From this point on, the software is basically an advanced shopping cart with some extra features like the ability to order individual images out of a particular zip, and instant download.

The sites that I have setup are surprisingly popular, and within the past year and a half, the sites I work with have sold closs to half a million dollars worth of porn. That may not seem much to a big business tycoon, but it is when theres only a handfull of people making the profit.

I dont know how well the end user sales are however. I like this hardened php stuff and I think it has great potential. I am waiting for them to come out with a PHP5 version, and then I will jump right on it because all of my newer projects are going to be in php5.

Re:Already in use

[toastyman]

1) We've got no problem with PHP on a pretty high traffic porn site. Turck_mmcache helps quite a bit by caching the pseudo-compiled bytecode of each script, so it's pretty blazing.

Basically every page is dynamically generated, even the images go through a PHP script to make sure the right people are seeing the right images.

We honestly have a bigger problem with the SQL server keeping up than PHP consuming too much CPU. The site listed in my home page URL here runs on 3 servers, one for MySQL, one for most PHP scripts, and one to serve all the images. The two httpd servers handle about 1200 requests per second, and the loads are pretty low. 95% of those requests are PHP scripts.

2) For the site I'm talking about there, we've got anywhere from 1000 to 5000 people browsing the site at once. Another site I admin(very NSFW) gets much more traffic than that, and a lot of those visitors are downloading 5-200MB movies for free. There we have two thttpd servers handling most of the static files (videos and images). At times there we're in the more-than OC-12 levels of bandwidth, and they handle the load just fine.

How do we make money? Some of our sites are subscription based, and we try to have content that you can't get anywhere else. We try to drive the community aspect of our sites, and try not to just be "another generic porn site".

The first site lets anyone browse for free as much as they want, you just get access to more content if you pay. You also get to talk to the "performers" and a few other perks. The second site I mentioned is all free, it's supported by ads though.

(trying not to make this spam, just a bit of insight into how porn on the internet actually works. And no, I'm not Stile.)

Re:Already in use

[abulafia]

Weird. I do high-volume sites for a living, and mod_perl rocks. I sometimes fall back to coding something in C when it is called millions of times a day, but in general, mod_perl makes getting close to the iron really easy.

shrugs.

Hell, people probably can write fast software in PHP... I can't stand the language, myself, so I've never bothered to learn optimization tricks. Mod_perl kicks ass... as Slashdot knows, not to mention Amazon...

Can a PHP devotee who also knows web development from a mod_perl standpoint explain why you like PHP so much? I'm honestly curious. I've modified other people's apps, and find the language both cumbersome to use for non-trivial things and overly low level, at the same time.

Re:Already in use

[nemesisj]

I'm not extremely familiar with mod_perl, but I do lots of work in PHP.

The reasons I like PHP better than perl for web development is the fact that you can escape in and out of execution (yes, this can be and is often abused) and I like how PHP wraps some of the more unreadable aspects of perl (like extracting arguments, etc) and has nice session support.

Also, PHP seems to have a lot of standard web stuff rolled in by default. I know that you can configure perl to be whatever you want it to be, but back before I had access to my own servers whose environment I could control, this mattered a bit more.

Anyway, just my two cents - it really comes down to personal preference between the two in my opinion - lots of the major disctinctions have gone away in the last couple of years.

Re:Already in use

[BusDriver]

Turck MMCache dev stopped since the lead dev was taken in by Zend. That doesn't mean development has stopped though! New people have taken it over and are slowly coding new stuff up!

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

[Yaa 101]

Perl was invented to scratch a itch on the commandline, PHP is purely invented for apache and this shows... The problem is not PHP being "slow", the problem is wrongly usage of the database, mostly mysql. Some well known PHP programs use more than 30 queries each go, you can understand that of course a high volume site is out of the question... Further there is also the question with both Perl and PHP, that is a smooth configured Apache that can fork and prefork a number instances from itself to serve connections. Mainly PHP is a C like interperter on steroids... The language is very problem solving by nature and very efficient in that it takes a handfull of statements to solve a complicated matter... I think Perl developers see the same with Perl, my impression is that the same solutions take less code in PHP compared to Perl, but the is my private impression... The largest power of PHP is intuitivity, most constructs you think off work in one or 2 go's while in other Languages often you are buried to death with error messges... And not to forget, instant gratification, you can do more than 1000 runs in a hour when developing...

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.

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.

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.

Re:Bad Coding = Security Holes

[Rui Lopes]

Why protected at an upper level, if you can protect at a lower level? It's more robust to enforce security at a lower level than to rely on good programming practices!

Re:Bad Coding = Security Holes

[chegosaurus]

My PHP site is on a shared host. I do my level best to write secure code, but it's very possible the people who share my server don't. The server gets exploited through one of those, my site gets rmed or defaced, and suddenly I don't look so clever.

It's so easy to write bad code in PHP that half the world is doing it. Anything that helps ISPs protect users from the shortcomings of their peers has to be good news.

PHP security all relies on the coder

[bigberk]

It's all about how the coder writes his/her software, same with C, or Java, or anything else. I am directly aware of several breakins using PHP, and none of them used buffer overflows or anything so low level.

The most interesting one I saw used a programming flaw (note: not PHP's fault) to execute arbitrary commands to get the web server to download, compile, and execute a telnetd-like program for remote logins. Once the attacker had gained access via user nobody, they ran one of several trivial Linux local root exploits to get root. Don't kid yourself, Linux ain't all that secure.

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.

Really Now..

[FuzzyBad-Mofo]

From one of "Hardened PHP's" examples:

include $_REQUEST[$action];

Which is certainly a good example of what not to do; but if somebody's dumb enough to do something like this, likely no amount of engine protection is going to help them.

Other PHP Hardening Sites

[Dozix007]

I run http://www.uberhacker.com . This site is dedicated to secure PHP programming. It is better to program secure rather than limit coding abilities. Secure programming allows for a wider range of scripts and security.

Not quite

[vlad_petric]

Make no mistakes - in 2001 a security paper claimed that ``it is very hard to write a secure PHP application (in the default configuration of PHP), even if you try''

``A Study In Scarlet - Exploiting Common Vulnerabilities in PHP'' [Clowes 2001]

PHP is probably slightly better these days, but, just like Windoze, simply wasn't designed with security in mind. It's a language grown incrementally, designed to allow you to write websites very quickly. And yes, easy to use means that it attracts people who know very little about programming.

Conclusion: combination of insecure language plus low-quality developpers equals security disaster.

Re:Not quite

[vlad_petric]

Java Server Pages - jsp.

Its advantages: faster (java isn't slow, it has a slow startup, which for a server is hardly a big deal), because the code you write is going to be converted in machine code; scales better (PHP still doesn't provide connection pooling; pconnect doesn't count, btw); more secure (no buffer overflow b/c of java, can use security policies to restrict what your pages are doing)

Its disadvantage: well, you have to learn java. You can't just jump into writing jsp pages, as you'd do with php. But I can equally argue that that's an advantage as well, as it increases the quality of code.

nice intent but wrong approach

[mabu]

There's a fine line between securing a base system and crippling functionality. I'm all for the Hardened project, but I think ultimately it's the programmer's responsibility to make sure their code is secure.

A better approach might be to create some sort of code-parser that examines PHP code and warns the programmer of possible bad habits. Of course this should be prefaced with a long disclaimer that such a system isn't foolproof but is a good idea to run on any code to make sure you haven't overlooked any obvious problems.

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.

I dont get this

[cyberlotnet]

Tons of complaints about how php programmers should program better, how php sucks, this and that..

Yet just the other day people where bitching about Fedora not having SELinux on by default.

PHP - Hardened PHP
Fedora - "Hardened Fedora"

Its really the same thing. Instead of fixing root flaws we through more security over them hoping it will stop then next hacker..

Linus must really suck at kernel programming if we have to do things like this..

No he doesn't Linus rocks, I cheer for every single developer that has ever submitted a patch to the kernel.

Fact of the matter is this..

WE ARE HUMAN.. TO BE HUMAN IS TO ERR.

Yes the programmers, be it php exploits or the next kernel buffer overflow make mistakes.. Does that mean they are bad programmers.. HELL NO..

Are there a lot of bad PHP programmers, yes.. I bet there are a lot of bad C programmers out there as well. We are just lucky they dont get to commit changes to the kernel or we would all be FUBAR.

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.

"Safe programming" ain't that easy

[garyebickford]

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.