Slashdot Mirror
March To Be Month of PHP Bugs
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."
...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.
As opposed to "month-of-script-kiddies-working-hard-to-exploit-n on-patched-and-non-updated-websites"?
09 f9 11 02 9d 74 e3 5b d8 41 56 c5 63
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 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.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
Well, to be fair, you did choose to use PHP, which is notoriously buggy and insecure.
Interested in open source engine management for your Subaru?
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.
string sig = llGetSig("dimentox"); llSay(0,sig);
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.
// MD_Update(&m,buf,j);
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.
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.
Only three things are certain; death, taxes, and apocryphal quotations - Ben Franklin.
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).
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.
If he really wants to make a difference, he should fork PHP and really fix up the language and interpreter to his liking.
Err... he has.
Sometimes I think people don't read the articles.
Then I remember I'm reading slashdot.
In the case of SQL injection attacks, definitely yes. They provide add_slashes(), oh, but wait, that's insecure, so they provided mysql_escape_string() instead. Oh wait, that's insecure too, so they provided mysql_real_escape_string() instead. All the while, ignoring the fact that string concatenation is prone to security problems by its very nature, and ignoring the real solution — bound parameters — for years.
Bogtha Bogtha Bogtha
Really? Leaving aside the matter of using shared libraries, whenever I've had to add features to PHP it's gone like this:
The only actual downtime occurs during step 5, which lasts maybe a second at most. This is Linux after all -- you can run the old version while you're installing the new one.
Or am I misunderstanding your point?
Well, a lot of that is because the PHP devs are huge MySQL fanboys, so they limit themselves to what MySQL can do, rather than what better databases do.