[php-maint] another batch of php security issues for review

sean finney seanius at debian.org
Mon Aug 28 07:15:56 UTC 2006


hey joey et al,

going through the testing-security CVE list, i've found a few more
unaddressed issues.  this time around i won't spend any time patching
them until we agree which ones are issues and which ones are
non-issues :)

CVE-2006-4023 (The ip2long function in PHP 5.1.4 and earlier may
incorrectly validate ...)

	with this one you could craft an aribtrary string that would
	"pass" the validation part of this function.  somethinig like
	1.2.3.4.[sql code], which if not properly sanitized later
	on could lead to various other problems.

	the entry states that this is more likely a bug in any
	applications not performing further validation/sanitizing,
	and i tend to agree based on the php.net documentation, which
	states: "ip2long() should not be used as the sole form of IP
	validation. Combine it with long2ip()".

	so i say non-issue

CVE-2006-4020 (scanf.c in PHP 5.1.4 and earlier, and 4.4.3 and earlier,
allows ...)

	"buffer underflow" could lead to code execution, though it 
	isn't clear exactly how exploitable it is.  according to the
	patch:

	http://bugs.php.net/bug.php?id=38322

	looks like an off-by-one type error, with a simple enough fix, 
	anyway.

CVE-2006-3016 (Unspecified vulnerability in session.c in PHP before
5.1.3 has unknown ...)

	gotta love the "unspecified".  looks like php doesn't perform
	checks on the session name, which can contain any number of
	malicious things and be used for sql injection, xss, etc.

	not sure if this another shoot-yourself-in-the-foot issue or
	whether we should include the fix (which apparently is to only
	allow session names with alphanumeric characters)

CVE-2006-3018 (Unspecified vulnerability in the session extension
functionality in ...)

	this seems similar to the above, only it can result in heap
	corruption, which makes me think that perhaps it's appropriate
	to fix it (though finding the fix will be less than fun)

CVE-2006-2660 (Buffer consumption vulnerability in the tempnam function
in PHP 5.1.4 ...)

	using a long enough path (>MAXPATHLEN) allows you to have 
	tempnam create a file without the temp extension.  sounds like
	another shoot yourself in the foot issue, since the local user
	could just as easily create the file manually, and if the
	tempnam function is taking unsanitized input, it's an 
	application error


and i *think* that's it...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/pkg-php-maint/attachments/20060828/85ad4bef/attachment.pgp


More information about the pkg-php-maint mailing list