Changesets: MantisBT
|
master-1.2.x e679a1c0 2011-09-05 02:36 Details Diff |
Fix 0013191: Prevent further XSS issues relating to PHP_SELF Silvia Alvarez (Debian package manager for MantisBT) has performed additional testing of patch d00745f5e267eba4ca34286d125de685bc3a8034 and discovered that the XSS problems surrounding the use of $_SERVER['PHP_SELF'] have not been fully fixed. The form_action_self() function also used $_SERVER['PHP_SELF'] (retrieving the basename() component of the file name). Callees of this function did not escape this file name prior to printing it in the 'action' attribute of <form> elements. This patch swaps out PHP_SELF for SCRIPT_NAME (much safer as end users have no control over the value) and also applies escaping to the 'action' attribute of relevant <form> elements. Refer to Debian bug report #640297 [1] and dicussion on the mantisbt-dev mailing list for further details. Thank you Sils for the detailed analysis of the problem, detailed report, proposed solutions and extensive testing of patches for the latest round of vulnerabilities discovered. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640297 |
Affected Issues 0013191 |
|
| mod - billing_inc.php | Diff File | ||
| mod - bugnote_stats_inc.php | Diff File | ||
| mod - core/authentication_api.php | Diff File | ||
| mod - core/form_api.php | Diff File | ||
| mod - core/helper_api.php | Diff File | ||
| mod - manage_config_email_page.php | Diff File | ||
| mod - manage_config_work_threshold_page.php | Diff File | ||
| mod - manage_config_workflow_page.php | Diff File | ||
|
master 94e68102 2011-09-05 01:34 Details Diff |
Fix 0012361: Private bug visibility leak in my_view/view_all_bug_page In the My View / View Issues screens, private bugs in public projects (and probably private projects too) appear to ignore the private_bug_threshold value of their project unless you select it. When some projects have tighter security on viewing private bugs than others, this creates a situation where a user who should not be able to see a bug can still discover its existence in My View and View Issues. Viewing it fails with 'access denied', but if the summary had confidential information in it then the security leak has already happened. I don't consider giving All Projects the tighter security to be a usable workaround, because then you can't find bugs in the projects that use normal security for private bugs, until you select one of them, but then you can only see the subproject hierarchy you just went into. Steps to reproduce: ------ On a fresh 1.2.2 install try this: Create a public project. In the project, edit thresholds so that you need manager to view private bugs. Submit a private bug to that project. Login as a different user with global access of developer. View All Projects. You can see the bug in MyView / ViewIssues but then when you click on it you get an Access Denied screen. If you select the bug's project, then it correctly disappears. ------ Signed-off-by: David Hicks <d@hx.id.au> |
Affected Issues 0012361 |
|
| mod - core/filter_api.php | Diff File | ||
|
master-1.2.x cb74408f 2011-09-05 01:34 Details Diff |
Fix 0012361: Private bug visibility leak in my_view/view_all_bug_page In the My View / View Issues screens, private bugs in public projects (and probably private projects too) appear to ignore the private_bug_threshold value of their project unless you select it. When some projects have tighter security on viewing private bugs than others, this creates a situation where a user who should not be able to see a bug can still discover its existence in My View and View Issues. Viewing it fails with 'access denied', but if the summary had confidential information in it then the security leak has already happened. I don't consider giving All Projects the tighter security to be a usable workaround, because then you can't find bugs in the projects that use normal security for private bugs, until you select one of them, but then you can only see the subproject hierarchy you just went into. Steps to reproduce: ------ On a fresh 1.2.2 install try this: Create a public project. In the project, edit thresholds so that you need manager to view private bugs. Submit a private bug to that project. Login as a different user with global access of developer. View All Projects. You can see the bug in MyView / ViewIssues but then when you click on it you get an Access Denied screen. If you select the bug's project, then it correctly disappears. ------ Signed-off-by: David Hicks <d@hx.id.au> |
Affected Issues 0012361 |
|
| mod - core/filter_api.php | Diff File | ||
|
master-2.0.x 495303bb 2011-09-05 01:34 Todd Whitesel Committer: Paul Richards Details Diff |
Fix 0012361: Private bug visibility leak in my_view/view_all_bug_page In the My View / View Issues screens, private bugs in public projects (and probably private projects too) appear to ignore the private_bug_threshold value of their project unless you select it. When some projects have tighter security on viewing private bugs than others, this creates a situation where a user who should not be able to see a bug can still discover its existence in My View and View Issues. Viewing it fails with 'access denied', but if the summary had confidential information in it then the security leak has already happened. I don't consider giving All Projects the tighter security to be a usable workaround, because then you can't find bugs in the projects that use normal security for private bugs, until you select one of them, but then you can only see the subproject hierarchy you just went into. Steps to reproduce: ------ On a fresh 1.2.2 install try this: Create a public project. In the project, edit thresholds so that you need manager to view private bugs. Submit a private bug to that project. Login as a different user with global access of developer. View All Projects. You can see the bug in MyView / ViewIssues but then when you click on it you get an Access Denied screen. If you select the bug's project, then it correctly disappears. ------ Signed-off-by: David Hicks <d@hx.id.au> |
||
| mod - core/filter_api.php | Diff File | ||
|
master b08e9c16 2011-09-05 01:15 Details Diff |
Fix 0013140: Incorrect permissions check during bug reporting and cloning Todd Whitesel reported an issue with incorrect permissions checks being performed when cloning issues. The steps to reproduce this bug were provided by Todd: ------ Fresh 1.2.5 install. Create two users, a Developer and an Updater. Create a private project. (Actually create a couple more projects so you can see the project selector.) Add both users to the private project AS MANAGERS. Login as Developer, select the private project, and create an issue. Login as Updater, select All Projects, and attempt to clone that issue. It fails with ACCESS DENIED error #13. Also note that your access level was Manager while editing the cloned issue, but in the error screen your access level is back to your global access of Updater. As Updater, Select the private project, create an issue. Then select All Projects, and attempt to clone that issue. It succeeds, apparently because you are cloning your own issue. Create a public project and attach the private project as a subproject of it. Retry the above cloning tests with the public parent project instead of All Projects -- the results are the same whether you select All Projects or the parent project. ------ The problem was that the current project (from the project selector dropdown) was used as the basis for config_get calls, thus leading to incorrect permissions and settings being used within bug_report.php. We need to instead switch (temporarily) the current project to either the master issue (when cloning) or the specified project_id (when creating a new issue via bug_report_page.php). Thanks again to Todd for the discovery and debugging of this problem, the detailed bug report and initial patch (that has been extended to resolve the second project_id issue from bug_report_page.php). Conflicts: bug_report.php |
Affected Issues 0013140 |
|
| mod - bug_report.php | Diff File | ||
|
master-1.2.x 9be5d99a 2011-09-05 01:15 Details Diff |
Fix 0013140: Incorrect permissions check during bug reporting and cloning Todd Whitesel reported an issue with incorrect permissions checks being performed when cloning issues. The steps to reproduce this bug were provided by Todd: ------ Fresh 1.2.5 install. Create two users, a Developer and an Updater. Create a private project. (Actually create a couple more projects so you can see the project selector.) Add both users to the private project AS MANAGERS. Login as Developer, select the private project, and create an issue. Login as Updater, select All Projects, and attempt to clone that issue. It fails with ACCESS DENIED error #13. Also note that your access level was Manager while editing the cloned issue, but in the error screen your access level is back to your global access of Updater. As Updater, Select the private project, create an issue. Then select All Projects, and attempt to clone that issue. It succeeds, apparently because you are cloning your own issue. Create a public project and attach the private project as a subproject of it. Retry the above cloning tests with the public parent project instead of All Projects -- the results are the same whether you select All Projects or the parent project. ------ The problem was that the current project (from the project selector dropdown) was used as the basis for config_get calls, thus leading to incorrect permissions and settings being used within bug_report.php. We need to instead switch (temporarily) the current project to either the master issue (when cloning) or the specified project_id (when creating a new issue via bug_report_page.php). Thanks again to Todd for the discovery and debugging of this problem, the detailed bug report and initial patch (that has been extended to resolve the second project_id issue from bug_report_page.php). |
Affected Issues 0013140 |
|
| mod - bug_report.php | Diff File | ||
|
master 7af2f47a 2011-09-05 00:41 Details Diff |
Fix 0013141: Incorrect parameters to config_get function Thanks to Todd Whitesel for finding this problem in filter_api.php and to Roland Becker for providing further assistance. I have grepped the source code and reviewed all other calls to config_get to ensure they correctly use parameters. There was one additional bug discovered in bug_report_page.php. Conflicts: bug_report_page.php |
Affected Issues 0013141 |
|
| mod - bug_report_page.php | Diff File | ||
| mod - core/filter_api.php | Diff File | ||
|
master-1.2.x 955d1cb5 2011-09-05 00:41 Details Diff |
Fix 0013141: Incorrect parameters to config_get function Thanks to Todd Whitesel for finding this problem in filter_api.php and to Roland Becker for providing further assistance. I have grepped the source code and reviewed all other calls to config_get to ensure they correctly use parameters. There was one additional bug discovered in bug_report_page.php. |
Affected Issues 0013141 |
|
| mod - bug_report_page.php | Diff File | ||
| mod - core/filter_api.php | Diff File | ||
|
master-1.2.x cb67e6a6 2011-09-05 00:21 Details Diff |
Remove use of filter_var(...) for master-1.2.x Robert Munteanu correctly mentioned on the mailing list that the master-1.2.x branch needs to work with PHP 5.1. The filter_var(...) function is not available in PHP <5.2 and therefore we can't use it in the master-1.2.x branch. We can achieve similar results by removing all null characters from the string (\0). This is OK for our use case which is the use of $_SERVER['SCRIPT_NAME'] - a value that is set by the server and cannot be manipulated by remote users (like PHP_SELF). |
||
| mod - config_defaults_inc.php | Diff File | ||
|
master 674fbf70 2011-09-04 23:21 Details Diff |
Initialize table prefix and suffix to short values within install.php for Oracle This allows the installer to automatically setup a config_inc.php file with appropriately short values, avoiding multiple steps and errors during the install process for oci8. Porting to 1.3 - Conflicts: admin/install.php |
||
| mod - admin/install.php | Diff File | ||
|
master-1.2.x cad51f20 2011-09-04 22:34 Details Diff |
Correct access_has_any_project checks in print_column_selection The access_has_any_project method call takes a user, not a project parameter. |
||
| mod - core/columns_api.php | Diff File | ||
|
master-1.2.x 338208c5 2011-09-03 22:58 Details Diff |
Allow more control over the excel api's output The following changes have been made: - allow declaration of Spreadsheet styles to control the appearance of rows and cells - allow setting of attributes on individual cells The actual output of the excel export is unchanged. The API changes are completely backwards compatible. Fixes 0013290: Allow more control over excel export format |
Affected Issues 0013290 |
|
| mod - core/excel_api.php | Diff File | ||
|
master 887d9e50 2011-09-03 22:58 Details Diff |
Allow more control over the excel api's output The following changes have been made: - allow declaration of Spreadsheet styles to control the appearance of rows and cells - allow setting of attributes on individual cells The actual output of the excel export is unchanged. The API changes are completely backwards compatible. Fixes 0013290: Allow more control over excel export format |
Affected Issues 0013290 |
|
| mod - core/excel_api.php | Diff File | ||
|
master 03f1c7b0 2011-09-03 22:17 Paul Richards Details Diff |
Using just script_name is OK, but it's feasible that SCRIPT_NAME isn't set - this is more common in (badly configured?) nginx servers | ||
| mod - config_defaults_inc.php | Diff File | ||
|
master-1.2.x 98833635 2011-09-03 18:40 Details Diff |
Bump version to 1.2.8 and update release notes | ||
| mod - core/constant_inc.php | Diff File | ||
| mod - doc/RELEASE | Diff File | ||
|
master-1.2.x 0a636b37 2011-09-03 16:36 Details Diff |
Issue 0013281: Fix Projax XSS issues (unescaped value attributes) Projax sucks. This is why it was replaced with jQuery in the master branch. However master-1.2.x still uses the older Projax code. The Projax library doesn't attempt to escape values before dumping them in HTML output, thus leading to XSS issues. The easiest workaround is to pass in already-escaped values to the Projax functions. This issue was reported by High-Tech Bridge SA Security Research Lab as part of their advisory #HTB23045, available at https://www.htbridge.ch/advisory/multiple_vulnerabilities_in_mantisbt.html |
Affected Issues 0013281 |
|
| mod - bug_report_page.php | Diff File | ||
| mod - bug_update_advanced_page.php | Diff File | ||
|
master e2f30f70 2011-09-03 16:21 Details Diff |
Remove unreachable code branch in config_defaults_inc.php Commit 57c944856712cf3fdc7855d10db07da93a82e863 introduced an unreachable code branch that has no effect. Removed. The functionality will likely need to be rechecked by Paul/John to see whether we do want to use PHP_SELF. |
||
| mod - config_defaults_inc.php | Diff File | ||
|
master-1.2.x 965b00a0 2011-09-03 15:34 Details Diff |
Revert "Fix 0013282, 0013283: bug_actiongroup_ext_page.php LFI and XSS" This reverts commit a7eacc181185eff1dd7bd8ceaa34a91cf86cc298. Paul fixed this in a better way with commit a908cc61362059025910e2437d55bedc31863139 (to be backported to 1.2.x after this older commit is reverted). |
Affected Issues 0013282, 0013283 |
|
| mod - bug_actiongroup_ext_page.php | Diff File | ||
| mod - core/bug_group_action_api.php | Diff File | ||
|
master f3df5f1c 2011-09-02 02:07 Details Diff |
Modified generated SQL for triggers in install.php to work with Oracle sqlplus "CREATE OR REPLACE TRIGGER" statements must end with END; / to work for Oracle sqlplus Original patch provided by Carsten Grohmann in issue 0013227 Porting to 1.3 - Conflicts: admin/install.php |
Affected Issues 0013227 |
|
| mod - admin/install.php | Diff File | ||
|
master 803446e9 2011-09-02 01:58 Details Diff |
Improve Oracle DB connection check in install.php Oracle supports DB bindings in two ways: 1. Use hostname, username/password and database name 2. Use tns name (insert into hostname field) and username/password, database name is still empty Original patch provided by Carsten Grohmann in issue 0013227 Porting to 1.3 - Conflicts: admin/install.php |
Affected Issues 0013227 |
|
| mod - admin/install.php | Diff File | ||
|
master-1.2.x a7eacc18 2011-08-31 22:36 Details Diff |
Fix 0013282, 0013283: bug_actiongroup_ext_page.php LFI and XSS High-Tech Bridge SA Security Research Lab reported 2 issues with the 'action' parameter to bug_actiongroup_ext_page.php Issue 0013282 XSS issue with require_once() call failures returning an unescaped user-supplied filename. There has been a fair amount of recent public talk about PHP error messages being a source of XSS issues. This is an example. Issue 0012283 Local file inclusion/path traversal vulnerability on web servers that allow translations like: http://example.com/directory/file.htm/../file2.htm ==> http://example.com/directory/file2.htm Vulnerable (default configuration): Apache Not vulnerable (default configuration): nginx This issue has _SEVERE_ consequences for people using web servers which don't check each segment of a path from top to bottom for validity. It shouldn't be possible to include the contents of config_inc.php to retrieve MantisBT database passwords because require_once('config_inc.php') will parse the document as a PHP script (echoing nothing). However it may allow attackers to view private files accessible to the web server user account. It also allows an attacker to guess the file structure of a server (existence of installed software, user accounts, etc). nginx will produce a 404 error when it determines that file.htm is not a directory. This makes too much sense, doesn't it? |
Affected Issues 0013282, 0013283 |
|
| mod - bug_actiongroup_ext_page.php | Diff File | ||
| mod - core/bug_group_action_api.php | Diff File | ||
|
master c12a32af 2011-08-31 22:36 Details Diff |
Fix 0013282, 0013283: bug_actiongroup_ext_page.php LFI and XSS High-Tech Bridge SA Security Research Lab reported 2 issues with the 'action' parameter to bug_actiongroup_ext_page.php Issue 0013282 XSS issue with require_once() call failures returning an unescaped user-supplied filename. There has been a fair amount of recent public talk about PHP error messages being a source of XSS issues. This is an example. Issue 0012283 Local file inclusion/path traversal vulnerability on web servers that allow translations like: http://example.com/directory/file.htm/../file2.htm ==> http://example.com/directory/file2.htm Vulnerable (default configuration): Apache Not vulnerable (default configuration): nginx This issue has _SEVERE_ consequences for people using web servers which don't check each segment of a path from top to bottom for validity. It shouldn't be possible to include the contents of config_inc.php to retrieve MantisBT database passwords because require_once('config_inc.php') will parse the document as a PHP script (echoing nothing). However it may allow attackers to view private files accessible to the web server user account. It also allows an attacker to guess the file structure of a server (existence of installed software, user accounts, etc). nginx will produce a 404 error when it determines that file.htm is not a directory. This makes too much sense, doesn't it? Conflicts: bug_actiongroup_ext_page.php core/bug_group_action_api.php |
Affected Issues 0013282, 0013283 |
|
| mod - bug_actiongroup_ext_page.php | Diff File | ||
| mod - core/bug_group_action_api.php | Diff File | ||
|
master ce56bd57 2011-08-31 02:32 Details Diff |
Obsolete $g_show_attachment_indicator option Following discussion with dhx on IRC on 31-Aug-2011, this setting is not necessary. There is no point or advantage in displaying a paperclip bitmap as opposed to the actual number of attachments; furthermore, the option was inconsistently used, in one instance it was actually hiding the attachments column completely Affects issue 0013276 Porting 3323204d0c3e6031b182b7113e7afb99d861588d to master |
Affected Issues 0013276 |
|
| mod - config_defaults_inc.php | Diff File | ||
| mod - core/columns_api.php | Diff File | ||
| mod - core/helper_api.php | Diff File | ||
| mod - core/obsolete.php | Diff File | ||
|
master-1.2.x 3323204d 2011-08-31 02:32 Details Diff |
Obsolete $g_show_attachment_indicator option Following discussion with dhx on IRC today, this setting is not necessary. There is no point or advantage in displaying a paperclip bitmap as opposed to the actual number of attachments; furthermore, the option was inconsistently used, in one instance it was actually hiding the attachments column completely Affects issue 0013276 Commit also removes trailing whitespace in columns_api.php |
Affected Issues 0013276 |
|
| mod - config_defaults_inc.php | Diff File | ||
| mod - core/columns_api.php | Diff File | ||
| mod - core/helper_api.php | Diff File | ||
| mod - core/obsolete.php | Diff File | ||
|
master 791b9365 2011-08-31 02:22 Details Diff |
Removed obsolete comment file_can_view_bug_attachments does check for allow_view_own_attachments |
||
| mod - core/columns_api.php | Diff File | ||
