[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 10 Feb 2015 00:41:01 -0000
From: "P Richards" <paul@...tisforge.org>
To: <oss-security@...ts.openwall.com>
Cc: <cve-assign@...re.org>
Subject: RE: CVE request: XSS in MantisBT
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@...tisbt.org]
Sent: 09 February 2015 21:37
To: oss-security@...ts.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
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.
