×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

March To Be Month of PHP Bugs

kdawson posted more than 7 years ago | from the open-season dept.

PHP 292

PHP writes "Stefan Esser is the founder of both the Hardened-PHP Project and the PHP Security Response Team (which he recently left). During an interview with SecurityFocus he announced the upcoming Month of PHP bugs initiative in March." Quoting: "We will disclose different types of bugs, mainly buffer overflows or double free (/destruction) vulnerabilities, some only local, but some remotely triggerable... Additionally there are some trivial bypass vulnerabilities in PHP's own protection features... As a vulnerability reporter you feel kinda puzzled how people among the PHP Security Response Team can claim in public that they do not know about any security vulnerability in PHP, when you disclosed about 20 holes to them in the two weeks before. At this point you stop bothering whether anyone considers the disclosure of unreported vulnerabilities unethical. Additionally a few of the reported bugs have been known for years among the PHP developers and will most probably never be fixed. In total we have more than 31 bugs to disclose, and therefore there will be days when more than one vulnerability will be disclosed."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

292 comments

So, PHP means ? (4, Funny)

Rastignac (1014569) | more than 7 years ago | (#18080450)

Public Holes Publication, isn't it ? ;)

Re:So, PHP means ? (2, Insightful)

Dimentox (678813) | more than 7 years ago | (#18080710)

Actually PHP is not that insecure.. Its the people who do not know hjow to write code who are insecure. You blame PHP. I blame peole who actually think they can program but are nothing more but scripters. PHP can be secure. If you write it correctly. Think about the script kiddys who use automated perl scripts.. Should perl not be on systems? If you want real security unplug your machine.. it will be safe. Otherwise any machine can be vouln.

Re:So, PHP means ? (5, Insightful)

Anonymous Coward | more than 7 years ago | (#18080802)

No, PHP is quite insecure. The libraries, the interpreter, and most PHP software are all poorly written.

And if inexperienced scripters is really the major problem, then the PHP developers need to take them into account when developing PHP. This means that the PHP developers need to add features to their product that help prevent such inexperienced people from writing easily-exploitable scripts. There has been some work done in this area, but it's been minimal, and so far ineffective.

Yes, inexperienced developers probably are responsible for many of the problems. But the more experienced (I would hope) developers of PHP itself need to step up to the plate, and do their part to deal with the problem of inexperienced developers writing poor code. Even if they don't do it in order to offer a better product, they should do it to save the few remaining strands of their reputation.

Re:So, PHP means ? (1)

Dimentox (678813) | more than 7 years ago | (#18080844)

right they do indeed need to step up. BUt my mainj point being that just having php installed does not open up the machine to be hacked.

Re:So, PHP means ? (2, Interesting)

JoelMartinez (916445) | more than 7 years ago | (#18081350)

And if inexperienced scripters is really the major problem, then the PHP developers need to take them into account when developing PHP. This means that the PHP developers need to add features to their product that help prevent such inexperienced people from writing easily-exploitable scripts.
Microsoft calls this the pit of success ... where it's easy to "fall into" a successful implementation

Re:So, PHP means ? (1)

milamber3 (173273) | more than 7 years ago | (#18081016)

Think about the script kiddys who use automated perl scripts.. Should perl not be on systems?
You are confusing the ability to use a script written in a specific language to exploit a hole with security vulnerabilities that are inherent in a particular language.

If you are making that mistake you should probably not be flaming anyone.

Re:So, PHP means ? (5, Interesting)

daeg (828071) | more than 7 years ago | (#18081062)

The problem isn't just the coders, it's the fault of the language, too. Sure, you can write fairly secure PHP code, but the language itself does not lend itself to teaching security. It's plainly evident that most features have "ease of use" ahead of "security" -- Register Globals is a prime example. I could have told you from the start that registering variables based on the names of POST/GET values was a Bad Idea(tm). Hell, anyone could have.

PHP is also forever afraid of breaking backwards compatibility. They probably don't want to scare PHP coders.

They also have issues around the monolithic nature of PHP. Oh, you want image processing? Recompile PHP! Oh, you need XML processing? Recompile PHP! There is no isolation whatsoever, everything resides in the same namespace.

I am glad that they are making progress, though. PHP 5 finally brought their OO up to speed (mostly). They finally have a secure, native database connector (PDO) that supports escaped bound parameters. PHP 6 is finally removing some deprecated features.

That said, I still am weary when I log into a website that holds my personal information and see a ".php" URL.

(I was a full time PHP developer for about 6 years. Was.)

Re:So, PHP means ? (2, Informative)

onerob (976438) | more than 7 years ago | (#18081406)

Register Globals has been off by default for years.

Please don't let us see the return of \'magic quotes\'

Re:So, PHP means ? (1)

jdbartlett (941012) | more than 7 years ago | (#18081428)

You've just summed up--in one short comment--everything I hate about PHP. I've been a PHP developer for several years and it was my first introduction to the OSS community, but I still remember that wild discovery: "You mean have to take down the entire service just because it wasn't compiled against this or that library? That's INSANE! What the hell is Linux FOR?"

Re:So, PHP means ? (1)

rufus t firefly (35399) | more than 7 years ago | (#18081588)

You've just summed up--in one short comment--everything I hate about PHP. I've been a PHP developer for several years and it was my first introduction to the OSS community, but I still remember that wild discovery: "You mean have to take down the entire service just because it wasn't compiled against this or that library? That's INSANE! What the hell is Linux FOR?"

I understand the point you're making, but why don't you just run it in CGI mode if you don't want to recompile, or use dl() to load the extension you want at runtime? I can't fault a language for needing extensions to be compiled ... it's more the fault of it being an Apache module than anything, since it simply needs to be reloaded to "see" its new modules.

Re:So, PHP means ? (2, Interesting)

tinkertim (918832) | more than 7 years ago | (#18081632)

Actually PHP is not that insecure.. Its the people who do not know hjow to write code who are insecure. You blame PHP. I blame peole who actually think they can program but are nothing more but scripters. PHP can be secure. If you write it correctly. Think about the script kiddys who use automated perl scripts.. Should perl not be on systems? If you want real security unplug your machine.. it will be safe. Otherwise any machine can be vouln.


You are correct, but that doesn't make net irritants that are permitted by insecure setups any less irritating. One of the biggest problems that come to mind are shared web hosting providers who have no choice but to run php 'wide open' allowing almost all functionality and without the benefit of phpsuexec to find what sites they host are letting the bots in.

They have no control or knowledge of what people upload. Someone could upload a 2 year old copy of phpBB they had on CD, not knowing any better and now you have a gigabit connected spam cannon hurling garbage at the rest of us.

I'm not saying its *just* shared hosts that (help to) give PHP the reputation its been getting, but they are a major contributor. Some take proactive measures to try and at least curtail it, most do not.

Its going to be a 'fun' month for those of us who have to deal with abuse issues. That is more than certain. I think I speak for many when I say : "Aww, SHIT."

Maybe he could stagger it out (1)

SlappyBastard (961143) | more than 7 years ago | (#18082022)

Give people a day or two to respond to each exploit before he hands us another to go racing after.

great... (5, Informative)

blantonl (784786) | more than 7 years ago | (#18080460)

Looks like this will also be "Month-of-me-working-harder-to-make-sure-my-site-i s-patched- and-updated-and-not-exploited-by-script-kiddies"

Re:great... (4, Insightful)

FredDC (1048502) | more than 7 years ago | (#18080500)

As opposed to "month-of-script-kiddies-working-hard-to-exploit-n on-patched-and-non-updated-websites"?

Your site is likely already compromised. (0)

Anonymous Coward | more than 7 years ago | (#18080594)

Maybe you shouldn't bother with the patches. If you're running any of the well-known PHP software, there's a good change your server has already been compromised by one or more such script kiddies.

I worked at a somewhat popular web hosting company for a while, and you wouldn't believe how often PHP sites are exploited. Most of the time the site owner had no idea that their site had been compromised in some way, even those who went out of their way to ensure that they were running the latest version of whatever PHP software they were using.

Re:Your site is likely already compromised. (1)

julesh (229690) | more than 7 years ago | (#18080626)

Maybe you shouldn't bother with the patches. If you're running any of the well-known PHP software, there's a good change your server has already been compromised by one or more such script kiddies.

I actually persuaded my business partner to authorise a 2-month long project to reimplement all the features we need from phpBB from scratch, rather than use original code, just for this reason. It didn't take much work to convince him that we didn't want the hassle of having to deal with regular [netcraft.com] 0-day [netcraft.com] exploit [astahost.com] scripts in the wild.

Re:Your site is likely already compromised. (1, Informative)

Anonymous Coward | more than 7 years ago | (#18080698)

Most likely, you're correct.

Still, there are precautions to take when running a common PHP-based app. First off, use Xen. Set any filesystem to read only (through Xen) that you can get away with. When installing PHP, only install the modules the script actually uses. Second, install mod_security and enable every possible protection. Third, install Suhosin (hardened php, Debian Etch has it packaged). Fourth, edit the php.ini file and enable safe mode and disable every possible feature you can get away with. Fifth, for the DB create multiple accounts. Use the permissions properly. Set it so that the user the script has only can update the specific tables it has to, deny it from everything else.

Still, it will only be a matter of time before it's compromised but at least those steps help. Make sure to make regular database and file backups from the Dom0 so it will be easier to restore the site.

PHP really needs to enforce proper security. In 5.x it's OO is actually pretty nice and I like doing development with it, but I've dropped it for Java due to constant security issues.

Re:Your site is likely already compromised. (1, Insightful)

Anonymous Coward | more than 7 years ago | (#18080738)

With all the effort necessary to set up Xen, strip out unused modules, fuck around with configuration settings, test it all out, etc., etc., it's probably just easier, cheaper and safer to go with something other than PHP.

Re:Your site is likely already compromised. (1, Informative)

Anonymous Coward | more than 7 years ago | (#18080980)

You're absolutely correct.

However, you'll probably run into a situation where the customer demands a certain poorly written php app. In those cases you have to go through the extra effort and deal with the inevitable compromise.

PHP is a nice language, but it needs to enforce proper security. If that security breaks apps, tough shit. Fix the broken apps.

Re:great... (2, Insightful)

bconway (63464) | more than 7 years ago | (#18080654)

Well, to be fair, you did choose to use PHP, which is notoriously buggy and insecure.

Re:great... (1)

Dragonslicer (991472) | more than 7 years ago | (#18080760)

If it's so buggy and insecure, why do so many large (and small, like the one I work for) companies have sites that use PHP and don't have problems with PHP-caused bugs or security holes? The existence of crap written by a 12-year-old like phpBB and phpnuke does not prove that the language is buggy or insecure. Idiots will write bad code in whatever language you put in front of them.

Re:great... (0)

Anonymous Coward | more than 7 years ago | (#18080922)

If it's so buggy and insecure, why do so many large (and small, like the one I work for) companies have sites that use PHP and don't have problems with PHP-caused bugs or security holes?

They surely do. They just aren't aware of them. But once they get a $80,000 bandwidth bill, because some spammer compromised their server and used it to send out billions of spam messages, they'll realize that they've got a little bit of a problem on their hands.

Re:great... (1)

MicrosoftRepresentit (1002310) | more than 7 years ago | (#18080942)

Except .NET! It is actually scientifically impossible to write insecure code in .NET. Also, exploits are impossible to write in managed code, and have to sit in their own un-managed blocks. This is because of the generational automatic garbage collector which will instantaneously garbage collect all exploitable or insecure codepaths using FXCop.

Re:great... (1)

joebp (528430) | more than 7 years ago | (#18081080)

This is about bugs in PHP itself, not applications written in PHP. Both have an utterly appalling security record though.

Re:great... (1)

rufus t firefly (35399) | more than 7 years ago | (#18081668)

This is about bugs in PHP itself, not applications written in PHP. Both have an utterly appalling security record though.

I'm not sure how I feel about that statement.

I'm the primary developer of an opensource PHP-based application, and I can attest that PHP security is more in the hands of the application developer. Yes, we've all heard some of the stupid PHP Nuke exploits, people not quoting their SQL properly ... but should the PHP interpreter developers really be held accountable for other peoples' shoddy coding practices? How many of the bugs in the wild that you're referring to are actually PHP application developers who don't know their ass from their elbow and don't bother to patch known vulnerabilities in a timely fashion?

I understand it has become fashionable to dump on PHP whenever languages are being discussed, but I believe, and have for some time, that it's not the language (unless you run up against intrinsic limitations of said language), but how people choose to develop in it. I'm sure there are secure VB apps, just as there are shoddy crashy Java apps out there.

Re:great... (3, Insightful)

Bastard of Subhumani (827601) | more than 7 years ago | (#18081736)

If it's so buggy and insecure, why do so many large (and small, like the one I work for) companies have sites that use PHP
I'm sure there's a fancy Latin name for it, but what you're saying is equivalent to "Eat shit - a billion flies can't be wrong".

Re:great... (2, Insightful)

kestasjk (933987) | more than 7 years ago | (#18080732)

I'm a PHP enthusiast with a few servers running PHP apps, and I say bring it on. If such a small team can look for and find so many bugs I doubt a determined attacker would have much problem anyway.
I'm sure that after the dust has settled PHP will be more secure than it was, and that can only be a good thing.

Re:great... (1)

mobby_6kl (668092) | more than 7 years ago | (#18080862)

I'm sure that after the dust has settled PHP will be more secure than it was ...

That's like saying that the ocean will be more wet after it's been raining for a day than it was before.

NM (1)

mobby_6kl (668092) | more than 7 years ago | (#18080982)

Disregard that post, I should have previewed and read it again before submitting. It actually makes it sound like PHP is the OpenBSD of scripting languages, which is obviously the opposite of the desired effect.

Re:great... (2, Informative)

miyako (632510) | more than 7 years ago | (#18080734)

This comment reflects what seems to be one of the biggest misconceptions in computer security. People seem to be under the impression that vulnrabilities are magically conjured into existance when the bugs are made public.
The fact is that the bugs have really been there the whole time, and just because we didn't know about it doesn't mean that some nefarious person didn't know about it.
Now, script kiddies might not know about the vulnrabilities until they are made public, but they are called script kiddies because they use scripts- usually written by someone who has an inkling of what they are doing.

Re:great... (1)

julesh (229690) | more than 7 years ago | (#18081554)

This comment reflects what seems to be one of the biggest misconceptions in computer security. People seem to be under the impression that vulnrabilities are magically conjured into existance when the bugs are made public.

Well, yes, but the fact is that there is incalculably higher risk from an unpatched, publicised bug (especially if more than a few weeks old) than there is in an unpublicised one. Almost all exploits occur using well known bugs, even if you discount worms.

Re:great... (3, Funny)

elrous0 (869638) | more than 7 years ago | (#18080800)

Hey, my un-fashionable use of Perl finally pays off!

[Ducks down and hopes next month isn't the "31 days of Perl Bugs"]

-Eric

Look on the open/bright side. (2, Informative)

kale77in (703316) | more than 7 years ago | (#18080972)

The bright side, it seems to me, is that PHP's openness means even if the developers are slack, the bugs can still be disclosed without IP litigation threats.

Also, he's given the developers a week or two of warning before March. If there's anything *that* serious in there, actually known to the developers, the fix could conceivably be ready by the time the bug is announced.

I run PHP sites, and I'd rather see the bugs public and being patched, than known only to the developers (we hope).

Re:great... (1)

Mr. Underbridge (666784) | more than 7 years ago | (#18080984)

Looks like this will also be "Month-of-me-working-harder-to-make-sure-my-site-i s-patched- and-updated-and-not-exploited-by-script-kiddies"

Well, if the article is to be believed and the PHP team hasn't much cared about some of these bugs, patching and updating won't help you. In any event, these bugs won't be fixed live. So they will result in potential compromise you won't be able to stop, likely.

In other words, this will also be "Month-of-you-getting-bent-over-by-open-security-h oles-in-PHP-you-can't-do-anything-about"

Re:great... (1)

suv4x4 (956391) | more than 7 years ago | (#18081278)

Looks like this will also be "Month-of-me-working-harder-to-make-sure-my-site-i s-patched- and-updated-and-not-exploited-by-script-kiddies"

You can thank the PHP internals and Zend about this. Having to deal with them at some points, they are literally like having to handle a bunch of spoiled children on a mission to have fun on your expense.

I've said it plenty of times and I'll say it again: PHP is going down, fast. The only reason to use it right now, is because there's still some money to be made from clients with PHP sites, or clients who wants to pay thousands for a site, but only few bucks/month for your average PHP host (I know.. I don't get it either).

(Much) faster, more stable and more consistent alternatives currently include Mono (C# - an excellent language), Python, Java and possibly Ruby 2.0, from the looks of it.

Re:great... (1)

bradword (806343) | more than 7 years ago | (#18081416)

If this is anything like the month of apple bugs, they'll release one or two bugs actually associated with apple, then talk about bug that are third party add-ons. The months of apple bugs was a big disappointment. If this actually comes through and makes php more secure, then more power to him.

even if... (3, Insightful)

cosmocain (1060326) | more than 7 years ago | (#18080488)

...there are that much holes in PHP (which i don't doubt), mr. esser seems to be on a kind of crusade since he left the security response team.

Re:even if... (5, Informative)

Alphager (957739) | more than 7 years ago | (#18080572)

He began his crusade when he founded the security-team: He wants a secure PHP. He left the security-team out of frustration that the main devs didn't care about security (leaving security-critical bugs unfixed for ages). This month of PHP-bugs is his effort to put pressure on the devs to finally make security a priority.

Re:even if... (0)

Anonymous Coward | more than 7 years ago | (#18080618)

that should be "because he thinks that the main devs didn't care about security"

Re:even if... (1, Insightful)

HBI (604924) | more than 7 years ago | (#18080674)

I imagine if he'd written the patches to fix the problems they wouldn't have had any excuse not to accept them.

This stinks of self-promotion. Calling something a "Month of PHP Bugs" does nothing to improve PHP's reputation. It sounds spiteful, in fact.

Releasing an exploitable bug every day rather than just writing the code to fix it sounds really lame, too. The people being harassed by this are the people running PHP.

I bet a lot fewer people will be after this month.

Re:even if... (1)

Chris_Jefferson (581445) | more than 7 years ago | (#18080684)

For many of these bugs he did write code to fix them. However he couldn't get the patches accepted into the PHP mainline.

Re:even if... (1)

HBI (604924) | more than 7 years ago | (#18080706)

So why didn't he fork the project then? That seems like a legitimate excuse.

Re:even if... (1)

moranar (632206) | more than 7 years ago | (#18080756)

Maybe he didn't think it would make any difference? Forking PHP wouldn't change the countless developers who don't know nor care about security, the thousands of servers with PHP already there, plus it'd have to get a sizable team to carry it forward. Seriously, if you really want a secure language for the web, you don't stop at PHP.

Maybe what he cared more about was security, not the language.

Re:even if... (4, Insightful)

moranar (632206) | more than 7 years ago | (#18080920)

Or maybe, just maybe, on reading the article we'd find he did "fork" PHP, through Hardened-PHP and Suhosin. The wonders never cease.

Re:even if... (0)

Anonymous Coward | more than 7 years ago | (#18080834)

He releases patches [hardened-php.net] instead.

Re:even if... (1)

cosmocain (1060326) | more than 7 years ago | (#18080736)

sure - i understand the frustration that's driving him. and i guess the MoPHPb will wake some folks up, hopefully the devs. but it'll wake up script-kiddies, too. in fact, that's what i fear most, it might only wake up the script kiddies, as the devs didn't seem to care in the past and that leaves more than thirty unpatched publicly documented security holes and a few folks, who need to run php. what a lot of fun...

Re:even if... (1)

gmack (197796) | more than 7 years ago | (#18080836)

sure - i understand the frustration that's driving him. and i guess the MoPHPb will wake some folks up, hopefully the devs. but it'll wake up script-kiddies, too. in fact, that's what i fear most, it might only wake up the script kiddies, as the devs didn't seem to care in the past and that leaves more than thirty unpatched publicly documented security holes and a few folks, who need to run php. what a lot of fun...

The script kiddies are already awake. The probes for PHP vulnerabilities are getting more common. The scripts they use to detect flaws in web servers are probing deeper than ever before and can now detect holes in custom PHP code.

This is all about waking everyone one else up so hopefully the problems will get fixed

Re:even if... (2, Insightful)

gmack (197796) | more than 7 years ago | (#18080782)

No.. it's a good thing. PHP apps are now the most common means of gaining a remote shell on Linux and as a sysadmin I have to constantly worry about what PHP code some customer installed can allow some attacker to break into my server. PHP allows some things it really shouldn't.. take includes on a variable for instance a few months back we had a machine spewing DoS attempts and the admin in charge of the box couldn't figure out how the attacker got a shell. The culprit? Some programmer used a variable to hold his includes and the attacker simply overrode that variable. Now you can (and we did) blame the programmer for being an idiot but the problem is that a language being sold as "great for anybody to start programming in" should be a lot safer by default I mean really.. what legitimate reason is there for that "feature" in the first place?

Re:even if... (1)

M. Baranczak (726671) | more than 7 years ago | (#18081178)

This "feature" was used for passing request parameters into the script. So there was a legitimate need for it, it was just implemented in a really bone-headed way, since it allowed the overriding of local variables if you weren't careful. This was fixed in version 5 - unfortunately, this meant breaking backwards compatibility, since most older scripts relied on the old way of passing parameters. So a lot of servers out there (I'm assuming yours is among them) are still stuck using PHP 4.

I wanted to like PHP, I really did. But shit like this just does not inspire confidence.

Hear, hear. (3, Insightful)

cortana (588495) | more than 7 years ago | (#18081968)

An anonymous coward said some time ago,

When I looked at Zend's introduction to PHP, the first sample PHP program was Hello World, and the second was a cross-site scripting vulnerability.

Blatant Self-Promotion (1)

Ron Harwood (136613) | more than 7 years ago | (#18081208)

This stinks of self-promotion. Calling something a "Month of PHP Bugs" does nothing to improve PHP's reputation. It sounds spiteful, in fact.

Yep. Everything he writes on this topic is along the lines of:

-They all suck.
-I'm the greatest.
-They're all out to get me.
-The fools, the laughed at me at the institute.
-You aren't taking me seriously! I've fixed everything in my personal extension to PHP and you keep breaking it by changing the language!

etc... etc...

I don't know what he thinks he's going to accomplish - but he's made his name synonomous with "shit disturber" and while he claims to be trying to make PHP better, he's only poisoning things in the long run.

Re:even if... (1)

tobiasly (524456) | more than 7 years ago | (#18081572)

This stinks of self-promotion.

Of course it's self-promotion. Why does the guy stick his picture on the front of the article?

Attention geek bloggers: You are not attractive. Stop [networkper...edaily.com] posting [securityfocus.com] pictures [zdnet.com] of your dorky [zdnet.com] looking [businessweek.com] selves [pcmag.com] at the top of your blog.

It doesn't make you look like a real journalist, it just makes you look like a tool.

(Note: in case you're wondering how I got so many pictures to prove my point, I simply looked up the fud tag [slashdot.org] on Slashdot and started clicking away :)

Re:even if... (0)

Anonymous Coward | more than 7 years ago | (#18081644)

Haha,

what kind of drug are you using?

there is no photo of esser at all anywhere near the interview...

i suggest for next month (3, Funny)

Anonymous Coward | more than 7 years ago | (#18080494)

month of PCP bugs. i see them all over my skin and i can't scratch them off! SOMEONE HELP ME

Partially surprising (5, Insightful)

Anonymous Coward | more than 7 years ago | (#18080512)

I really shouldn't be surprised at the PHP team's approach to security any more, but it really does still surprise me from time to time. It's amazing, but the PHP team are worse than Microsoft ever were with security. And they don't even learn from this - they've had this attitude for as long as I can remember (PHP 3 days), and they just aren't getting it. Or rather, if they get it, they just don't care.

PHP is a disgrace to the open source community. (5, Interesting)

Anonymous Coward | more than 7 years ago | (#18080652)

It's amazing, but the PHP team are worse than Microsoft ever were with security.

This is very true. And also very unfortunate. When it comes to many managers, PHP has given the entire open source community a bad name. This is mainly because it has been repeatedly pushed as being part of the LAMP suite, when in fact Python and Perl are far better options for the 'P'. So when you recommend the use of Linux, Apache or MySQL, they automatically think of PHP, and recall how terrible its security is. And then they associate that lack of security with Linux, Apache and MySQL, even when that's not the case!

If there's one thing the open source community as a whole should do, it should be to disown PHP. Responsible open source developers and projects need to just stop using it for their web sites. It'd be good if more things like this Month of PHP Bugs were held, just to show the public that the OSS community knows that PHP is terrible, and wants to do something about it. The longer we continue to use PHP, the harder it will be to repair the reputation of even completely unrelated (and far more secure) open source projects.

Re:PHP is a disgrace to the open source community. (4, Insightful)

archen (447353) | more than 7 years ago | (#18081864)

The problem with PHP is that it's very easy. One of the supposed advantages of Lamp is that it is also rather easy to set up and work with. I've seen more projects than I would care to, where the programmers couldn't code their way out of a paper bag but managed to accumulate a surprisingly functional mass of PHP spaghetti code. Perl is a good option only if the coders are disciplined, and having good structure is critical for a good Perl project. I don't have any experience with Python, but due to the nature of python language structure, you'll never be able to embed it the way you could with PHP (templates are necessary here as well).

One of the problems with PHP is the fact that when the bar of entry is so low, you get a lot more low bar people actually coding it. It's become the next generation of VB garbage. The language is only half of the security problem (a half we could better do without, but still).

Re:Partially surprising (2, Interesting)

julesh (229690) | more than 7 years ago | (#18081412)

I really shouldn't be surprised at the PHP team's approach to security any more, but it really does still surprise me from time to time. It's amazing, but the PHP team are worse than Microsoft ever were with security. And they don't even learn from this - they've had this attitude for as long as I can remember (PHP 3 days), and they just aren't getting it. Or rather, if they get it, they just don't care.

I'm not surprised. Their attitude to bug reports in general is pretty hostile. See, for instance, this report of a segmentation fault bug [php.net] .

Re:Partially surprising (0)

Anonymous Coward | more than 7 years ago | (#18081624)

Well, his name *was* sniper@php.net. What else could you expect besides 'user error'? ;-)

For once (4, Insightful)

Timesprout (579035) | more than 7 years ago | (#18080514)

I am actually glad to see one of these xxx month of bugs. Personally I have always thought PHP to be a steaming pile of poorly thought out garbage but there is no denying its popularity despite its flaws. Anything that actually helps the meme 'most php flaws are caused by poor programmers' actually become a reality by improving the core security of the language is therefore to be welcomed.

Re:For once (1)

nottestuser (166818) | more than 7 years ago | (#18080556)

The meme is true but only because for each of the 100 flaws in PHP itself there 1M programmers who don't know a single thing about any of the OWASP top 10.

Re:For once (2, Insightful)

jimicus (737525) | more than 7 years ago | (#18080702)

Anything that actually helps the meme 'most php flaws are caused by poor programmers' actually become a reality

Most flaws in any code are caused by poor programmers. It's possible to write clearly structured, well laid out code in BASIC (no, not visual BASIC, the real thing), as most implementations support things like local variables and procedures. It's just exceptionally rare.

This is why so many computer science degrees (at least until recently in the UK) used Modula-2 or Pascal as their primary teaching language. Don't for one moment imagine the lecturers thought that these languages would be useful in the real world - the idea was to teach good practise.

Re:For once (0)

Anonymous Coward | more than 7 years ago | (#18080832)

This is why so many computer science degrees (at least until recently in the UK) used Modula-2 or Pascal as their primary teaching language. Don't for one moment imagine the lecturers thought that these languages would be useful in the real world - the idea was to teach good practise.
Huh? Since when is Pascal not a useful real-world language? This is the first time I've ever heard this claim.

Re:For once (0)

Anonymous Coward | more than 7 years ago | (#18081714)

Absolutely, 99.9999% of software flaws are caused by poor programmers, with the 0.0001 remaining ones caused by dirt and coffee drops inside the keyboard.

Install modsecurity (5, Informative)

HxBro (98275) | more than 7 years ago | (#18080532)

I recently installed modsecurity http://www.modsecurity.org/ [modsecurity.org] for apache along with the rules from http://www.gotroot.com/ [gotroot.com] and it's done a good job of blocking attacks on my server including a lot of the php mail() injection attempts, whilst it has shown up a few false positives like someone posting a message with sql keywords e.g. "select" "from", it is certainly worth installing even if you have to monitor the logs for a bit afterwards to watch for the false positives and alter the rules accordingly.

Whilst it probably won't solve a lot of the problems with php and security it does help protect the server especially when you don't have control over what your users are uploading to their web space.

We audited PHP for some of our projects. (-1, Troll)

Anonymous Coward | more than 7 years ago | (#18080568)

As a vulnerability reporter you feel kinda puzzled how people among the PHP Security Response Team can claim in public that they do not know about any security vulnerability in PHP, when you disclosed about 20 holes to them in the two weeks before.

Only 20?! We recently audited several versions of PHP for a project we are developing at work. We didn't have high expectations of it going in. I mean, we were all aware that it has a fairly poor security record, but we had heard that there had been improvements recently, so we gave it a shot. Damn, did it fail badly.

I think the one word that describes it best is "shitty". The semantics of the language are shitty. The standard libraries are shitty. The database interfacing support is shitty. The interpreter is shitty. The performance is shitty. Most of the web apps written using it were absolutely shitty.

We decided to go with Django instead. At least Python is a sensible language, with a well-developed standard library modules, and a high-quality implementation. It's easy to see that Python was developed by people who had some background in programming language theory, as well as in real-world software development. PHP, on the other hand, seems like it was thrown together by a bunch of kids. It does not appear that much thought, if any, went into actually designing it. Maybe that's why it suffers from so many security flaws.

Re:We audited PHP for some of our projects. (2, Informative)

clawoo (945374) | more than 7 years ago | (#18080828)

Not to start a little argument over PHP and Python, but you're comparing apples with oranges here. You are saying that PHP is insecure, its semantics are undesirable and so are its standard libraries, database interfacing, interpreter and performance, and then you come along saying how awesome Django is, disregarding that actually you're comparing a language with a framework.

There are a handful [cakephp.org] of decent [xisc.com] PHP frameworks [symfony-project.com] out there, with others coming along [zend.com] , which you can take and compare with Django, but please don't bash the language because you don't like its semantics, you have something personal with it or you didn't take the time to choose a decent framework.

Regarding the database interfacing support, I beg to differ, I believe PHP has been supporting a large number of databases for a longer while than most of the other web scripting languages out there today.

Re:We audited PHP for some of our projects. (1)

xtracto (837672) | more than 7 years ago | (#18081610)

Well, I do not have a lot of experience with PHP (only some typical unsecure LAMP tests) but after looking what they did with mysql_real_escape_string() [php.net] and mysql_escape_string() [php.net] I agree with GP. What kind of programming language is that? what the heck does REAL is supposed to mean?

I have programmed in PHP and C#/VB.NET for web forms (back when .NET was just out) and I can tell you that even there, the microsoft product was better than PHP. One of the things I dislike about PHP and I liked about the WebForms .NET approach is the separation of the interface with the functionality which allowed us to create a real multi tier application. I have not programmed "for real" web applications for some time but as far as I know it is not possible to do that sepparation with PHP.

Re:We audited PHP for some of our projects. (1)

julesh (229690) | more than 7 years ago | (#18081858)

after looking what they did with mysql_real_escape_string() and mysql_escape_string() I agree with GP. What kind of programming language is that? what the heck does REAL is supposed to mean?

It's a backwards compatibility hack. When they implement mysql_escape_string, the MySQL C API didn't need a connection object to the server to perform quoting, it just did it locally. Some advanced features were added in later MySQL versions, and a connection to the server is now needed in order to know what character set is in use in order for the quoting to be performed correctly. If you're just using us-ascii/iso-8859-1 like most MySQL developers, you can ignore the difference. If you're using UTF8 or some other charset, you need to make sure you use the "_real_" version.

The whole 'mysql_*' API ought to be deprecated anyway. mysqli is much better.

Re:We audited PHP for some of our projects. (1)

julesh (229690) | more than 7 years ago | (#18081886)

One more thing:

One of the things I dislike about PHP and I liked about the WebForms .NET approach is the separation of the interface with the functionality which allowed us to create a real multi tier application. I have not programmed "for real" web applications for some time but as far as I know it is not possible to do that sepparation with PHP.

As somebody who has written a 3-tier web application in PHP for a well-known multinational company, I can assure you that tier separation is not only possible in PHP, it's actually fairly easy. Just don't try forwarding remote session IDs to the middle tier from the front tier and then running them on the same server. It won't work.

Mod me troll-down... (0)

Anonymous Coward | more than 7 years ago | (#18080576)

But to me (and I'm not the only one), PHP is a huge security hole. There are people that consider machines running PHP insecure. Mod me down, but it's a fact.

Are bugs the problem? (4, Interesting)

cerelib (903469) | more than 7 years ago | (#18080634)

I always had the feeling that the bad security reputation with PHP had less to do with technical bugs and more to do with how easy it is to write insecure code(especially when using the mysql module). Also at fault is the general lack of programming understanding by the amatuers who find their way to PHP because it is so easy to go from having a static HTML page to a dynamic PHP page. Are there a lot of vulnerabilities in the interpreter?

Re:Are bugs the problem? (1)

CodeShark (17400) | more than 7 years ago | (#18081036)

Poor code writing and a failure to integrate known fixes is the problem. For example, code/modules developed by the Hardened PHP project referenced earlier has fixes many of the known vulnerabilities, and in general PHP 5.X is much more secure than prior versions.



Personally while I don't necessarily like all the work I have to do when there is a "bug exposure" in the media for tools I am using -- like PHP -- I don't have time to track everything let alone fix them, this "month of bugs" won't affect me as much because the ISP I use for my sites has historically been very good at fixing the server-based bugs, and alerting me when a known application error is widespread in the code base so that I can scan my modules and do the updates. That's where paying more than $3.95 a month for a GOOD php web hosting service is a pretty good exchange of $ for peace of mind.

Re:Are bugs the problem? (1)

Peter (Professor) Fo (956906) | more than 7 years ago | (#18081256)

Well it's like this : Most car crashes are caused by drivers but some are caused by defective design and materials. Others are made worse by 'misleading' the driver (I have ABS so I can stop in 6 feet on ice) or encouraging them to believe they're safe under all conditions (I can drive at 120 (a) 'cos the speedo goes up to 150 and (b) I've seen those videos with the crash dummies which don't seem too fatal.)

PHP is the same : It's easy to drive so naturally lots of people have a go. (Good Thing). Sadly many haven't got the foggiest idea about security, interface design, database design, maintainability or testing. Some will take this opportunity to learn a bit about these subjects but for most 'programming' is the same as 'getting code to work'.

If only someone would write a book. http://www.eminent.demon.co.uk/ob/Programming.htm [demon.co.uk]

Re:Are bugs the problem? (2, Insightful)

poot_rootbeer (188613) | more than 7 years ago | (#18081972)

I always had the feeling that the bad security reputation with PHP had less to do with technical bugs and more to do with how easy it is to write insecure code

Or even more likely, how easy it is to download and run insecure code written by some other lousy programmer. It's not the people who are writing their own CMS systems that are getting haxor'd, it's the people who grabbed a copy of PHPNuke and threw it up there on the 'net.

Wait... (4, Funny)

kahei (466208) | more than 7 years ago | (#18080662)


Only a month?

Ha ha, yes, thank you, I'll be here all week, bringing predictable yet mildly amusing banter. In fact, I'll be here all year. The whole of my life, probably. *breaks down and cries*

March To Be Month of PHP Bugs (1)

Edie O'Teditor (805662) | more than 7 years ago | (#18080672)

Nope, I'd rather be person than a unit of time and I'm sure as heck not walking anywhere to become one.

PHP needs to be fixed in general (2, Informative)

MikeRT (947531) | more than 7 years ago | (#18080690)

If he really wants to make a difference, he should fork PHP and really fix up the language and interpreter to his liking. Besides bug and security fixes, a standard naming convention for built-in functions would be quite nice. Maybe Esser could do for PHP what EGCS did for GCCS if he did that.

Re:PHP needs to be fixed in general (1)

ravenlock (693538) | more than 7 years ago | (#18080914)

Too late for that. There is a huge amount of custom web apps already written in PHP, and that's enough momentum to steamroller any attempt to make a decent PHP. Nobody wants to pay for a rewrite that "doesn't add value," because most customers don't care about vulnerabilities until they are already exploited. Time to look at solutions that were well thought out to begin with.

Re:PHP needs to be fixed in general (0)

Anonymous Coward | more than 7 years ago | (#18081186)

Too late for that. There is a huge amount of custom web apps already written in PHP, and that's enough momentum to steamroller any attempt to make a decent PHP. Nobody wants to pay for a rewrite that "doesn't add value," because most customers don't care about vulnerabilities until they are already exploited. Time to look at solutions that were well thought out to begin with.

Sounds to me like that same reasoning will keep those same people from rewriting things in any other language as well.

OK, seriously now... (1)

MattPat (852615) | more than 7 years ago | (#18080926)

Do we need a month dedicated to every application that has bugs in it? Because I'm pretty sure our sun will have imploded by then.

Take PHP outside web pages altogether. (0)

Anonymous Coward | more than 7 years ago | (#18081004)

Fork PHP. This is what they should do.

Do not let it execute inside web pages. X server pages is bad. Take PHP outside of web pages altogether. Good PHP programmers should be using Smarty templates anyways.

Make a good VM for PHP and clean up all the damn bugs. PHP has nice C/Perl syntax, it has the potential for a good general purpose language.

Create a "pervlet" container. No, not for perverts, but to serve PHP web objects much like Tomcat for servlets. Don't stuff everything inside Apache. Leave the front gate for security configurations and static pages.

That's it for now. Thank you and come again.

P.S The /. security image is the word "toasted". Haha nice!

Re:Take PHP outside web pages altogether. (1)

julesh (229690) | more than 7 years ago | (#18081782)

Do not let it execute inside web pages. X server pages is bad. Take PHP outside of web pages altogether. Good PHP programmers should be using Smarty templates anyways.

One way of looking at PHP is that it is an extremely powerful templating language. That's the job it was designed to do in the first place, anyway. So why not write your back end in a more powerful language and just do a quick front end templating job in PHP that takes those results and slaps them into a web page.

Oh, right, the reason not to is that PHP is just about the only common denominator you'll find at nearly any web hosting company you might choose to go with. I think this is just about the only reason not to though.

(I say, begrudgingly, as a PHP programmer who uses the language only because of this popularity factor)

PHP has nice C/Perl syntax, it has the potential for a good general purpose language.

I don't think so. There is at least one major flaw with its language design (and it's a basic, fundamental flaw that most people don't realise): there is no distinction between strings and identifiers. Try this:

It's an interesting choice: '$' becomes an unary operator that returns a reference to the value of its argument. So why doesn't work? God knows. It should, but it doesn't. Probably the same reason that functionReturningAnObject()->field doesn't work: the language definition is screwed up. $v = "t"; echo $$v; works fine though.

Reference semantics are screwed up as well. Try this:

$a = array (1, 2, 3, 4);
foreach ($a as &$b) $b++;
foreach ($a as $b) $b++;
print_r ($a);


Now, explain to me why it is that the last item in $a is incremented twice, while all the others are only incremented once?

The more features are added to it, the more evidence there is that at its core, PHP is a badly designed language.

P.S The /. security image is the word "toasted". Haha nice!

Did you post AC just so you could make that joke?

Re:Take PHP outside web pages altogether. (1)

julesh (229690) | more than 7 years ago | (#18081810)

Hmmm... The munged PHP code from my post was:

    (lack of quotation marks deliberate)

and

    (addition of quotation marks also deliberate)

As a non-programmer, what are the alternatives? (0)

Anonymous Coward | more than 7 years ago | (#18081070)

I've been running Gallery (& more recently Gallery2) and Serendipity on a server (recently updated to 5.2.1 with Suhosin) for some time now. There have been many posts here about not using PHP, but finding replacements for these applications which don't use PHP is either hard or bloody impossible. Is there a resource site which shows web apps which *don't* use PHP? What languages are better to look out for? Ruby on Rails? Python?

I'm not a programmer and never will be, so "Code your own!" doesn't work for me. If PHP is really so insecure then what are realistic alternatives?

TIA

In Other News (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#18081190)

The Computer Institute of Kazakhstan has declared March to be the Month of TRS-80 Bugs.

Re:In Other News (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#18081204)

Great Success!

Suhosin Extension (1)

metarox (883747) | more than 7 years ago | (#18081398)

On a side note, anyone know where I could find that Suhosin extension compiled as a binary (DLL) for windows ?

Coming in April (4, Funny)

bill_mcgonigle (4333) | more than 7 years ago | (#18081400)

"Month of Shooting Fish In a Barrel"

At least the Month of Apple Bugs was a hard target to go after.

Re:Coming in April (0)

Anonymous Coward | more than 7 years ago | (#18081622)

Apple a hard target? Bahahhahahaaahaha

Welcome to the social! (0)

Anonymous Coward | more than 7 years ago | (#18081656)

Enjoy your stay this month Mr. PHP.

Love,
    Artie MacStrawman

A Couple Easy Precautions (2, Informative)

corychristison (951993) | more than 7 years ago | (#18081890)

I've been running PHP for some time now, I try to use the latest and greatest, but sometimes I am a little behind.

Here are a few simple precautions for PHP configuration:
  • Do not(!) install cURL. I know it is useful, but has a lot of security problems!
  • Disable register globals [default as of 4.2.0]
  • Safemode is worthless and a little too restricting, use OpenBaseDir.
  • disable_functions = exec,system,passthru,shell_exec,proc_open,proc_clo se,proc_terminate,proc_nice,proc_get_status (may be more, off the top of my head :-)
These are what I can think of off the top of my head. This allows full compatability with all major scripts [mostly due to not using SafeMode] but still holds a fair bit of protection from people executing scripts and pushing them to run in the background. Had this happen to me a few years ago. I was hosting someone as a favour, and I'm not sure if they did it, or they were running some crappy code and it was exploited. Either way, their account was suspended.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...