[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201209041902.q84J2PGu008228@linus.mitre.org>
Date: Tue, 4 Sep 2012 15:02:25 -0400 (EDT)
From: cve-assign@...re.org
To: oss-security@...ts.openwall.com
Cc: cve-assign@...re.org
Subject: Re: php header() header injection detection bypass
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> - 5.3.11, https://github.com/php/php-src/blob/704bbb3263d0ec9a6b4a767bbc516e55388f4b0e/main/SAPI.c#L593
> has the issue completely fixed
Note that, in the
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1398 entry, the
affected versions are "PHP before 5.3.11." (We do know that 5.3.11
was released about 2 months after 5.4.0.)
>This is perfect, thanks. Please use CVE-2012-4388 for the incomplete
>fix for CVE-2011-1398.
There may be a difference in terminology here. Some CVE entries have a
"NOTE: this vulnerability exists because of an incomplete fix for
CVE-####-####." sentence. This means that a product originally had a
vulnerability (for example, CVE-AAAA-BBBB) that had vectors V1 and V2
in version X.Y. Then, a new version X.Z was released in which a code
change prevented exploitation through vector V1, but still allowed
exploitation through vector V2. Here, a new CVE (for example,
CVE-CCCC-DDDD) is needed because vector V2 is now known to have
different affected versions than vector V1. The CVE-CCCC-DDDD
description would mention "vulnerability in X.Z ... via V2 ... NOTE:
this vulnerability exists because of an incomplete fix for
CVE-AAAA-BBBB."
In the current situation, CVE-2011-1398 will probably be modified soon
to have a "NOTE: this vulnerability exists because of an incomplete
fix for CVE-####-####." sentence. However, unless another related
vulnerability is discovered in the future, there won't be any CVE
entry with a "NOTE: this vulnerability exists because of an incomplete
fix for CVE-2011-1398." sentence. Because of this, "Please use
CVE-2012-4388 for the incomplete fix for CVE-2011-1398" is potentially
confusing to some people.
Although a vulnerability statement such as "First one still has the
possibility of injecting '\r' before the first '\n'" can be associated
with the concept of an incomplete fix, MITRE does not consider the fix
to be an "incomplete fix for" a different CVE (that references a
better patch). In our terminology, the "incomplete fix for" phrase is
only used for pointers in the opposite direction. And, of course, CVEs
are assigned to vulnerabilities, not to fixes.
>The second one kills the protection for the NUL byte check, so it won't
>allow header splitting for Apache SAPI, but FastCGI stuff will be affected,
A mostly unrelated comment is that MITRE doesn't associate the
"incomplete fix" concept with this "kills the protection for the NUL
byte check" issue. A code change occurred during the process of trying
to fix a vulnerability, but the effect of the code change was to
introduce a different vulnerability.
- --
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (SunOS)
iQEcBAEBAgAGBQJQRk5FAAoJEGvefgSNfHMdQFoIAMBTeZtPoZHxY1a3UtCkV6H0
cB8//BTAhm60tUjoaR9YE+VOYYxkPqLAzGG/U0Mv+Zg4atOBAv6i2YZdsDnt6Pih
+13H2jv1GGtbqBeLu69b9b+9ehrLNJ1tcrQCJEMOFBtZqvTBh7do5m8pRBsUjjNp
zVWdBaz3/ISm0SiNbQ2GRY6kqc169mhh56cJ8vPpG1ZNP7xSzTgQtPR+o5+DbV84
30BAp97kwykdc5EBsRqaAA5ZRvCVSHNl0Hz9YD/9YGDJN3KOxJSys0hPuloEFk/B
Exaa5VdrPearyf0U+HdiJ+ZFwGiqNIrZqfbE8iO+mP8SfS9hiltHTEhhMJlsw0o=
=9KKK
-----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
