Month of PHP Bugs and PHP 5.2.1

Friday, February 9. 2007

You might have heard about it from different places already. The Month for the "Month of PHP bugs" was choosen and it will be March. This means I will post every day in March information about one or more vulnerabilities within PHP.

Today PHP 5.2.1 was released which fixes some (but not all) of the bugs I will cover in the "Month of PHP bugs". Actually the release announcement already gives a list of bugs that were fixed. As usual the release announcement gives too little information about the bugs, does describe several bugs wrongly, forgets some security bugs that were fixed, downplays the seriousness of the bugs and does not give a single line of credit.

You will not find any hint anywhere that the security bugs listed were as usual reported by third parties. The release announcement as usual tries to make it look like all of the bugs where found by the PHP developers themself, who have no problem to credit themself in the Changelog for the little fixes they commited. But the original reporters that actually did the work of finding and reporting the vulnerability and that are therefore responsible for the additional security of the PHP community are not mentioned with a single line.

The later is by the way the reason why most of the security vulnerabilities in PHP are found by the "Hardened-PHP Project". There is absolutely no benefit for a security researcher to disclose vulnerabilities in PHP. Security vulnerabilities in PHP are far more worth when kept private and sold to 3rd parties. Actually if the list in the PHP 5.2.1 release announcement would be complete and woule give proper credit it would be quite obvious to everyone that nearly all vulnerabilities in the list were actually reported by the Hardened-PHP Project and are not the work of the PHP developers.

Ah and before I forget. During the "Month of PHP bugs" it will be demonstrated that the "Added internal heap protection" in PHP 5.2.1 (unlike the one within the Suhosin-Patch) does not stop the exploitability of lots of vulnerabilities at all.

Posted by Stefan Esser in Security, PHP at 10:20

Comments (33)

Link to this post

Comments

Display comments as (Linear | Threaded)

#1 cartman ()

I hope you will also provide patches along with the bugs, else we are kinda screwed whole month.

posted on Friday, February 9. 2007

#1.1 bigtoe ()

I agree that the Month of PHP Bugs is a great way to draw attention to the problem, but I share cartman's concern. Will you be issuing patches along with the bugs? This seems to me like the responsible thing to do and it would show that you're not trying to screw PHP users, but simply pointing out the ineptitude of (most of?) the PHP developers.

posted on Friday, February 9. 2007

#2 Stefan Esser wrote (Link) ()

What the original blog entry misses is the information that in the days where PHP was not infected by the enterprise marketing virus and not every second PHP developer considered himself a security expert PHP.net gave proper credit to bug reporters.

posted on Friday, February 9. 2007

#3 Ilia Alshanetsky wrote (Link) ()

Since I wrote the release announcement let me clarify a few things.

First of all it has never been a policy of release announcement to provide credit for the specific changes and or discovery of security issues. Look at the previous release announcements, for reference.

As far as the text of the announcement, it was specifically kept vague to prevent easy development of exploits for the discovered issues until the people have had the chance to upgrade their PHP versions. I knew you were going to release MOPB in march (as you can find in my blog as of a few days ago) and would get full credit for those discoveries anyway.

As far the notes about the exploits themselves, while large segment was in fact discovered by you, there was a good number that was not as well. The security notes are not "1 per exploit" so in many instances they summarize more then one issue.

posted on Friday, February 9. 2007

#3.1 Stefan Esser wrote (Link) ()

Ilia,

I guess most people understand that the vendor tries to downplay the seriousness of vulnerabilities but the release announcement does not tell the thruth.

Actually it claims that local issues in PHP are only an issue when PHP is used as an Apache module. This is however not true. Local exploits might be more dangerous when PHP runs as module but local PHP exploits are still dangerous.

Users of PHP assume, that if they install only the basic extensions and use disable_function to for example forbid all socket functionality or shell execution functions that they are on the safe side. I have also seen people that also forbid all kind of functions that could actually write to the harddisk, to be safe from exploits.

So far so good. But the moment someone can use a local PHP exploit he can do pretty much whatever he wants. This of course includes direct attacks against for example the linux kernel to get root access. Or alternatively use some other local vulnerability.

