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."
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.
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.
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.
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.
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, whoever came up with the idea that include and require could take an URL as argument should be slapped ...
Am I the only that disagrees with your technique?
I understand that the galleries of pics have to be filtered from a single database for each site, but there is a better way to do this.
Instead of writing dynamic pages, write an application that produces static pages based on the database. Whenever your content changes, re-run the applications to get fresh static pages.
Dynamic pages are just way too much overhead for what you're trying to accomplish.
Unfortunately mmcache isn't developed anymore, isn't it? :-/
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.
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.
Mine does too - yay for us :-)
:-)
I use PHP all the time. I know perl/mod-perl too but it doesn't have the install-base that php does - especially selling to people on shared hosting packages..
It's also kind of unusual to find cheapo shared hosting sites (on the adult side of things) who will let you run cron jobs or the like. Understandably
Speaking as someone who is familiar with both mod-perl and php and still does primary work in php, perhaps I can enlighten you.
The fact of the matter is that before mod-perl, getting perl to run as a scripting language required spawning perl processes for each request made to the server. This causes significant problems. PHP as a compiled in resource could be handled by the apache children themselves and did not suck up extra resources.
Now, that's not the case with perl any longer, but with any system that you have significant ammounts of time and other investments in, it's kinda hard to drop current production and switch back to perl.
Currently, since the new core for perl has been underway for a while and that will likely require a reworking of the code the decision has been made to hold off so that we don't have to rework the engine twice.
/* TODO: Spawn child process, interest child in technology, have child write a new sig */
I'm sorry, but I think you're nuts. Not to specifically knock the other choices you mention, but I think plenty of people feel that PHP has a far less annoying and convoluted syntax than say Perl or Lisp, which you seem to be advocating instead of PHP. And you say you have a "superficial familiarity" with PHP, yet knock PHP for a lack of Speed... Try it, you might be surprised (especially if you use a compilation cache like Turck MMCache). Why do you think every other random interpreted language is going to be way faster than PHP?
The only point I won't argue strongly is the security aspect. I don't think PHP is as bad as everyone is claiming if it is set up properly, but it isn't perfect - in particular too many ease-of-use features have been added that can chuck any semblance of security right out the window...
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
While all aspiring PHP-programmers should take the time to read the paper mentioned to understand why and how -- and to guard themselves against doing the same mistakes that we've all grown accustomed to over the years, it should be mentioned that almost all these default attack vectors has been taken care of during the years.
the default installation of PHP today makes people write a lot more robust code than it used to do. New applications has been able to move away from the 'ugly' things and a general understanding of what not to do has been developed by almost all active developers. If you've done serious PHP developement during the last years, you know how much further things has come.
mats
One man's ceiling is another man's floor.
That depends on whether the remote server is set up to execute the file.
If the remote server is set up to simply send the file as text, then the *local* server will execute the text. As a PHP script. As the local user. And your remote attacker has the ability to run any commands on the server that a local script could run (usually, "wget a rootkit from this other server, unzip it, and execute it...")
Believe it or not PHP-Nuke had that exact behaviour about a year ago. The problem wasn't including ordinary files. The problem is with PHP you can include http files. So just make a request action=http://myserver/phpscript.php that had system() calls and you basically had a non interactive shell that could upload and execute files as the httpd user. Which is much closer to an exploit than including a /etc/passwd (which doesn't work in PHP either btw, unless the httpd user has read permissions on that file).
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.