1. Introduction
The WordPress Cookie ‘cache_lastpostdate’ Parameter PHP Code Injection vulnerability allows attackers to execute arbitrary PHP code on a web server running vulnerable versions of WordPress. This is possible if the PHP ‘register_globals’ setting is enabled. Successful exploitation could lead to complete compromise of the website and underlying server. Confidentiality, integrity, and availability are all at risk.
2. Technical Explanation
This vulnerability occurs because WordPress does not properly sanitise input received in the ‘cache_lastpostdate’ cookie parameter when PHP’s ‘register_globals’ is active. This allows an attacker to inject malicious PHP code into this parameter, which will then be executed by the server. The precondition for exploitation is that the ‘register_globals’ setting must be enabled in the PHP configuration. CVE-2005-2612 details this issue.
- Root cause: Lack of input validation on the ‘cache_lastpostdate’ cookie parameter when register_globals is enabled.
- Exploit mechanism: An attacker sends a crafted HTTP request with a malicious PHP code string in the ‘cache_lastpostdate’ cookie. The server then executes this code. For example, an attacker could inject
into the cookie and execute arbitrary commands via the ‘cmd’ GET parameter. - Scope: WordPress versions prior to 1.5.2 are affected when running with PHP’s ‘register_globals’ enabled.
3. Detection and Assessment
Confirming vulnerability requires checking both the WordPress version and the PHP configuration. A quick check is to see if register_globals is enabled, followed by verifying the WordPress version.
- Quick checks: Use
php -i | grep "register_globals"on the server to determine if ‘register_globals’ is enabled. Check the WordPress admin interface for the installed version number. - Scanning: Nessus plugin ID 30497 may detect this vulnerability. This is an example only and should be verified.
- Logs and evidence: Examine web server access logs for requests containing suspicious characters or PHP code in cookie parameters. There are no specific event IDs associated with this vulnerability.
php -i | grep "register_globals"
4. Solution / Remediation Steps
The primary solution is to disable the ‘register_globals’ setting in PHP. This is a critical security measure that addresses multiple vulnerabilities, not just this one.
4.1 Preparation
- Ensure you have access to modify the PHP configuration file (php.ini). A roll back plan is to restore from backup or re-enable ‘register_globals’ in php.ini, although this is strongly discouraged.
- A change window may be required depending on your environment and approval processes.
4.2 Implementation
- Step 1: Edit the PHP configuration file (php.ini).
- Step 2: Locate the ‘register_globals’ setting.
- Step 3: Change the value of ‘register_globals’ to ‘Off’.
- Step 4: Save the php.ini file.
- Step 5: Restart the web server service for the changes to take effect.
4.3 Config or Code Example
Before
register_globals = On
After
register_globals = Off
4.4 Security Practices Relevant to This Vulnerability
Several security practices can help prevent this type of vulnerability. Input validation is key, as is using safe defaults and keeping software up-to-date.
- Practice 1: Least privilege – run web server processes with the minimum necessary permissions to reduce impact if exploited.
4.5 Automation (Optional)
Automation is not directly applicable for this specific fix, as it requires modifying the PHP configuration file which varies between systems. However, configuration management tools can be used to enforce the ‘register_globals = Off’ setting across multiple servers.
# Example Ansible task (requires appropriate permissions and php.ini path)
- name: Disable register_globals in php.ini
lineinfile:
path: /etc/php5/apache2/php.ini # Adjust path as needed
regexp: '^register_globals = On'
line: 'register_globals = Off'
notify: Restart Apache
5. Verification / Validation
Confirm the fix by verifying that ‘register_globals’ is disabled and re-testing for the vulnerability.
- Post-fix check: Run
php -i | grep "register_globals"again. The output should not contain “register_globals = On”. - Re-test: Attempt to inject PHP code into the ‘cache_lastpostdate’ cookie and verify that it is not executed.
- Smoke test: Ensure basic website functionality, such as viewing posts and pages, still works correctly.
- Monitoring: Monitor web server logs for any unexpected errors or suspicious activity related to PHP execution.
php -i | grep "register_globals" # Should return no output
6. Preventive Measures and Monitoring
Regular security baselines, automated scanning, and a robust patch process are essential for preventing this type of vulnerability.
- Baselines: Update your security baseline to include the requirement that ‘register_globals’ is disabled in PHP configurations.
- Asset and patch process: Implement a regular patch cycle for WordPress core, plugins, and themes.
7. Risks, Side Effects, and Roll Back
Disabling ‘register_globals’ should not cause any compatibility issues with modern WordPress installations. However, older or poorly written plugins may rely on this setting.
- Risk or side effect 2: No known service impacts with modern WordPress installations.
- Roll back: Restore the original php.ini file from backup and restart the web server service. This is strongly discouraged; investigate plugin compatibility issues instead.
8. References and Resources
- Vendor advisory or bulletin: https://seclists.org/fulldisclosure/2005/Aug/232
- NVD or CVE entry: CVE-2005-2612
- Product or platform documentation relevant to the fix: No specific WordPress documentation exists for this vulnerability, but general PHP configuration guides are available.