This would not be possible without the local holes in PHP.

posted on Friday, February 9. 2007

#3.1.1 Ilia Alshanetsky wrote (Link) ()

Stefan,

I think you misunderstood my intention, perhaps it was my language, in which case my apologies to you or anyone else who was confused by it. Allow me to clarify, the release announcement says the following:

"However, some of the above issues can be triggered remotely in certain situations, or exploited by malicious local users on shared hosting setups utilizing PHP as an Apache module."

To me this reads as: some issues are remotely exploitable, while others pose danger to users using PHP as an Apache module.

The key word is "or" not and

posted on Friday, February 9. 2007

#3.1.1.1 Stefan Esser wrote (Link) ()

Ilia,

my statement is: Local vulnerabilities do affect all shared hosting setups, not only mod_php setups. While for obvious reasons local vulnerabilities are very bad for mod_php, people using CGI still assume that they can rely on disable_function, open_basedir and friends. They rely on the fact that PHP cannot execute arbitrary code on the server (for example launch exploits against the kernel to get root) but only the functions allowed in the php.ini.

It is simply not true that hosting companies consider allowing a customer to run arbitrary PHP scripts is equal to allowing him to run arbitrary code.

posted on Friday, February 9. 2007

#3.1.1.1.1 Ilia Alshanetsky wrote (Link) ()

When PHP is ran as CGI it runs under the account of the user, which means that given proper file permissions on the system it would be difficult to do any significant harm to other users of the system.

PHP is a scripting (I am tempted to say a programming) language, and as such as a tool. Once you give such a tool, a fairly powerful one at that to someone you don't trust, it could pose a serious danger. Ultimately languages are tools designed to enable people, not to restrict them and ultimately restrictions should like in the OS configuration to truly work properly.

posted on Friday, February 9. 2007

#3.1.1.1.1.1 Stefan Esser wrote (Link) ()

First of all using PHP as CGI does not necessary mean that every virtual host gets executed with different permissions. It only means that one does not use it as Apache Module. To get PHP to execute with different users additional configuration steps have to been taken.

Secondly PHP unlike PERL, Python is designed to be a Web Application Programming Language. It comes with configuration options that are supposed to restrict the language so that it cannot do any harm. These restriction options are one of the reasons why PHP is so accepted by the hosters, because they believed they can restrict it far easier than PERL and Python scripts. (However things like disable_function are completely worthless when there are trivially exploitable local vulnerabilities in PHP)

And last but not least... There are heavily used products from a 4 letter company that is heavily involved in PHP that allow getting 'root' due to local vulnerabilities. And from both sides one hears: Ohh we don't protect against local users.

PS: With any of these postings I do not want to advertise open_basedir as a solution. I am more concerned about things like disable_function that actually are still considered to be safe.

posted on Saturday, February 10. 2007

#3.1.1.1.1.1.1 Ilia Alshanetsky wrote (Link) ()

PHP was initially designed primarily as a web scripting language, which is one of the reasons it did so well in that vertical. Although, now a days people use it more and more out side of the web environment for shell scripts, some GUI work (php-gtk).

As I am certain you know built-in protections in PHP can only go so far because in the end its a language designed to enable users, not to limit them. To ensure secure environment ideally you want user separation (chroot, mod_suid, fastcgi, cgi, etc...).

posted on Saturday, February 10. 2007

#4 Benjamin Klaile wrote (Link) ()

"Month of bugs" ... sound like a well planned marketing strategy for your own product Suhosin

Hope you'll consider that there your behaviour may have a very displeasing effect to users of PHP. If you want to "revenge" with those who have trouble with .. do it, but please don't involve the huge community of PHP users and let them pay for the controversies you may have with some developers.

"in the days where PHP was not infected by the enterprise marketing virus and not every second PHP developer considered himself a security expert PHP.net gave proper credit to bug reporters."
I'm young, I'm inexperienced, but what that sounds to me .. kind of defiant. Best regards, Ben.

posted on Friday, February 9. 2007

