RE: CVE request: XSS in MantisBT

["P Richards" <paul () mantisforge org>]

Hi Damien,

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?

This fix was set to trigger an error if a user tried to set a value of filter_config_id through any means.

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.  

If we look at the initial commit: 

Line 167 : $t_filter_config_value  = gpc_get_string( 'filter_config_id', META_FILTER_NONE );
Line 191 : $t_filter_config_value  = $t_cookie_contents[2];

Lines 199 to Line 206 add the following code:

+if( !is_blank( $t_filter_config_value ) && (int)$t_filter_config_value !== META_FILTER_NONE ) {
+       // check that config value exists
+       if( @config_get_global( $t_filter_config_value ) === null ) {
+               $t_cookie_path = config_get( 'cookie_path' );
+               gpc_clear_cookie( $t_cookie_name, $t_cookie_path );
+
+               trigger_error( ERROR_GENERIC, ERROR );
+       }
+}

The code block in lines 199 to 206 is executed on all code paths before display of any information to user.

It seems you then modified the fix for this vulnerability in August to re-introduce the vulnerability by moving the fix 
for the XSS issue in adm_config_page.php with filter_config_id being unchecked to a specific code path (i.e. only to 
apply to cookie values). See https://github.com/mantisbt/mantisbt/commit/3d0625d84d5d08a998673713df1711e1d46b0b86

And now are requesting a CVE for the new issue crediting a different research company 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? Or could you confirm what CVE ID was initially 
issued for this fix which I can use when publishing the discovery information for this issue with the 31st May 2014 
date.

Thanks
Paul

-----Original Message-----
From: Damien Regad [mailto:dregad () mantisbt org] 
Sent: 09 February 2015 21:37
To: oss-security () lists openwall com
Subject: [oss-security] CVE request: XSS in MantisBT

Greetings,

Please assign a CVE ID for the following issue

Description:

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 which would be executed in the client's browser when displaying 
the page.

Affected versions:
- >= 1.2.13
- 1.3.0-beta.1

Fixed in versions:
- 1.2.20 (not yet released)
- 1.3.0-beta.2 (not yet released)

Patch:
See Github [1]

Credit:
This vulnerability was discovered by Fortinet's FortiGuard Labs (reference FG-VD-15-008 [2]) The issue was fixed by 
Damien Regad (MantisBT Developer).

References:
Further details will be available in our issue tracker [2] once this goes public.

[1] https://github.com/mantisbt/mantisbt/commit/6defeed5 (1.2.x)
     https://github.com/mantisbt/mantisbt/commit/3c6f6e56 (1.3.x) [2] 
http://www.fortiguard.com/advisory/UpcomingAdvisories.html
[3] https://www.mantisbt.org/bugs/view.php?id=19301