Slashdot Mirror
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."
I like how this story is positioned just above the one about WinZip's poor security.
Or are you just glad to see me?
no body.
Is that protection against canaries? Protection with Japanese kunf-fu canaries? Or protection for canaries? I mean, the kung-fu canaries have potential...
Hate me!
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.
Software piracy is victimless theft.
It better not ever encourage Safe Mode as a security feature. I perfer running in Dangerous Mode.
where flamebait is +5 funny and funny stuff is -1 flamebait
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?
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.
What is CSSRepublic
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.
proactive approach to protect servers against known and unknown weaknesses
If it is trying to cover up known weaknesses, wouldn't that make it reactive? Proactive would have been if PHP would have been designed with security in mind.
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.
Wouldn't it be a lot more useful if they found an ingenious way to have PHP scripts run properly in a suexec environment, so we can finally get rid of safe_mode and open_basedir everywhere?
Not that this is not nice; every language should have internal hack/bug protections. But a proper security model would do more, no?
follow me on Twitter: http://twitter.com/moeffju
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.
I'm a administrator for a rather large PHP site, and most of these features have already been implemented by other third parties. The fact these people are implementing the same features used in open source projects makes me wary of exactly how original their code is.
Nope.
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.
From one of "Hardened PHP's" examples:
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.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.
Kung-fu comes from China, not Japan.
No, it's far too subtle for Slashdot's legions of morons.
``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.
The Raven
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.
I like your idea, but I really DON'T SEE ANY information on how to write secure code. Perhaps a direct link? So, anyone know a better site or some books on how to write SECURE code.
http://www.uberhacker.com
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.
Well, I can't speak for the first post, but from my experience at Internet Entertainment Group (ClubLove, went out of biz a few years ago), most of our pages WHERE dynamic. We had several hundred sites that all drew off the same database of picks (stored in a simply HUGE RAID named Cthulhu). Most of the sites where template driven, and heavily relied on generating galleries on the fly based on whatever theme of the particular site (cum shots, MILF, gay, cream pies, whatever...). We server it all off of 9 SGI machines running Irix...
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
Check out http://www.uberhacker.com/cgi-bin/index.php?page=g uide
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.
Personal Website
PHP *can* run in a suexec environment. But to do that, you have to make your php run as cgi-bin.
This isn't exactly the greatest thing for performance. Not to mention having to put a !#/usr/bin/php on the top of each file.
I'm sure some mod_rewrite work could pipe all php file extensions to one script that would do a require on the file, eliminating the need for that string on the top. What a pain in the ass, though.
So your statement should read: wouldn't it be a lot more useful if they found an ingeneous way to have PHP scripts run properly with suexec and mod_php?
I, for one, would like that. It's shitty about how many hosting companies who run shared accounts make it easy for other people on the machine to sniff my Database server password.
/^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$/i
There's nothing but crap on that site. I heard about it before when you spammed some site I read. You teach poor programming skills and barely touch on anything that's useful towards security.
Your "gauntlet" challenge is probably a scam to get people to write scripts for you. You can't even handle your own PHP errors gracefully and run everything through an index.php page...
Please come back when you have something useful.
---John Holmes...
Not many folks will qualify as knowing both. From my perspective, PHP was stable (MOD_PERL, several years back, was twitchy) and considerably simpler. Remember that to much of the programming world, Perl is weird.
Wouldn't that make it HPHP?
If it's not Consolidated Lint, it's just fuzz!
have you ever used the fusebox methedology?
e gory&categoryid=xxx
e gory/categoryid/xxx
Although it may be nicer to use mod_rewrite to be able to use friendly url's
For instance in my companies e-commerce web app you can either use:
http://www.site.url/index.php?fuseaction=shop.cat
http://www.site.url/index.php/fuseaction/shop.cat
or http://www.site.url/shop.category/categoryid/xxx
Whatever, they all get piped through index.php through which then puts them through to the relevant circuit (i.e. shop) and fuse(action) (i.e. category).
I am NaN
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.
It's human to err, but diabolic to persevere in your errors.
When I talk with php "developpers" who learnt it by example and without any formal programming background, it's extremely difficult to get past the "but it works very well this way ..."
The Raven
The ones I'm most familiar with are extensions of Common Lisp. There are 3 CL web servers, each with dynamic HTML generation capability (AllegroServe, Araneida, CL-HTTP). Then there's Lisp Server Pages, Active Lisp Pages, etc., and another whole load of CGI solutions. I use (and highly recommend) AllegroServe. There is a whole big list over at Cliki (which runs on Araneida).
There are many CGI bindings for various Scheme implementations, and the PLT web server is kind of popular. I'm not very familiar with Scheme web solutions though, so I probably left something out.
There is a lot of activity with Smalltalk-based web apps. Seaside is a continuation-based framework that gets a lot of attention. There's also AIDA/Web, and an unfinished mod.Smalltalk. I am not very familiar with Smalltalk web solutions either, so I probably missed a few.
Python is a very popular option, and Zope seems to be a very popular framework. I don't know anything about web programming in Python aside from that.
Take pretty much any of the recent lightweight (in the conference meaning of the term) languages, and you're bound to find good options, almost all of them better in terms of security and speed than PHP; I can't think of a single one that has a more annoying syntax or more convoluted and limited semantics than PHP, though. Another thing that you should consider is the website we're posting on is pretty interactive, and kind of popular, and it's written in Perl.
In the great CONS chain of life, you can either be the CAR or be in the CDR.
Ugh. God I hate seeing sites handled almost entirely out of index.php. Like an iceburg it's the publicly visible part of a very troubled language.
Try this for an ugly URL:
Sorry to pick on the Ogre3D project. I've seen similar URL's around (in particlar on sourceforge projects) so it appears to be using one of the popular PHP theming packages. What an ugly abomination. I'm of the (strong) opinion that URLs should make sense and if possible, be memorable. It's a geek thing. I sometimes forget to bookmark pages or for whatever reason can't get an electronic version (email, text file, etc) to myself. I don't know how much URL's matter to non-geek users, but making things clearer would probably help everyone.
PHP seems to have no mechanism to handle "virtual" URLS (i.e not pointing directly to files), instead relying on the admin to use Apache's mod_rewrite module. Could some PHP coder enlighten me, is this really true? It seems very odd that a language (and runtime) supposedly designed specifically for web pages does not support this important feature.
Well, understandable URLs can actually be a problem. I point out a tutorial on Uberhacker.Com that actually shows why it is. If someone is able to look at a URL and "understand" it, you can do quite a bit of damage. For example : somesite.com/index.php?cmd=del&msg=456 From looking at this somewhat "memorable" URL, it is easy to see what it does. Also, if the particular site has no protection with it's delete command, it would be easy to reak havoc across the site.
To state the obvious, no shit. Of course you're going to have problems with the ficticious URL and system you presented. Somewhat of a straw-man argument there.
Now here's what I suggest: Don't combine "content" pages/scripts with "action" pages/scripts. What I mean is, have a script that does the adding/deleting/renaming/whatever and then does a 302 Temporary redirect (back) to the page/script that actually displays the data.
This has the following advantages:
As for authentication and protection, well that's a different matter. It doesn't really have much to do with URL's. Use cookies and even SSL to nail things down.
1) Some of these patches may introduce subtle bugs into interactions with 3rd party libraries (that covers pretty much most of the major function()s in PHP)
2) Some of these patches may introduce performance hits which would not be acceptable for some uses.
3) If you are running a large hosting company these patches may subtly break scripts being used by customers, tech supportality ensues.
4) Since this is a fairly new project, not even to a 1.0 release the pace of change may be so fast that it's more trouble than it's worth for the PHP and HPHP guys to keep making patch after patch as api's and such change. This way, the HPHP guys can toil away, making whatever internal changes they need to to achieve the securing of PHP.
I'm not saying this isn't a good idea, just I don't think it's the right time for this to happen, when the codebase has settled down maybe, but with the imminent move to the Zend Engine 2 and PHP 5 they may have to start from scratch (don't quote me on that however, it could be trivial for all I know!).
I am NaN
Just because things all go through index.php and are routed on from there in Fusebox doesn't make the url difficult to understand if you use mod_rewrite to pretty up (and make search engine safe) the url.
:o)
Seriously, have a look at Fusebox for PHP (or coldfusion, ASP or $favourite_scripting_language), it has increased productivity and code reuse in our company.
The other nice thing is naming conventions have you putting your "action/logic" code into files prepended with act_ and your display code into files prepended with dsp_, helping somewhat to enforce the notion of MVC. When used with a templating engine such as smarty however there is no other way to do it and one of my pet gripes with php (the mixing of logic and display) is banished forever
I am NaN
Basically, plan, plan, plan is what I do. It helps me spot stupid errors that I have made before I code them.
Also, code slowly a bit at a time and always look at your project from a security point of view (unlike InvisionBoard, god that has so many holes in it) and find a compromise between features and security.
thats my 0.02
First off, the index of that site handles content. That is all (I made it). Second, I could care less how obscure the links are. Bookmark it, or go to the site. All pages in my site (so far) are only three links deep. Second, if you are a secure scriptor in the first place, you will never run into any of those issues. Also, why does my code need to be clear to someone else ? I am the one using it, and if it is not clear to a Hacker, I have no problems.
Before someone else lashes out at Microsoft for analagous reasons, I don't think such an analogy would be entirely fair. While it is a server admin's responsibility to secure his/her server(s), and it is a software company's responsibility to secure its operating system(s), the tasks are not the same or even on the same level.
:-P
But to support cnf's point, I'm neither a server admin nor a software developer for Microsoft, and I'm watching South Park so I can't concentrate on explaining why it's not a good analogy... But I thought it was a good idea.
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.
It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
orionserver.com
The Raven