How to remediate – Moodle ‘filter/tex/texed.php’ ‘pathname’ Parameter Remote Comm…

1. Introduction

2. Technical Explanation

• Exploit mechanism: An attacker crafts a malicious request containing commands in the ‘pathname’ parameter, which are then executed by the server when processing the TeX filter. For example, an attacker could send a request like http://example.com/filter/tex/texed.php?pathname=; whoami to execute the ‘whoami’ command.
• Scope: Moodle installations with PHP’s ‘register_globals’ enabled and TeX Notation filter active, where PHP’s ‘magic_quotes_gpc’ is disabled.

3. Detection and Assessment

You can check if your system is vulnerable by verifying the PHP configuration settings and Moodle’s filter status. A thorough assessment involves reviewing the code for unsanitised input.

• Quick checks: Check PHP’s ‘register_globals’ setting using php -i | grep register_globals. If it returns ‘Register Globals: On’, your system is potentially vulnerable.
• Scanning: Nessus plugin ID 32801 can identify this vulnerability, but results should be verified manually.
• Logs and evidence: Look for unusual commands being executed by the web server user in system logs (e.g., /var/log/auth.log or similar).

php -i | grep register_globals

4. Solution / Remediation Steps

The primary solution is to disable PHP’s ‘register_globals’. This prevents the vulnerability from being exploited.

4.1 Preparation

• No services need to be stopped, but schedule this during off-peak hours as it may cause temporary disruption.

4.2 Implementation

1. Step 1: Edit your PHP configuration file (php.ini) and set ‘register_globals’ to Off.
2. Step 2: Restart your web server (e.g., Apache or Nginx) 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

Practices like input validation and least privilege are important for preventing this type of vulnerability.

• Practice 1: Input validation prevents malicious data from being processed, reducing the risk of command injection.
• Practice 2: Least privilege limits the impact if an attacker successfully executes commands on the server.

4.5 Automation (Optional)

No automation is provided as direct configuration changes are required and should be verified manually.

5. Verification / Validation

• Post-fix check: Run php -i | grep register_globals. The output should show ‘Register Globals: Off’.
• Re-test: Attempt to exploit the vulnerability using a test payload (e.g., http://example.com/filter/tex/texed.php?pathname=; whoami). It should no longer execute commands.
• Monitoring: Monitor system logs for any unexpected command executions by the web server user.

php -i | grep register_globals

6. Preventive Measures and Monitoring

Update your security baselines to include disabling ‘register_globals’ as a standard practice. Implement regular vulnerability scanning in CI/CD pipelines.

• Baselines: Update your PHP configuration baseline or policy to enforce ‘register_globals = Off’.
• Pipelines: Add checks in your CI/CD pipeline to scan for insecure PHP configurations, including enabled ‘register_globals’.
• Asset and patch process: Review PHP configurations regularly as part of a standard asset management process.

7. Risks, Side Effects, and Roll Back

Disabling ‘register_globals’ may cause compatibility issues with older applications that rely on it. If this happens, you will need to update those applications or restore from backup.

• Roll back: Restore your PHP configuration file (php.ini) from backup and restart your web server.

8. References and Resources

• Vendor advisory or bulletin: https://www.securityfocus.com/archive/1/499172/30/0/threaded
• NVD or CVE entry: Not applicable (no specific CVE assigned).
• Product or platform documentation relevant to the fix: https://docs.moodle.org/