#4.1 Stefan Esser wrote (Link) ()

It is a pity that within the PHP community the disclosure of security holes is taken as attack or revenge.

"Hope you'll consider that there your behaviour may have a very displeasing effect to users of PHP."

I hope you will realise how funny this statement is. Without my "behaviour" PHP would have several remotely exploitable holes. I wonder how unpleasant it would be for the huge community of PHP users to see their servers hacked.

And actually it does not matter how defiant my statements sound to you. Fact is that PHP did credit security researchers (atleast me) a few years ago, before all this pseudo security awareness and enterprise hype existed.

posted on Friday, February 9. 2007

#5 TrollAlarm ()

@Benjamin Klaile:
"...I'm young, I'm inexperienced, but what that sounds to me .. kind of defiant..."
That sounds to me ... Troll Alarm

What´s the deal with your posting?

posted on Friday, February 9. 2007

#6 cartman ()

To Ilia,

without giving proper CVE numbers for security bugs its hard for a distro to see if a new security bug is a dup or not. Just mentioning "some buffer overflows here and there" doesn't help anyone.

posted on Friday, February 9. 2007

#6.1 Ilia Alshanetsky wrote (Link) ()

I think the overall impression was that Stefan and other reporters of the security bugs would register the relevant CVE numbers. I don't think it would be appropriate for us to take credit by registering CVEs for issues not discovered by us (PHP developers).

posted on Friday, February 9. 2007

#7 m0dY ()

Revenge! might be and we're all (PHP beneficiaries) have nothing to do with it, disclosing a security issue or even a stability issue is in my opinion an ethical action and bad action at the same time, you get to be seen sometimes as a devil in a white sheep clothes and some times as someone who's giving php core developers and maintainers a small wakeup punch in the head, both are judged from different views by different eyes, also i won't stick with the idea that Steffan is trying to do a "marketing strategy for your own product Suhosin" as Benjamin Klaile stated unless Suhosin will become someday a commercial software (or Steffan is planning to do so), at the mean time i think that MOPB will be a good push for any developer who's have trust from a large community and have a lot of doors relying on his software to care more about security issue and not wait after they are released as 0dayz and then be widely available for public.

posted on Saturday, February 10. 2007

#8 cartman ()

Arghhhhh see this commit, now security commits are hidden too, way to go indeed.

wez Sat Feb 10 17:21:03 2007 UTC

Modified files:
/CVSROOT loginfo.pl
Log:
add [SECURITY] tag for commit mail

http://cvs.php.net/viewvc.cgi/CVSROOT/loginfo.pl?r1=1.85&r2=1.86&diff_format=u
Index: CVSROOT/loginfo.pl
diff -u CVSROOT/loginfo.pl:1.85 CVSROOT/loginfo.pl:1.86
--- CVSROOT/loginfo.pl:1.85 Mon Jun 19 05:35:33 2006
+++ CVSROOT/loginfo.pl Sat Feb 10 17:21:03 2007
@@ -93,6 +93,12 @@
# before a line that begins with "Log Message"
my ($logmsg,$tag) = &get_log_message();

+# if tagged as a security fix, route it to security@ instead
+if ($logmsg =~ /\[SECURITY\]/m) {
+ @envaddr = ("security\@php.net");
+ @mailto = @envaddr;
+}
+
#print "$$ before fork\n";

posted on Sunday, February 11. 2007

#9 cartman ()

Ah Rasmus Lerdorf reverted that stupid security@php.net commit, sanity at last!

posted on Sunday, February 11. 2007

#10 Mark Cox ()

By reporting an issue every day, users and distributions that include PHP either have to provide updates every single day for a month, or wait until an update for all the issues at the end of the month and expose themselves to the cummulative risk.

Distributions that ship PHP can provide rapid updates to their users for important issues, but no user wants to receive an update every day. Or can handle installing it.

Reporting them one by one over a month is worse than full disclosure as it is specifically designed to maximise the risk to users of PHP. This is punishing the users (and distributions) more than the PHP security team.

I'm sure that yould get the same attention to the flaws by announcing 31+ holes in one go, then they can all be promptly fixed, and users get a single (large) update.

