Slashdot Log In
Month of PHP Bugs Has Begun
Posted by
Zonk
on Sat Mar 03, 2007 01:28 PM
from the quick-hide-the-furniture dept.
from the quick-hide-the-furniture dept.
An anonymous reader writes "The previously announced Month of PHP Bugs started three days ago, and already lists 8 security vulnerabilities in PHP and PHP related software. From the site: 'This initiative is an effort to improve the security of PHP. However we will not concentrate on problems in the PHP language that might result in insecure PHP applications, but on security vulnerabilities in the PHP core. During March 2007 old and new security vulnerabilities in the Zend Engine, the PHP core and the PHP extensions will be disclosed on a day by day basis. We will also point out necessary changes in the current vulnerability management process used by the PHP Security Response Team.'"
Related Stories
[+]
March To Be Month of PHP Bugs 292 comments
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."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Defective by Design? (Score:5, Interesting)
We see a lot of people use the phrase "defective by design" when talking about Vista and in that instance I'm pretty sure the use of the term is correct.
Having never used PHP but heard of its many security problems I'm wondering: Is PHP defective by design? If so, why so and how would Slashdot seek to fix it?
Simon
Re: (Score:3, Interesting)
Not entirely joking. I use embedded perl for my own dynamic sites, and keep track of the lists, and can't recall any serious known flaws with that implementation.
The vulnerabilities that keep popping up (and the fact that I already know and am comfortable with perl, have CPAN, can develop quickly especially now that I have my own base modules set up, etc) are one reason that I never really looked into PHP.
Re:Defective by Design? (Score:5, Informative)
It was. A lot of work has been done in the last couple of major versions to fix this, but still a lot of installations are crippled in the name of backward compatibility.
Most of what we're seeing here though is just run-of-the-mill sloppy coding. Create a lot of references to a variable and overflow its (16-bit) reference count? Please. That should never have happened.
Fortunately, it seems most of the bugs released so far don't affect the majority of installations. We have a number of 'executing arbitrary PHP code can let somebody own your web server' -- well, most of us don't let random people run arbitrary PHP code anyway. We have some 'deserialising arbitrary data can let somebody own your web server' issues too, but then there has been a long-standing warning that PHP's deserialise function isn't secure anyway, so that shouldn't affect anyone who's been paying attention. We have some issues with the Zend Platform, but I'm not sure how many people have that installed. So far, the only issue to affect me, is the phpinfo XSS vulnerability -- and that just meant I had to delete my phpinfo.php file that I kept in the root of each domain I host.
Parent
Re: (Score:3, Interesting)
And phpBB is just one of many popular applications that do it...
Re: (Score:3, Insightful)
No, I wasn't. One more reason not to use phpBB, I guess.
Re: (Score:2)
But they do $inputHash == $hash, and you can use the serialized syntax to make $inputHash = true;, which means that it will == any non-zero-length string. Very annoying gotchas like this can make PHP a nightmare.
Re: (Score:2)
But they do $inputHash == $hash, and you can use the serialized syntax to make $inputHash = true;, which means that it will == any non-zero-length string. Very annoying gotchas like this can make PHP a nightmare.
Strange, I'm looking at the code for phpBB2 v2.0.22 in my editor right now, and there is no occurrence of code like you mention. That sort of problem was cleared up well over a year ago, when it was first revealed to be a problem. In every case where unserialize() is used, its output is assigned t
Re: (Score:2)
Doesn't mean calling unserialize on untrusted data is a good idea. Unserialized data may be of any class, and code may be automatically executed in it during the unserialization process. This means an attacker may be able to execute code you were not expecting to be executed, potentially leading to any of a number of exploit scenarios. Unserializing untrusted data in PHP (and many other dynamic languages) is a bad
Re:Defective by Design? (Score:5, Informative)
if you left an open phpinfo() on your server (giving potential attackers access to filepaths, module version numbers, configuration options, apache server configuration options), you have a lot more to worry about than a little XSS.
unfortunatly, you're not alone [google.com].
Parent
Re: (Score:2)
Its bloody helpful.
Re: (Score:2)
Heh... guess I'm not the only idiot that does that. :) Even though I'm running 5.x and that bug doesn't affect me, I've known it was a stupid idea for a long time but laziness prevailed. You and the PHP bugs project have just given me the motivation to fix that!
Re:Defective by Design? (Score:5, Interesting)
How I wish we could just junk the language and start again with something else; unfortunately, market pressures being what they are, I'm afraid we're stuck with it, at least for the time being.
Parent
Re:Defective by Design? (Score:5, Insightful)
It may never completely go away, but there are alternatives to using it.
Parent
Re: (Score:3, Informative)
It may never completely go away, but there are alternatives to using it.
Not really. Most of us in the off-the-shelf web package software development industry are constrained to develop in whatever's available on the servers our clients are likely to choose. An informal survey suggests that of 5 popular hosting providers in my local area, only 1 offers anything other than PHP or Perl/CGI in their basic level package. With this kind of support
Re: (Score:2)
Re: (Score:2)
A major problem for PHP is still it's configureware mentality. No other programming language has a configure file. PHP started with it because it's also a web framework; which is somewhat understandable. However, they then proceeded to abuse the configuration file for all sorts of semantic behaviors, and the end result is that it's very HARD to program securely and portably at the same time. Make a configuration change, and tha
Re: (Score:2)
*ducks*
Re:Defective by Design? (Score:5, Interesting)
Parent
Re: (Score:2)
Yes; I have set up my server to reject requests with GET/POST variables that have unrecognised names. The '[]' would trigger that rejection.
Parent isn't flamebait (Score:2)
I just started using PHP a few months ago for a few utilities on one of my websites. There are a ton of things about the language that seem half-assed. In particular I'm thinking of:
- The entire mysql library, which I have to use right now because mysqli apparently isn't enabled by default in PHP 4 and my current host won't turn it on or upgrade to PHP 5. Why is the default behaviour to force the use of SQL injection-vulnerable code?
- There is no equivalent of a "contains" method
Re:Parent isn't flamebait (Score:5, Interesting)
strpos() return FALSE when it can't find the 'needle'. http://us2.php.net/strpos [php.net] Use a proper test (===) and you'll have all you need in a single statement.
Some people really LIKE dynamically-typed variables. It's not a bug or a problem. It's a design choice.
Your flamebait at the end (vbscript) does nothing to enhance your argument. Leave it off next time.
Parent
Re: (Score:2)
Re: (Score:2)
I've seen atrocious code where you can tell that just because the coder knows how to do a for loop in BASIC it means it can become the next Bill Gates.
Re:Defective by Design? (Score:5, Funny)
Parent
Re: (Score:2)
Re: (Score:3, Informative)
Also, using something like GRSec [grsecurity.net], or SELinux can further restrict what people could do if they did end up with a shell on your webserver. Although whether it's worth the effort to set up for everyone is another question.
Re: (Score:2)
Month of bugs, will it change things for better? (Score:4, Interesting)
On the other hand, i bet a fair few of the released vunerabilities will be applicable for many websites that the company i work for hosts, and i know corperate policy doesn't include frequent updates to their envirioment, there's just to many sites, to many badly supported applications by/for customers, and just to damn many servers to work with easily, i can't imagine were the only such company with such problems... And it really makes me wonder if this will mean that many hundreds of our hosted websites will from now on be easily hackable by scriptkiddies
Should prove to be interesting times, and who knows maybe it will teach our admins to use yum/rpm's for their servers instead of compiling their own apache/php combinations
Just in case.. (Score:4, Interesting)
Also version 4 predominates (Score:2)
Re: (Score:2)
Re: (Score:2)
In a shared-hosting situation, I can see why these would be a much bigger problem.
Typical (Score:3, Informative)
I more and more get the feeling that the PHP developers themselves do not properly understand the vulnerabilities any more, which leads to improper and I even dare to say incompetent handling of reports and fixes (many of which simply get applied somewhere down the road without proper announcement or mentioning anywhere in the CHANGELOG) as well as seemingly ignorance regarding more complex vulns that are just as relevant as the glaringly obvious ones but simply not as mass-exploitable by script kiddies.
And *this* is the big problem that PHP is facing today regarding enterprise support. Maybe Jon Doe's blog installation is not as mass-exploitable by a script kiddie any more as it used to be some years ago, yet Big Company's CMS is still vulnerable to complex attacks by an experienced attacker who might use published attacks that security experts know about, yet end users do not.
Re: (Score:2)
Yes, in a shared host environment it potentially allows users to bypass safe mode and open basedir restrictions, however information on how to properly secure PHP for a shared environment has been around for a LONG Time. Not one person on the development team you go so far as to call
Re: (Score:2)
I believe serialize() [php.net] preserves references -- it certainly does in PHP5 -- and (as mentioned elsewhere [slashdot.org] in the discussion) several PHP applications unserialize() remote data (notably phpBB).
Now, since the bug is apparently PHP4 only (gigabytes worth of references notwithstanding), the Big Question is whether or not the PHP4 unserialize() restores references.
Re: (Score:2)
Oh Nose! (Score:4, Funny)
I've found a very similar bug in GLIBC! This code will cause a segment violation!
Shock! Gasp! Horror!
Re: (Score:3, Informative)
Re: (Score:3, Informative)
I've observed that a lot of complaints about modern PHP derive from the fact that it's a dynamic interpreted language, but that in many ways it behaves like a compiled, angry, shoot-yourself-in-the-foot language, like C.
PHP will segfault, just like C, if you recurse too far on the stack, but almost every other scripting language has a mechanism for catching a stack overflow as an exception and then letting the programmer handle it. PHP in this case just crashes; even C allows you to register a function to
Re: (Score:2)
I've found a very similar bug in GLIBC!
int main(){
main();
}
This code will cause a segment violation!
Shock! Gasp! Horror!
Now you know why web pages aren't generally coded in C. There's a reason people use higher level languages for such tasks, and one of them is that you can NOT crash the server via
PHP taint what it should be (Score:2, Insightful)
Maybe. PHP is a wonderful interpreted language that makes creating a web application easy. The biggest problem with PHP are the entry-level programmers who don't understand the beast that is web programming.
Many PHP programmers don't understand th
Re:PHP taint what it should be (Score:4, Interesting)
Parent
Be Prepared? (Score:2, Insightful)
Re: (Score:2, Insightful)
Next Month... (Score:2)
Seriously, when does the Month of Oracle Bugs make its return? Or did the Month of Bugs folks simply chicken out when Larry Elison showed up at their house with a samurai sword?
Re: (Score:2)
http://www.xkcd.com/c225.html [xkcd.com]
Why MOPB Matters (Score:2, Interesting)
Yes, a lot of the problems are sloppy coding, but too many are in the PHP core. How many web pages use the PHP-array-specific query-string
?foo[]=bar
- not many, you might think. How many use a PHP neste
Re: (Score:2)
Re: (Score:2)
Because it is painfully obvious that you have no idea what you are doing, and thanks to PHP's lack of secuirty measures against inexperienced programmers, you are very likely creating tons of highly vulnerable programs.
Other languages tend to have much more secure APIs, letting you get away with not paying as much attention to security. Do yourself a favour and switch to one of them.
Re: (Score:2)