Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 13 Feb 2015 22:53:16 +0100
From: Damien Regad <dregad@...tisbt.org>
To: oss-security@...ts.openwall.com
Subject: Re: CVE request: XSS in MantisBT

On 2015-02-10 01:41, P Richards wrote:
 > This issue looks fairly like the issue previously identified in
 > adm_config_report.php in May 2014, as an XSS. See
 > 
https://github.com/mantisbt/mantisbt/commit/cabacdc291c251bfde0dc2a2c945c02cef41bf40
 > I'm still waiting for the CVE to be provided for
 > cabacdc291c251bfde0dc2a2c945c02cef41bf40 from May, or could you let
 > me know what CVE was assigned for the initial fix?

A 5 seconds search through the MantisBT changesets tells me that it was 
CVE-2014-8986.
See https://www.mantisbt.org/bugs/view.php?id=17889.

Which, by the way, would have been even easier for you to find if you 
had actually bothered to follow the process and report the security 
issue in our tracker yourself instead of emailing me that PDF file of 
yours and making me do the legwork.

 > And in fact, it looking at the diff, my initial thought was you were
 > trying to take a vulnerability discovered by myself and pass it off
 > as something new crediting someone else and yourself for the fix -
 > although it may be this was unintentional as it appears you
 > re-introduced the same bug a few months after the initial fix.

You know, this really sounds like paranoia... You know me, and should 
know better. I have never taken credit for somebody else's work. Credit 
was given, where it was due:
http://thread.gmane.org/gmane.comp.security.oss.general/14706/focus=14849

 > [...]
 >
 > It seems you then modified the fix for this vulnerability in August
 > to re-introduce the vulnerability [...]
 >
 > And now are requesting a CVE for the new issue crediting a different
 > researchcompany for the 'new vulnerability', with no mention of the
 > original discovery for this issue in May 2014.
 >
 > @Mitre: How is this handled? Do you assign two CVE's in this case?

As far as I can tell, while related, these are indeed 2 distinct issues 
even though they are evidently related.

Quite frankly, I just can't be bothered to analyze whether my follow-up 
fix for CVE-2014-8986 reintroduced the issue or not.

Even if I did, the fact remains that 1.2.19 was released as it was, so 
we DO have two distinct issues here in any case.

D


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.