1. Introduction
The Request Tracker 4.0.x prior to 4.0.23 and 4.2.x prior to 4.2.10 application has multiple vulnerabilities that could allow a remote attacker to cause a denial of service, obtain sensitive data, or log in as another user. This affects organisations using the Best Practical Solutions Request Tracker web server software. A successful exploit could compromise confidentiality, integrity and availability of ticket data.
2. Technical Explanation
The vulnerabilities stem from flaws within the RT application’s email gateway and handling of RSS feed URLs. Attackers can exploit these to gain unauthorised access or disrupt service. The Nessus scanner relies on self-reported version numbers for detection, so accurate reporting is essential.
- Root cause: Flaws in email processing (CVE-2014-9472) and RSS feed URL handling (CVE-2015-1165 & CVE-2015-1464).
- Exploit mechanism: A crafted email can trigger a denial of service. Sensitive URLs and ticket data may be accessible via unspecified vectors. An attacker could log in as the user who created an RSS feed.
3. Detection and Assessment
Confirming vulnerability involves checking the RT application version. A thorough assessment requires reviewing logs for suspicious activity related to RSS feeds or email processing.
- Quick checks: Check the RT web interface ‘About’ page for the version number.
- Scanning: Nessus plugin ID is not specified in the context provided.
- Logs and evidence: Review RT application logs for unusual errors related to email parsing or RSS feed requests. Specific log paths are not available from this information.
# No command example available as version check requires UI access.4. Solution / Remediation Steps
Upgrade the Request Tracker application to a patched version. Follow standard change management procedures.
4.1 Preparation
- Ensure you have access to the latest RT installation packages. A roll back plan is to restore from the pre-upgrade backups.
- A change window may be required for a production upgrade, with approval from relevant IT stakeholders.
4.2 Implementation
- Step 1: Download the Request Tracker version 4.0.23 or 4.2.10 installation package from the Best Practical Solutions website.
- Step 2: Stop the RT web server service (e.g., Apache, Nginx).
- Step 3: Back up the existing RT installation directory.
- Step 4: Install the new version of Request Tracker over the existing installation.
- Step 5: Restore any custom configurations from your backup.
- Step 6: Start the RT web server service.
4.3 Config or Code Example
Before
# Version information prior to patch:
RT version 4.0.x < 4.0.23 or 4.2.x < 4.2.10After
# Version information after patch:
RT version 4.0.23 or 4.2.10 (or later)4.4 Security Practices Relevant to This Vulnerability
Practices that help prevent this issue include a regular patch cadence and input validation.
- Practice 1: Implement a consistent patch management process for all applications, including Request Tracker.
- Practice 2: Ensure any custom code or plugins used with RT validate user inputs to prevent injection attacks.
4.5 Automation (Optional)
No automation script is provided as this depends on the specific installation method.
5. Verification / Validation
Confirm the upgrade by checking the application version and verifying core functionality. A negative test could involve attempting to exploit a known vulnerability from CVE-2014-9472, which should now be blocked.
- Post-fix check: Check the RT web interface ‘About’ page for version 4.0.23 or 4.2.10 (or later).
- Re-test: Re-run the initial version check to confirm the upgrade was successful.
- Smoke test: Verify that users can log in, create tickets, and send emails through RT.
- Monitoring: Monitor application logs for errors related to email processing or RSS feeds as a baseline.
# No command example available as version check requires UI access.6. Preventive Measures and Monitoring
Update security baselines to require patched versions of Request Tracker. Consider adding checks in your CI/CD pipeline.
- Baselines: Update your security baseline or policy to specify a minimum required version for Request Tracker (4.0.23 or 4.2.10).
- Asset and patch process: Review and update the asset inventory to include all instances of Request Tracker, and establish a regular patch review cycle (e.g., monthly).
7. Risks, Side Effects, and Roll Back
Upgrading may introduce compatibility issues with custom configurations or plugins. A roll back involves restoring from pre-upgrade backups.
- Risk or side effect 1: Compatibility issues with existing customizations. Mitigation: Thoroughly test the upgrade in a non-production environment first.
- Risk or side effect 2: Service downtime during the upgrade process. Mitigation: Schedule the upgrade during off-peak hours and communicate planned downtime to users.
- Roll back: 1) Stop the RT web server service. 2) Restore the database from backup. 3) Restore the original installation directory from backup. 4) Start the RT web server service.
8. References and Resources
- Vendor advisory or bulletin: https://docs.bestpractical.com/release-notes/rt/4.2.10
- NVD or CVE entry: Not specified in the context provided, but can be found by searching for CVE-2014-9472, CVE-2015-1165 and CVE-2015-1464 on the NVD website.
- Product or platform documentation relevant to the fix: https://docs.bestpractical.com/release-notes/rt/4.2.10