Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 4 Sep 2012 15:02:25 -0400 (EDT)
Subject: Re: php header() header injection detection bypass

Hash: SHA1

> - 5.3.11,
>   has the issue completely fixed

Note that, in the 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

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 ]
Version: GnuPG v1.4.11 (SunOS)


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.