[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <002301d04dbc$b0dc4380$1294ca80$@mantisforge.org>
Date: Sat, 21 Feb 2015 09:56:39 -0000
From: "P Richards" <paul@...tisforge.org>
To: <cve-assign@...re.org>,
<dregad@...tisbt.org>
Cc: <oss-security@...ts.openwall.com>
Subject: RE: CVE request: XSS in MantisBT
Hi, I'm now confused.
" A. We do not plan to change
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8986 to
state that 1.2.18 and 1.2.19 are affected versions. CVE-2014-8986
is now specifically about types of attacks that are successful
against 1.2.17 but are not successful against 1.2.18 or 1.2.19."
The original vulnerability was to allow users to inject arbitrary html for
xss via the filter_config_id parameter. For example:
e.g. a POST or GET to /adm_config_report.php with
filter_config_id=database_version'/><script>alert(4849)</script>;
This is successful against 1.2.17, 1.2.18 and 1.2.19.
I'm not actually sure what "types of attacks" are blocked by CVE-2014-8986
in its current state as mantis has remained vulnerable to the issue
throughout.
I've already created bug reports with linux distributions that ship mantis
1.2.18 and stated that CVE-2014-8986 was included that the fix the
vulnerability was not included so as they can protect their customers, as
from the test cases I have here the issues that I originally identified were
never fixed.
Thanks
Paul
-----Original Message-----
From: cve-assign@...re.org [mailto:cve-assign@...re.org]
Sent: 21 February 2015 03:14
To: dregad@...tisbt.org
Cc: cve-assign@...re.org; oss-security@...ts.openwall.com;
paul@...tisforge.org
Subject: Re: CVE request: XSS in MantisBT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> The MantisBT Configuration Report (adm_config_report.php) did not
> properly sanitize the form variables used when saving a filter,
> allowing an attacker to embed JavaScript code
The details of this situation are somewhat unusual from the perspective of
CVE assignment. The short answer is that CVE-2015-2046 is a new CVE ID that
is about the specific portion of the original May
2014 adm_config_report.php discovery that remains present in version
1.2.18 and 1.2.19.
The meaning of CVE-2014-8986 has now been changed to the specific portion of
the original May 2014 adm_config_report.php discovery that was already fixed
in version 1.2.18.
The set of CVE assignments has been arranged this way because it corresponds
to a standard pattern in which one vulnerability report is made, the vendor
releases changed code that turns out to be an incomplete fix for the
vulnerability, and then a second vulnerability report is made that
corresponds to a valid attack against the changed code. This matches some of
the principal details of the current situation, e.g.,
one vulnerability report is made:
adm_config_page.php had an XSS issue with filter_config_id being
unchecked
(see http://openwall.com/lists/oss-security/2015/02/10/1 - this is
a discussion of the original report; it is not the original report
itself)
the vendor releases changed code:
- In 1.3, cabacdc2 + 3d0625d8 together form at least a *partial* fix
for
[the above vulnerability report] (released in 1.3.0-beta.1)
- In 1.2, e326b73a is a combination of the above 2 (released in 1.2.18)
(see http://openwall.com/lists/oss-security/2015/02/16/7)
a second vulnerability report is made that corresponds to a valid
attack against the changed code:
(see http://openwall.com/lists/oss-security/2015/02/09/10)
The following items, although significant to understanding the situation as
a whole, do not directly affect the set of CVE
assignments:
1. The development of the cabacdc291c251bfde0dc2a2c945c02cef41bf40
change, which was apparently a complete fix for all aspects of
the problem.
2. The commit of cabacdc291c251bfde0dc2a2c945c02cef41bf40 on May 31,
2014, which apparently would have fixed all aspects of the
problem if a user deployed a MantisBT installation based on the
latest May 31, 2014 github code, instead of one based on a
MantisBT release.
3. The specific way in which
cabacdc291c251bfde0dc2a2c945c02cef41bf40 was transformed into an
incomplete fix (e.g., by moving a code block so that it affected
only a single code path).
4. The original meaning of the CVE-2014-8986 ID.
5. The possibility that the FG-VD-15-008 discovery relied, in part,
on previously published information, rather than exclusively new
analysis.
The reason that this set of CVE assignments is unusual is that, in a common
"incomplete fix" situation, the reason for issuing a release with an
incomplete fix is that nobody recognized how to fix the entire problem. In
those situations, it is typically not necessary to adjust the meaning of the
original CVE, because that CVE usually captures everything that was
originally known about the problem. Here, apparently one or more persons
knew that
cabacdc291c251bfde0dc2a2c945c02cef41bf40 was the complete fix, but the
1.2.18 release still did not ship with that complete fix.
Finally, to anticipate two questions:
A. We do not plan to change
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8986 to
state that 1.2.18 and 1.2.19 are affected versions. CVE-2014-8986
is now specifically about types of attacks that are successful
against 1.2.17 but are not successful against 1.2.18 or 1.2.19.
B. Discoverer information for CVEs is not determined or published by
MITRE. We think the most likely scenario is that the original
discoverer of CVE-2014-8986 was Paul Richards, whereas
CVE-2015-2046 was independently discovered by both Paul Richards
and FortiGuard Labs. Other possibilities exist.
- --
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.14 (SunOS)
iQEcBAEBAgAGBQJU5/dIAAoJEKllVAevmvmsiyAH/RgwlxaCqRrLB6TrY7wxVeMT
1qeelJNHYZSOpyvqBGRrhXUHt0HI3foGywj4Io+YGYLt2r6GUm47YEMsJ+YZg2Tk
FX4Rrb4eTcil8j5SSPBcrzGbaA6ZlkjSTUnXv2127OKKRYd115mWreWOovLa00OT
Z+Qp6ZnUVp3hn4DyGc8IvTXzH4VfgEcFka4SCjDZ+UDC/Jf/mEXGCb5esSJdMkmK
QyQzNE6pey4QYPxWgbrvwcouSFKyMQ6XVdh0fSPnyMvxN2JpuZr2I4KYo1JvBQmU
Z5iTS5p/fCkxNyIw3QSa0QcL+oSZM5a1v3U1HhXlxBXzpkhjzYyUPIC2kVvM1cs=
=tjY7
-----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.
