Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 20 Feb 2015 22:13:41 -0500 (EST)
Subject: Re: CVE request: XSS in MantisBT

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 - this is
      a discussion of the original report; it is not the original report

  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)

  a second vulnerability report is made that corresponds to a valid
  attack against the changed code:

The following items, although significant to understanding the
situation as a whole, do not directly affect the set of CVE

  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

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 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 ]
Version: GnuPG v1.4.14 (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.