PHP new vulnarabilities
hi all last time i found this when i run portaudit -Fda Affected package: php5-5.1.6 Type of problem: php -- _ecalloc Integer Overflow Vulnerability. Reference: http://www.FreeBSD.org/ports/portaudit/e329550b-54f7-11db-a5ae-00508d6a62df.html how can i fix this -- Best regards, Khaled J. Hussein System Administrator Hadara Technologies Group [EMAIL PROTECTED] http://www.palnet.com Tel. +972 2-240-3434 Fax. +972 2-240-3430 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PHP new vulnarabilities
Hi Khaled, Affected package: php5-5.1.6 Type of problem: php -- _ecalloc Integer Overflow Vulnerability. http://www.FreeBSD.org/ports/portaudit/e329550b-54f7-11db-a5ae-00508d6a62df.html how can i fix this Compile php from source after applying http://www.hardened-php.net/files/CVE-2006-4812.patch ? I dodn't deploy 5 yet, but maybe an other fix is underway ? Hth. Regards, Robert ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PHP new vulnarabilities
On Sun, 15 Oct 2006 14:31:25 +0200 Khaled J. Hussein [EMAIL PROTECTED] wrote: hi all last time i found this when i run portaudit -Fda Affected package: php5-5.1.6 Type of problem: php -- _ecalloc Integer Overflow Vulnerability. Reference: http://www.FreeBSD.org/ports/portaudit/e329550b-54f7-11db-a5ae-00508d6a62df.html how can i fix this update ypur portstree. you'll get php5-5.1.6_1 which fixes the _ecalloc overflow, but not yet the open_basedir race condition. Joerg -- | /\ ASCII ribbon | GnuPG Key ID | e86d b753 3deb e749 6c3a | | \ / campaign against |0xbbcaad24 | 5706 1f7d 6cfd bbca ad24 | | XHTML in email |.the next sentence is true. | | / \ and news | .the previous sentence was a lie.| signature.asc Description: PGP signature
Re: PHP new vulnarabilities
On Sunday 15 October 2006 08:12, Joerg Pernfuss wrote: On Sun, 15 Oct 2006 14:31:25 +0200 Khaled J. Hussein [EMAIL PROTECTED] wrote: hi all last time i found this when i run portaudit -Fda Affected package: php5-5.1.6 Type of problem: php -- _ecalloc Integer Overflow Vulnerability. Reference: http://www.FreeBSD.org/ports/portaudit/e329550b-54f7-11db-a5ae-00508d6a6 2df.html how can i fix this update ypur portstree. you'll get php5-5.1.6_1 which fixes the _ecalloc overflow, but not yet the open_basedir race condition. Joerg ive been scratching my head on this one for a few days too. i have a box at home, that is running 6.2-PRERELEASE. when i try to install the lang/php5 port, i get: [EMAIL PROTECTED] /usr/ports/lang/php5]# make install clean === php5-5.1.6_1 has known vulnerabilities: = php -- open_basedir Race Condition Vulnerability. Reference: http://www.FreeBSD.org/ports/portaudit/edabe438-542f-11db-a5ae-00508d6a62df.html = Please update your ports tree and try again. *** Error code 1 Stop in /usr/ports/lang/php5. however, my server is running the same port, with no issue whatsoever. [EMAIL PROTECTED] /etc/mail]# pkg_info | grep php5 php5-5.1.6_1 (and many extensions too) perplexing that one box could have it, while another one (using the same updated ports tree), refuses it. could be related to the code branch im following on my workstaion versus my server? thanks, jonathan ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PHP new vulnarabilities
Hi Jonathan Jonathan Horne schrieb: On Sunday 15 October 2006 08:12, Joerg Pernfuss wrote: On Sun, 15 Oct 2006 14:31:25 +0200 Khaled J. Hussein [EMAIL PROTECTED] wrote: hi all last time i found this when i run portaudit -Fda Affected package: php5-5.1.6 Type of problem: php -- _ecalloc Integer Overflow Vulnerability. Reference: http://www.FreeBSD.org/ports/portaudit/e329550b-54f7-11db-a5ae-00508d6a6 2df.html how can i fix this update ypur portstree. you'll get php5-5.1.6_1 which fixes the _ecalloc overflow, but not yet the open_basedir race condition. Joerg ive been scratching my head on this one for a few days too. i have a box at home, that is running 6.2-PRERELEASE. when i try to install the lang/php5 port, i get: [EMAIL PROTECTED] /usr/ports/lang/php5]# make install clean === php5-5.1.6_1 has known vulnerabilities: = php -- open_basedir Race Condition Vulnerability. Reference: http://www.FreeBSD.org/ports/portaudit/edabe438-542f-11db-a5ae-00508d6a62df.html = Please update your ports tree and try again. *** Error code 1 Stop in /usr/ports/lang/php5. however, my server is running the same port, with no issue whatsoever. [EMAIL PROTECTED] /etc/mail]# pkg_info | grep php5 php5-5.1.6_1 (and many extensions too) perplexing that one box could have it, while another one (using the same updated ports tree), refuses it. could be related to the code branch im following on my workstaion versus my server? Maybe the bug was not in your vuxml when you compiled php5-5.1.6_1. You can use: make -DDISABLE_VULNERABILITIES install clean It will ignore the vuxml entry. Cheers, Thomas ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PHP new vulnarabilities
--On October 15, 2006 12:39:11 PM -0500 Jonathan Horne [EMAIL PROTECTED] wrote: ive been scratching my head on this one for a few days too. i have a box at home, that is running 6.2-PRERELEASE. when i try to install the lang/php5 port, i get: [EMAIL PROTECTED] /usr/ports/lang/php5]# make install clean === php5-5.1.6_1 has known vulnerabilities: = php -- open_basedir Race Condition Vulnerability. Reference: http://www.FreeBSD.org/ports/portaudit/edabe438-542f-11db-a5ae-00508d6a 62df.html = Please update your ports tree and try again. *** Error code 1 Stop in /usr/ports/lang/php5. however, my server is running the same port, with no issue whatsoever. That's because you installed the port on the server *before* the vulnerability was found. [EMAIL PROTECTED] /etc/mail]# pkg_info | grep php5 php5-5.1.6_1 (and many extensions too) perplexing that one box could have it, while another one (using the same updated ports tree), refuses it. could be related to the code branch im following on my workstaion versus my server? No. It's related to the timing of when a security vulnerability was discovered. Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer The University of Texas at Dallas http://www.utdallas.edu/ir/security/
Re: PHP new vulnarabilities
--On October 15, 2006 7:49:55 PM +0200 Thomas [EMAIL PROTECTED] wrote: Maybe the bug was not in your vuxml when you compiled php5-5.1.6_1. You can use: make -DDISABLE_VULNERABILITIES install clean It will ignore the vuxml entry. No offense, but anybody who *deliberately* installs a vulnerable version of php in *today's* world, is an absolute fool. Some of us are *stuck* with the vulnerable version, because we installed before the vulnerability was found. We can't go back because previous versions are *also* vulnerable. But *deliberately* installing it when you *know* it's vulnerable - and one of the most attacked applications on the internet? Foolhardy doesn't quite grasp the insanity of that. Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer The University of Texas at Dallas http://www.utdallas.edu/ir/security/
Re: PHP new vulnarabilities
Paul Schmehl [EMAIL PROTECTED] wrote: --On October 15, 2006 7:49:55 PM +0200 Thomas [EMAIL PROTECTED] wrote: Maybe the bug was not in your vuxml when you compiled php5-5.1.6_1. You can use: make -DDISABLE_VULNERABILITIES install clean It will ignore the vuxml entry. No offense, but anybody who *deliberately* installs a vulnerable version of php in *today's* world, is an absolute fool. Some of us are *stuck* with the vulnerable version, because we installed before the vulnerability was found. We can't go back because previous versions are *also* vulnerable. Have you looked at the vulnerability? There are only certian coding instances that would actually open this up to any attack vector. Since the bug is in unserialize, it's pretty easy audit a program to ensure that it isn't vulnerable. absolute fool seems a little extreme. -- Bill Moran Six men came to kill me one time, and the best of them carried this. It's a Callahan fullbore autolock, customized trigger and double cartridge thourough-gage. It's my very favorite gun. Jayne Cobb ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PHP new vulnarabilities
On Sun, 15 Oct 2006 13:07:15 -0500 Paul Schmehl [EMAIL PROTECTED] wrote: --On October 15, 2006 7:49:55 PM +0200 Thomas [EMAIL PROTECTED] wrote: Maybe the bug was not in your vuxml when you compiled php5-5.1.6_1. You can use: make -DDISABLE_VULNERABILITIES install clean It will ignore the vuxml entry. No offense, but anybody who *deliberately* installs a vulnerable version of php in *today's* world, is an absolute fool. Some of us are *stuck* with the vulnerable version, because we installed before the vulnerability was found. We can't go back because previous versions are *also* vulnerable. But *deliberately* installing it when you *know* it's vulnerable - and one of the most attacked applications on the internet? Foolhardy doesn't quite grasp the insanity of that. Completely true, but in this situation, the update is argueably the better thing to do. With the update you trade an integer overflow against this open_basedir hole that is, as far as I know, harder to exploit and the _1 version is sure to have the suhosin 0.9.5 patch (5.1.6 can be either 0.9.3 or 0.9.5 depending on checkout date - or none at all) - and with suhosin one can disable symlink(). What may of course very well break the php application, but this is simply choose your poison. Joerg -- | /\ ASCII ribbon | GnuPG Key ID | e86d b753 3deb e749 6c3a | | \ / campaign against |0xbbcaad24 | 5706 1f7d 6cfd bbca ad24 | | XHTML in email |.the next sentence is true. | | / \ and news | .the previous sentence was a lie.| signature.asc Description: PGP signature
Re: PHP new vulnarabilities
--On October 15, 2006 2:50:34 PM -0400 Bill Moran [EMAIL PROTECTED] wrote: Have you looked at the vulnerability? There are only certian coding instances that would actually open this up to any attack vector. Since the bug is in unserialize, it's pretty easy audit a program to ensure that it isn't vulnerable. absolute fool seems a little extreme. Perhaps. How many people are talented enough to understand the vulnerability and how it's exploited and know *for certain* that they won't have a problem? It would be different if we were talking about an app that isn't exploited much. Php is exploited every day, even when it's fully patched, due to the complexity of the attacks and the lack of understanding of most people who code in php. Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer The University of Texas at Dallas http://www.utdallas.edu/ir/security/
Re: PHP new vulnarabilities
Paul Schmehl wrote: --On October 15, 2006 7:49:55 PM +0200 Thomas [EMAIL PROTECTED] wrote: Maybe the bug was not in your vuxml when you compiled php5-5.1.6_1. You can use: make -DDISABLE_VULNERABILITIES install clean It will ignore the vuxml entry. No offense, but anybody who *deliberately* installs a vulnerable version of php in *today's* world, is an absolute fool. Some of us are *stuck* with the vulnerable version, because we installed before the vulnerability was found. We can't go back because previous versions are *also* vulnerable. But *deliberately* installing it when you *know* it's vulnerable - and one of the most attacked applications on the internet? Foolhardy doesn't quite grasp the insanity of that. That is a bit extreme. I have a full workload, I put in about 60 hours a week (I work a lot of weekends, I'm working now). I have servers running all different version of apps. I can't go around upgrading everything at the drop of a hat. I would be divorced within a month. If you read the security alerts carefully you will find many require a shell (We don't offer them to clients), some require a specific app to be running that you may not need (rm -f /usr/local/bin/vulnerable_app), and sometimes a simple code audit will tell you if you are vulnerable. It is also not uncommon that a security alert is issued for a problem that has not be proven in the wild. There are plenty of reasons to not follow a security alert, many of them quite valid. Upgrading mission critical systems without throughly understanding the implications just because someone screamed SECURITY!, now that is foolhardy. DAve -- Three years now I've asked Google why they don't have a logo change for Memorial Day. Why do they choose to do logos for other non-international holidays, but nothing for Veterans? Maybe they forgot who made that choice possible. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PHP new vulnarabilities
--On October 15, 2006 4:31:48 PM -0400 DAve [EMAIL PROTECTED] wrote: That is a bit extreme. I have a full workload, I put in about 60 hours a week (I work a lot of weekends, I'm working now). I have servers running all different version of apps. I can't go around upgrading everything at the drop of a hat. I would be divorced within a month. If you read the security alerts carefully you will find many require a shell (We don't offer them to clients), some require a specific app to be running that you may not need (rm -f /usr/local/bin/vulnerable_app), and sometimes a simple code audit will tell you if you are vulnerable. It is also not uncommon that a security alert is issued for a problem that has not be proven in the wild. There are plenty of reasons to not follow a security alert, many of them quite valid. Upgrading mission critical systems without throughly understanding the implications just because someone screamed SECURITY!, now that is foolhardy. That wasn't the situation here. Look, there are several possible scenarios where installing a vulnerable app is less of a risk than not installing the app at all. Business functionality *is* important. However, to arbitrarily say Use DISABLE_VULNERABILITIES is the answer to an app that won't install is always a wrong answer. *At a minimum* it should come with a warning of the possible risks. Furthermore *upgrading* from a non-vulnerabile app to a vulnerable app simply because it's the latest is foolhardy in the extreme. I don't think my statement was any more extreme than Just use DISABLE_VULNERABILITIES and you can install the app with no warning of the risks. *Especially* when the app is as highly scrutinized as php is (not to mention how vulnerabilities are being found in it all the time.) Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer The University of Texas at Dallas http://www.utdallas.edu/ir/security/
Re: PHP new vulnarabilities
Paul Schmehl schrieb: --On October 15, 2006 4:31:48 PM -0400 DAve [EMAIL PROTECTED] wrote: That is a bit extreme. I have a full workload, I put in about 60 hours a week (I work a lot of weekends, I'm working now). I have servers running all different version of apps. I can't go around upgrading everything at the drop of a hat. I would be divorced within a month. If you read the security alerts carefully you will find many require a shell (We don't offer them to clients), some require a specific app to be running that you may not need (rm -f /usr/local/bin/vulnerable_app), and sometimes a simple code audit will tell you if you are vulnerable. It is also not uncommon that a security alert is issued for a problem that has not be proven in the wild. There are plenty of reasons to not follow a security alert, many of them quite valid. Upgrading mission critical systems without throughly understanding the implications just because someone screamed SECURITY!, now that is foolhardy. That wasn't the situation here. Look, there are several possible scenarios where installing a vulnerable app is less of a risk than not installing the app at all. Business functionality *is* important. However, to arbitrarily say Use DISABLE_VULNERABILITIES is the answer to an app that won't install is always a wrong answer. *At a minimum* it should come with a warning of the possible risks. Furthermore *upgrading* from a non-vulnerabile app to a vulnerable app simply because it's the latest is foolhardy in the extreme. I don't think my statement was any more extreme than Just use DISABLE_VULNERABILITIES and you can install the app with no warning of the risks. *Especially* when the app is as highly scrutinized as php is (not to mention how vulnerabilities are being found in it all the time.) Does DISABLE_VULNERABILITIES not say enough? When he tried to install php he already got the vulnerabilities message including a web link. I think this knob was made for a reason. Cheers, Thomas -- Terry Lambert: It is not unix's job to stop you from shooting your foot. If you so choose to do so, then it is UNIX's job to deliver Mr. Bullet to Mr Foot in the most efficient way it knows. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PHP new vulnarabilities
so the question is, when will the php port be upgraded? it's been days already but i still keep on seeing the vulnerability message even if you say that it isn't that critical. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PHP new vulnarabilities
jan gestre [EMAIL PROTECTED] wrote: so the question is, when will the php port be upgraded? it's been days already but i still keep on seeing the vulnerability message even if you say that it isn't that critical. 1) The suhosin patchset apparently plugs the hole. Unfortunately, portaudit isn't aware of this and still reports the package as vulnerable. 2) The PHP folks haven't release the patch yet, although it's in their CVS. 3) Somebody _could_ generate a patchfile for the FreeBSD port -- don't know why nobody has. So, the answer is I don't know. -- Bill Moran There's more'n seventy little earth's spinning about the galaxy, and the meek have inherited not a one. Malcom Reynolds ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
