Bugzilla – Bug 654853
VUL-1: CVE-2006-7243: php5: NULL byte poisoning fix in php 5.3.4+
Last modified: 2019-06-18 14:54:08 UTC
Hi. There is a security bug in package 'php5'. This information is from 'oss-security'. This bug is public. There is no coordinated release date (CRD) set. More information can be found here: http://bugs.php.net/39863 Original posting: ---------- Weitergeleitete Nachricht ---------- Betreff: [oss-security] NULL byte poisoning fix in php 5.3.4+ Datum: Donnerstag 18 November 2010 Von: Pierre Joye <pierre.php@gmail.com> An: oss-security@lists.openwall.com hi, The problem describes here http://www.madirish.net/?article=436, in http://bugs.php.net/39863 (and numerous other places) has been fixed in PHP_5_3, targetting 5.3.4 (RC1 to be released today). It is a well (old) known issue in PHP and I wonder if there is a CVE already for it? If not I think having one could helpful. or? Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org ------------------------------------------------------------- [oss-security] Re: NULL byte poisoning fix in php 5.3.4+ Von: Pierre Joye <pierre.php@gmail.com> An: oss-security@lists.openwall.com forgot to add the fixes revs: http://svn.php.net/viewvc?view=revision&revision=305507 revert of part of the OCI8 fix http://svn.php.net/viewvc?view=revision&revision=305509 OCI8 fix (committed separately) http://svn.php.net/viewvc?view=revision&revision=305412
Sigh :-). There are 17 (!) files involved; almost all these patches add checking for string length to ensure that input string doesn't contain null byte, e. g. --- php/php-src/branches/PHP_5_3/ext/gd/gd_ctx.c +++ php/php-src/branches/PHP_5_3/ext/gd/gd_ctx.c @@ -91,6 +91,9 @@ } if (argc > 1 && file_len) { + if (strlen(file) != file_len) { + RETURN_FALSE; + } PHP_GD_CHECK_OPEN_BASEDIR(file, "Invalid filename"); fp = VCWD_FOPEN(file, "wb"); and similar. So it is something that I could try to port to 5_2 branch, but before I start with this hmpf work I would like to ensure that this is really necessary from security point of view (with respect to 'VUL-1' indication).
VUL-1 means: "Let's fix it together with a more serious update." So, it still means that it has to be fixed. :-) But the current solution as presented in comment#1 seems error prone and seems not to be the root of the problem. I hope a more sophisticated solution will appear until the next php5 security update. (php5 has a string type at least)
Created attachment 401804 [details] Current patch for 5_3 branch taken from revisions 305412, 305507, 305509. JFYI Log message of revision 305507: -----------------------------8<-------------------------------- - fix #39863, do not accept paths with NULL in them. See http://news.php.net/php.internals/50191, trunk will have the patch later (adding a macro and/or changing (some) APIs. Patch by Rasmus ----------------------------->8--------------------------------
I presume from this log message that upstream will not do backportable patch for the trunk. But ok, let's wait for better patch --> P4 for now.
The SWAMPID for this issue is 37389. This issue was rated as important. Please submit fixed packages until 2010-12-02. When done, please reassign the bug to security-team@suse.de. Patchinfo will be handled by security team.
CVE-2006-7243
Should we use patch from comment 3 for upcoming php update or do you see another solution?
ok!
WONTFIX because this bug can only be exploited with a malicious script.
can we remove the 0 byte patch from the package? this is very irritating: php-5.2.14-CVE-2006-7243.patch
adding to planned update for removal of patch only.
Done.