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."
Public Holes Publication, isn't it ? ;)
-- Rastignac was here.
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"
Lindsay Blanton
RadioReference.com
I thought every month was PHP Bugs month?
...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.
month of PCP bugs. i see them all over my skin and i can't scratch them off! SOMEONE HELP ME
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
I recently installed modsecurity http://www.modsecurity.org/ for apache along with the rules from http://www.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.
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?
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.
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*
Whence? Hence. Whither? Thither.
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.
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 of decent PHP frameworks out there, with others coming along, 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.
This is not your signature.
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).
"Month of Shooting Fish In a Barrel"
At least the Month of Apple Bugs was a hard target to go after.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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_cl
o 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."At this point you stop bothering whether anyone considers the disclosure of unreported vulnerabilities unethical."
Maybe. But to take more than 31 bugs and disclose them a day at a time so that in effect major web-facing infrastructure for big business and home users alike will have no chance at all of being secured during this entire window, all for the purposes of publicity?
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?
If you're a programmer and you don't see huge problems with both the design of PHP itself and the standard library you should just quit now and find another hobby/profession.
I'm a programmer. I work with PHP. I see a hell of a lot of problems with its design and implementation. Am I ready to dump it and switch to something better? You bet. I've been waiting for the chance for the last 5 years or more.
Can I actually do this?
No. The marketplace is such that if I implement my solutions in any other environment, I'm cutting myself out of large chunks of the market simply because people might choose a hosting provider that doesn't support whatever alternative language I choose to use.
The default behavior in case of database problems is to display the host, username and password in the browser? Good grief.
No, I did not read the f***ing article!
If there isn't a problem with register_globals, then why are they finally taking it out of the language? Of course the real questions are: why did it take so long to remove from the language, and why was it ever there in the first place? That is even more evidence of extremely bad judgement on the part of the PHP designers, that they mad such a bad mistake in the first place, and took so long to admit they made a mistake and correct it. They still try to blame it on "bad developers", but that's the only kind of developers they have left any more, because anyone with any sense or choice in the matter has moved on to better languages like Python and Ruby.
Doing a google search for register_globals site:www.us-cert.gov shows 112 references to security vulnerabilities having to do with register_globals. Is that enough evidence that register_globals is a bad idea?
The register_globals flag should not even be an option, backwards compatibility be damned. When you have security holes like "Unsafe termination of parse_str() may result in the register_globals directive turned back on, you're screwed even when you turn it off, because PHP turns it back on internally, then wets its pants before turning it back off, so it leaves it on for the rest of the lifetime of the web server.
That terrible bug was found AND FIXED by Stefan Esser (the person who this thread is about, in case you didn't bother to read the article), yet some piss-water-carrying PHP fan-boys are still attacking him as a "traitor".
Here is another article he wrote about PHP security problems having to do with register_globals and a lot of other stupid flaws that should have never existed in the first place: Zend_Hash_Del_Key_Or_Index Vulnerability. If you don't like it when people blame the Zend Corporation for so many of the problems in PHP, then maybe you should ask Zend to stop putting their company name into all those functions that are the root cause of so many security problems.
-Don
Take a look and feel free: http://www.PieMenu.com