How to remediate – PHP Error Log Format String Command Injection

1. Introduction

The PHP Error Log Format String Command Injection vulnerability allows an attacker to potentially run arbitrary code on a remote host running vulnerable versions of PHP. This is possible when ‘log_errors’ is enabled in the php.ini configuration file. Successful exploitation could lead to complete system compromise, impacting confidentiality, integrity and availability. Systems commonly affected are web servers running PHP 3.0.x or 4.0.x.

2. Technical Explanation

This vulnerability occurs because older versions of PHP do not properly sanitise input when writing to error logs if ‘log_errors’ is enabled. An attacker can inject format string specifiers into data logged by the application, which are then interpreted as commands by the operating system. The precondition for exploitation is that the vulnerable PHP version is running with ‘log_errors’ set to ‘On’. CVE-2000-0967 describes this issue.

• Root cause: Insufficient input validation when writing error log messages.
• Exploit mechanism: An attacker sends a crafted request containing format string specifiers that are written to the PHP error log, leading to arbitrary command execution. For example, sending a request with “%s%s%s…” in a logged variable could trigger shell commands.
• Scope: Affected platforms include servers running PHP versions older than 3.0.17 and 4.0.3.

3. Detection and Assessment

You can confirm if a system is vulnerable by checking the PHP version and configuration. A quick check involves examining the php.ini file for the ‘log_errors’ setting, and verifying the PHP version.

• Quick checks: Use the command php -v to display the PHP version. Check the php.ini file (location varies by system) for the line ‘log_errors = On’.
• Scanning: Nessus plugin ID 21834 may detect this vulnerability, but results should be manually verified.
• Logs and evidence: Examine PHP error logs for unusual patterns or unexpected characters that could indicate exploitation attempts. Log file locations vary by system configuration; common paths include /var/log/php_errors.log or within the web server’s log directory.

php -v

4. Solution / Remediation Steps

To fix this issue, either disable error logging or upgrade to a supported PHP version.

4.1 Preparation

• Ensure you have access to modify the php.ini configuration file and restart the web server. A roll back plan involves restoring the original php.ini file if issues occur.
• A change window may be needed depending on your organisation’s policies; approval from a system owner might be required.

4.2 Implementation

1. Step 1: Open the php.ini configuration file in a text editor.
2. Step 2: Locate the line ‘log_errors = On’.
3. Step 3: Change this line to ‘log_errors = Off’.
4. Step 4: Save the changes to the php.ini file.
5. Step 5: Restart your web server for the changes to take effect.

4.3 Config or Code Example

Before

log_errors = On

After

log_errors = Off

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this type of issue. Least privilege reduces the impact if exploited, and input validation blocks unsafe data from being logged.

• Practice 1: Implement least privilege principles for the web server user account.

4.5 Automation (Optional)

# Example Bash script to disable error logging in php.ini
# Replace /path/to/php.ini with the actual path
sed -i 's/^log_errors = On$/log_errors = Off/' /path/to/php.ini
systemctl restart apache2 # Or nginx, depending on your web server

5. Verification / Validation

Confirm that the fix worked by checking the PHP configuration again and attempting to trigger the vulnerability.

• Post-fix check: Run php -v to confirm the version is updated, then examine php.ini for ‘log_errors = Off’.
• Re-test: Re-run the command from section 3 to verify that ‘log_errors’ is now set to ‘Off’.
• Monitoring: Monitor PHP error logs for any unexpected activity or errors, as a regression could indicate an issue with the fix.

php -v

6. Preventive Measures and Monitoring

Update security baselines to include this setting, and add checks in your deployment pipeline to prevent similar issues.

• Baselines: Update your PHP configuration baseline or policy to enforce ‘log_errors = Off’ by default.
• Pipelines: Include static analysis (SAST) tools in your CI/CD pipeline to identify insecure configurations like enabled error logging.
• Asset and patch process: Implement a regular patch review cycle for all PHP installations, ensuring timely updates to address known vulnerabilities.

7. Risks, Side Effects, and Roll Back

Disabling error logging may make debugging more difficult. If issues occur, restore the original php.ini file.

• Risk or side effect 1: Disabling error logging can hinder troubleshooting efforts. Ensure adequate alternative logging mechanisms are in place.
• Risk or side effect 2: Restarting the web server may cause brief service interruption.
• Roll back: Restore the original php.ini file and restart the web server.

8. References and Resources

• Vendor advisory or bulletin: PHP Security Advisories
• NVD or CVE entry: CVE-2000-0967
• Product or platform documentation relevant to the fix: PHP Configuration Options – log_errors