[php-maint] Re: php4 security issues, the complete works (vol 2)
seanius at debian.org
Mon Sep 11 06:30:01 UTC 2006
On Sun, 2006-09-10 at 17:42 +0200, Stefan Fritsch wrote:
> > *CVE-2006-0207: needs further research:
> > text:
> > Multiple HTTP response splitting vulnerabilities in PHP 5.1.1
> > allow remote attackers to inject arbitrary HTTP headers via a
> > crafted Set-Cookie header, related to the (1) session extension
> > (aka ext/session) and the (2) header function.
> > background:
> > this bug was marked closed in the security tracker, but later it
> > was revealed that sarge might still be affected. see
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=354683
> > for more information.
> I have verified that the PoC in the bug report works with php4 from
> sarge. With firefox it can be used to do XSS (konqueror just gives an
> error message in this particular case). I think that such redirector
> scriptlets that feed a request parameter into a Location-header
> appear frequently in webapps. So I argue this should be fixed.
that seems pretty reasonable. i'll go digging for a patch.
> CVE-2005-3390 is register_globals=on only. It seems to be quite
> severe, though, so maybe it should be fixed nonetheless.
moritz seems to think otherwise, and i'm inclined to agree with him.
i'm not sure i understand the severity issue anyway, because i don't see
how being able to overwrite the $GLOBALS array is any different from
being able to overwrite any of the contents of the array, which is what
> BTW, wouldn't it make sense to formalize the security policy for php
> (no register_globals, no safe_mode, no open_basedir) and put it into
> the php package descriptions, README.Debians, and php.ini-comments
> for etch?
yes, i agree. i'll make sure to have some notes in the next uploads
of php4/php5 about this. joey/moritz: i imagine that i should get you
guys to sign off on whatever that blurb says... how about:
Because of the large number of security-related problems with
certain PHP configurations, the Debian security team does not
provide security support for configurations known to be
inherently insecure. Most specifically, the security team will
not provide support for flaws in:
- vulnerabilities involving register_globals being activated,
unless specifically the vulnerability activates this setting
when it was configured as deactivated.
- vulnerabilities involving any kind of safe_mode or
open_basedir violation, as these are security models flawed
by design and no longer have upstream support either.
- any "works as expected" vulnerabilities, such as "user can
cause php to crash by writing a malcious php script", unless
such vulnerabilities involve some kind of higher-level DoS or
privilege escalation that would not otherwise be available.
- something else? something more specific about input
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 191 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/pkg-php-maint/attachments/20060911/54bb967a/attachment.pgp
More information about the pkg-php-maint