[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