posted on Monday, February 12. 2007

#10.1 Stefan Esser wrote (Link) ()

Mark,

vulnerability disclosure is not a punishment, it is actually the opposite. PHP users and distributions get free information about security holes. It is actually a gift no one except the reporter has to pay for (by investing lots of work and getting nothing in return). Information, companies have to pay a lot of money for to aquire it for their own products and Open Source projects often get the same information for free.

The vulnerabilities put the user at risk, not the disclosure of them. The vulnerabilities exist no matter what. In a world without 0-day exploits disclosure would put users at risk, but that is not the reality we are living in. The disclosure of vulnerabilities allows the user to protect themself. Without that information only the "bad guys" have the information. In the case of PHP it sometimes takes several months before a fix in the CVS makes it into the next release and the public learns about it. THIS puts users at risk, because the "bad guys" already snapped the vulnerability from the PHP CVS:

And let's not forget, that by adding your own (vulnerability) fixes you create derived work and are not allowed to ship packages called PHP at all.

And I think that you do not really believe that announcing the vulnerabilities at once gives the same attention to the flaws, because that is not true at all. It is simply to much information at once and most people will not read it at all and just install an update one time. And nothing will be changed after that.

Microsoft did a very good thing by moving to a one security update per month strategy. Their products look a lot safer when there is one update per month for 15 bugs instead of every 2nd day an update.

posted on Monday, February 12. 2007

#10.1.1 Mark Cox ()

Stefan, you write: "The disclosure of vulnerabilities allows the user to protect themself. Without that information only the "bad guys" have the information." but yet your timed disclosure doesn't let users protect themselves. You already know what flaw you're going to disclose on March 31st, but you're keeping it to yourself and the 'bad guys' for the next 6 weeks. That's not "full disclosure", it's just a way to bring attention to your project whilst increasing the risk to PHP users.

posted on Monday, February 12. 2007

#10.1.1.1 Stefan Esser wrote (Link) ()

Mark,

first of all I have not decided yet what flaw I release when. This mostly depends on grouping similiar flaws together and when I finish writing up something about them.

And furthermore, by imputing that I do "the Month of PHP Bugs" to draw attention to my own project you disqualified yourself for further discussion.

Stefan Esser

posted on Monday, February 12. 2007

#10.1.1.1.1 Mark Cox ()

"your project" means "Month of PHP bugs", nothing else.

posted on Tuesday, February 13. 2007

#10.1.1.2 tk ()

Cut him some slack.

With 0day being private most of the time, it's imo (!) good to disclose those issues because it makes more people aware. Doesn't really matter when it's done. And if he gets attention for this, so be it. He's providing services for free and why not use them to get a job? After all many people use their commitment to Open Source on the resume.

I also agree with the fact that this should not be seen as a reminder to core developers only, it also makes administrators aware of problems.

The more important benefit of all this is, that they will (probably) get fixed soon. So instead of rolling out features maybe someone will focuse more on what needs to be fixed. But that last sentence is not meant to judge any developer or the overall development process. I just know from my personal experience that you always like to roll out new features instead of fixing nasty bugs.

posted on Monday, February 12. 2007

#11 Steve Christey ()

CVE is willing to provide reserved CVE candidate numbers to any party who can reasonably guarantee that there will be a minimal likelihood of duplicates, and the numbers will be assigned roughly in accordance with CVE's "content decisions". If disclosure is not going to be coordinated, then rationally speaking it should be at the earliest disclosure point - with a researcher who's willing to use the CVE.

To the PHP developers - CVE's role, partially, is to distinguish apples from other apples. CVE numbers in changelogs, and/or credits, make this difficult task at least a little bit easier. Any sort of cross-reference is useful.

Steve Christey
CVE Editor

posted on Tuesday, February 13. 2007

#12 bongobongo ()

I wonter why some people belive that keeping these security holes secret makes the whole thing more secure.

This is a good initiative.

Lets get all the SECURITY HOLES out in the open so everyone can know about them.
But when you do I hope you supply enough information with that information so we can prevent hackers from using the holes, if the security blunder is possible to fix that is.

