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 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.
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.
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 couldn't agree more with this poster. I think education of programmers in our Computer science educational instutiutions is lacking severly in teaching new programers about what dangers poorly written code can result in. I did a semester research project on the subject for my masters. (http://www.csee.umbc.edu/~cress1/cmsc791.html) All the educators I included in my project had very little if any clue about secure programming issues and after being presented with teaching alternatives were interested to include them in their curriculum. Does anyone else have any experiece where their professors hammered home the point that insecure and poorly written code can have catestrophic results?
Sig 'em boy!
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!
var sig = function() { sig(); }
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.
``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.
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
this is why if you're smart you configure your webserver to auto-prepend a script which does some basic security checks, things like validating sessions etc. plus you can set it up to know the names of what scripts can run when and where, and then create some code that checks what script was called and what variables were passed to it, and if it fails the checks for that script it wipes out all user variables, terminates script execution and logs an error.
I believe it would even be possible to get an md5 of the script that is being executed and compare it to a stored value.
These are all the kinds of things I'm working on for an application I'm developing. But the whole point is to create layers (onions have layers, ogres have layers, get it?) esp. those that force the entire enviroment to verify what it is running before it even runs it. Basically write things so that they can't run unless they are supposed to run then and there in that situation.
Say you have a program, and a certain page is opened, from that page you have possible actions. You need to create something separate which knows what actions can run from that page, and if something else is told to run that shouldn't be run. Or any other sort of thing similar to that, it terminates with a "friendly" error message and LOGS what happened, where it came from, the user name, etc.
And while I'm at it, other things to consider is if you use a cookie to allow a user to return to the site later and be logged in and have thier cart or whatever restored, you should:
On the server track the IP network that the cookie was set on, SERVER SIDE. When that cookie is used, and the computer is connecting from a different IP network require reauthentication. If you're more concerned about privacy, store the IP in the cookie, and some sort of one-way hash of it on the server then you can compare when they access the site. If it doesn't match, require them to reauthenticate. The whole purpose of this exercise is to prevent someone from using that cookie on another computer. This would be a bit of a hassle for mobile users, but still... Also always use a secure connection for authentication. If you use a cookie to allow a user to return, consider using two cookies, one which is for the main page which triggers a redirect to a secure page which then accepts the cookie to allow them into the site. Also at that point immediately destroy that old cookie, making it invalid, and reset with a new session ID and new verification info, and transmit it through this secure connection.
The whole point here is to make it more difficult for anybody looking at the packets flying around to find out this information and hijack that users session, and in effect compromising thier account. Other things to do are checks for the same account having multiple sessions at multiple locations, etc.
I have plenty of more thoughts on securing a web site, mainly e-commerce related. Yes you do more work to do all these checks, both programming and running it. But its worth it knowing that you're keeping things sane.
One other thing, anytime you do authentication, or anything with sensitive information, as soon as your script is done using that information, destroy those variables so that information is gone from RAM. The less time its sitting in RAM, the less chance there is for someone whose in that server to get it out of RAM. Of course this is improved tremendously if the server is configured to randomize the location of information in memory, since in this case it would be there for a fraction of a second in some random location--a little more difficult to get to I'd think.
Besides the dangers of bad code in general, PHP is particularly dangerous, with it's very flexible and network enabled features. It only gets worse because it is (apparently) so easy to learn and use and it makes everybody feel like a God of website making in no time flat. [Insert boss saying "hey, secretaries could write PHP without a problem" here].
The solution would be a very restrictive safe mode, which would freaking MAKE people watch what code they're writing and give up incredibly stupid and at the same time tricky stuff like using variables with globals enabled without any kind of previous cleaning or filtering. And the second half of the solution would be to throw out on their ass all the self-proclaimed PHP programmers who pull stupid stuff like this.
The first part won't happen because hosting services can't afford to break all the sites using globals and so on. The second half may happen, I dunno.
Meanwhile, hardened PHP won't mean much, I'm afraid. If a guy doesn't know enough to use an automated filtering class on his $_GET[] he won't know he needs Hardened PHP either, because he lacks severely where PHP security is concerned. You can lead a horse to water but you can't make it drink, right?
i ate crayons when i was a kid and now i have two braincells and the blue ones taste nicer
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.
Meanwhile, hardened PHP won't mean much, I'm afraid. If a guy doesn't know enough to use an automated filtering class on his $_GET[] he won't know he needs Hardened PHP either, because he lacks severely where PHP security is concerned. You can lead a horse to water but you can't make it drink, right?
How 'bout a link to or example of (a good) one?
this is my sig
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/