1. Introduction
Request Tracker 4.2.x prior to 4.2.5 contains a denial of service vulnerability in the Email::Address:List module. This means an attacker could crash the web server by sending specially crafted email addresses. This affects businesses running Request Tracker as their issue tracking system, potentially causing downtime and loss of service availability.
2. Technical Explanation
The vulnerability is caused by an algorithmic complexity flaw in the Perl CPAN Email::Address:List module used by Request Tracker. An attacker can submit a string without a valid address which causes excessive CPU usage, leading to a denial of service. This has been identified as CVE-2014-1474.
- Root cause: The Email::Address:List module does not efficiently handle long or complex strings when parsing email addresses.
- Exploit mechanism: An attacker sends an HTTP request containing a crafted string in a field processed by the Email::Address:List module, triggering high CPU consumption. For example, submitting a very long string as part of a new ticket request.
- Scope: Request Tracker versions 4.2.x prior to 4.2.5 are affected.
3. Detection and Assessment
You can check the version of Request Tracker running on your server to determine if it is vulnerable. Scanning tools may also identify this issue.
- Quick checks: Check the ‘About’ page in the Request Tracker web interface for the version number.
- Scanning: Nessus ID 68690 can detect systems potentially running a vulnerable version of Request Tracker, based on self-reported version information.
- Logs and evidence: Review application logs for high CPU usage spikes coinciding with unusual activity or ticket submissions.
# Example command placeholder:
# Check the RT version from the command line (may require access to RT configuration files)
# grep -i version /opt/rt/etc/RT_Config.pm
4. Solution / Remediation Steps
Upgrade Request Tracker to version 4.2.5 or later to resolve this vulnerability.
4.1 Preparation
- Stopping the webserver is not required, but may reduce load during the upgrade process. A roll back plan involves restoring the backed-up database and configuration files.
- Changes should be scheduled during a maintenance window with appropriate approval from IT management.
4.2 Implementation
- Step 1: Download Request Tracker version 4.2.5 or later from the Best Practical Solutions website.
- Step 2: Stop the web server running Request Tracker (e.g., Apache, Nginx).
- Step 3: Back up the existing Request Tracker installation directory.
- Step 4: Extract the downloaded archive to your desired installation location.
- Step 5: Restore your backed-up database and configuration files to the new installation.
- Step 6: Verify file permissions are correct for the web server user.
- Step 7: Start the web server.
4.3 Config or Code Example
Before
# No specific code example, as this is a version vulnerability. Confirming version < 4.2.5 indicates exposure.
After
# Confirm the RT version is now >= 4.2.5 via the 'About' page in the web interface or by checking RT_Config.pm
4.4 Security Practices Relevant to This Vulnerability
Regular patching and updates are crucial for mitigating vulnerabilities like this one. Input validation can also help prevent malicious data from being processed.
- Practice 1: Implement a regular patch cadence for all software, including Request Tracker.
- Practice 2: Enforce input validation on all user-supplied data to block potentially harmful strings.
4.5 Automation (Optional)
If using configuration management tools, automate the upgrade process to ensure consistent patching across your environment.
# Example Ansible snippet (requires adaptation for your specific environment):
# - name: Upgrade Request Tracker
# apt:
# name: requesttracker4
# state: latest
# become: true
5. Verification / Validation
- Post-fix check: Check the 'About' page in the web interface; it should display a version number greater than or equal to 4.2.5.
- Re-test: Run Nessus scan ID 68690 again, which should no longer report the vulnerability.
- Smoke test: Create and update a ticket as a normal user to ensure basic functionality is working correctly.
# Post-fix command and expected output (example):
# grep -i version /opt/rt/etc/RT_Config.pm
# $Version = '4.2.5'; (or higher)
6. Preventive Measures and Monitoring
Update your security baselines to require Request Tracker versions 4.2.5 or later. Consider adding automated checks in your CI/CD pipeline.
- Baselines: Update your internal security baseline document to specify a minimum supported version of Request Tracker (4.2.5).
- Asset and patch process: Review and update your asset inventory and patching schedule to ensure timely updates for all critical systems, including Request Tracker.
7. Risks, Side Effects, and Roll Back
Upgrading Request Tracker may introduce compatibility issues with customisations or integrations. Always test thoroughly in a non-production environment first.
- Risk or side effect 2: Temporary downtime during the upgrade process. Mitigation: Schedule the upgrade during a maintenance window.
- Roll back: Restore the backed-up database and configuration files, then restart the web server. Revert any changes made to file permissions.
8. References and Resources
- Vendor advisory or bulletin: https://docs.bestpractical.com/release-notes/rt/4.2.5
- NVD or CVE entry: CVE-2014-1474
- Product or platform documentation relevant to the fix: https://docs.bestpractical.com/release-notes/rt/4.2.5