To not give credit to the ones that actually reported the bugs, is truly a blunder as well.

posted on Friday, February 23. 2007

#13 anonymous ()

Stefan, it's a pity a good guy like yourself can be pushed over into joining the tactics of a Moth of Bugs. Pity to see you cross the line to the dark side.

posted on Saturday, February 24. 2007

#13.1 Stefan Esser wrote (Link) ()

Hello Anonymous,

I know that a lot of people consider the Month Of Bugs a bad thing. Maybe because previous Month Of Bugs did this and that.

Don't forget that I am not affiliated with anyone who did such a Month Of Bugs before. There are reasons why I have choosen todo MOPB. These reasons might be a little bit unclear until the Month has started. And I guess during the Month it will become pretty clear, why I had to choose this way and why it is the only way that makes sense.

After the month you can still decide if you still believe that I turned to the dark side.

posted on Saturday, February 24. 2007

#14 Justin Lindberg wrote (Link) ()

I am taking class in PHP programming, and I am really looking forward to the Month of PHP Bugs. How the PHP developers handle the public disclosure of these vulnerabilities will determine whether I continue learning and programming PHP or move on to some other language whose developers have a better attitude about security.

The PHP developers and Zend appear to have always concentrated on ease of use rather than security. It's a false dichotomy. I don't see that there needs to be any conflict between "easy to use" and "secure." It should be made as straightforward as possible to write secure PHP code.

Several software vendors, both free and proprietary, push some sort of "responsible disclosure." You yourself ask to be privately informed of security bugs in your software (Suhosin). While you are no doubt responsible enough to take bugs seriously when they are privately reported to you, most companies in practice don't even begin to take security issues seriously until there are working exploits in the wild.

In my opinion full disclosure (with working, tested patches if you are feeling generous) is the most responsible thing to do for an open source project, especially one like this whose developers appear to demonstrate an ongoing lack of concern about security.

The "Month of PHP Bugs" will hopefully lead, not just to a fix for those bugs that you have found, but to a change in attitudes and behavior so that PHP will greatly benefit security-wise in the long run.

posted on Saturday, February 24. 2007

#14.1 Stefan Esser wrote (Link) ()

Hi Justin,

of course I would like to get prior notice about security bugs in Suhosin. Every vendor does want that.

But unlike the PHP developers I will not claim publicly that Suhosin does not contain security bugs, when I know about their existance and have already fixed them in the CVS version.

I will also credit the person who reported it. Because I believe this is the least one can do.

And unlike some PHP developers claim I do not believe to write code without bugs, but unlike them I do not feel hurt/attacked when someone points them out. Feel free to find bugs in Suhosin of any kind. My users are usually not as frustrated as PHP users that have already tried reporting a bug in PHP.

posted on Saturday, February 24. 2007

#15 amu ()

i really need this script urgently and wish that you can help me.
i have my own site,in a certain page i want the script to run as:-
---i place a link on my page to "www.blah.com/blah"
---instead of opening the page i want the link to fetch all the blue colured links on "www.blah.com/blah".these links from the other site should be displayed on my site.
---on clicking one of the blu link displayed on my site fom othr site,
it should again dispay another set of blue links on my site(for eg from www.blah.com/blah/page)
---finally on clicking one of the links displayed from www.blah.com/blah/page it should download the link as it is supposed to be an exe or mp3 file.

i have no idea about programming as i am 12 yrs old. please.please do help me.

posted on Wednesday, February 28. 2007

#16 Jehzeel Laurente wrote (Link) ()

many of my scripts doesn't work with PHP5 also.. hayyy how sad

posted on Monday, April 16. 2007

#17 Jehzeel Laurente wrote (Link) ()

but now it works! hehe

posted on Friday, May 18. 2007

Add Comment

Name:

Email:

Homepage:

In reply to:

Comment:
Standard emoticons like :-) and ;-) are converted to images.

Remember Information? Subscribe to this entry
Submitted comments will be subject to moderation before being displayed.

Calendar