Fix potential OS command injection in wdproxy.js

[SunLingrui]

Command Injection Reproduction Notes for wdproxy.js

Summary

Hello,
I am writing to report a potential OS Command Injection vulnerability in the following file:
f2etest-client/f2etest-webdriver/webdriver/wdproxy.js

The issue appears when user-controlled input is used to construct shell command strings that are later executed via child_process.execSync(...). Under certain conditions, specially crafted input values provided in the /wd/hub/session request body may allow unintended command execution on the host system. This could potentially lead to command injection risks, depending on how the input is validated and processed.

Root Cause

The issue is caused by unsafe shell command construction in the following function:

function setProxy(proxyHost){
    cp.execSync('reg add "'+proxyPath+'" /v "ProxyEnable" /t REG_DWORD /d "1" /f >nul');
    cp.execSync('reg add "'+proxyPath+'" /v "AutoConfigURL" /d "" /f >nul');
    cp.execSync('reg add "'+proxyPath+'" /v "ProxyServer" /d "'+proxyHost+'" /f >nul');
    console.log('System proxy inited:', proxyHost);
}

Reproduction Material

A minimal reproduction script is provided in: poc_wdproxy.js
poc_wdproxy.js

This Proof of Concept (PoC) is intended to demonstrate that external input can reach dangerous command execution logic through the vulnerable code path.

What the PoC Does

The PoC performs a minimal end-to-end trigger of the vulnerable code path:

1. It loads wdproxy.js.
2. It sends a crafted POST request to /wd/hub/session.
3. The request sets:
   • browserName to internet explorer
   • proxy.proxyType to manual
   • proxy.httpProxy to a malicious payload
4. This causes the application to invoke setProxy(httpProxy).
5. The supplied httpProxy value is concatenated into a shell command and passed to execSync(...).

In the provided example, the injected payload is crafted so that, on macOS, successful command execution opens the Calculator application. This serves as a visible indicator that external input can reach the OS command execution sink without proper sanitization.

Example Payload

The PoC uses the following payload for desiredCapabilities.proxy.httpProxy:

& open -a Calculator #

How to Run

Run from the project root:

node poc_wdproxy.js 127.0.0.1:9999 1 ie 60

Expected Output

When the PoC runs, you should see output similar to:

F2etest WebDriver proxy is ready: 4001
[POC] spawn would run:
 java [ ... ]

[POC] sending createSession to port 4001

In the vulnerable version, after the crafted request is processed, the local machine will launch the Calculator application as a benign demonstration effect.
This shows that the attacker-controlled desiredCapabilities.proxy.httpProxy value can influence command execution behavior through the vulnerable setProxy() path.

Patch Explanation

This branch also includes a patched version of wdproxy.js intended to mitigate the command injection risk described above.

What the patch changes

The patch adds strict validation before proxy-related values are used by the following functions:

• setProxy(proxyHost)
• setPac(pacUrl)

In the vulnerable version, user-controlled values such as:

• desiredCapabilities.proxy.httpProxy
• desiredCapabilities.proxy.proxyAutoconfigUrl

could reach child_process.execSync(...) through string concatenation without validation.

The patched version introduces input checks before these values are passed into command execution logic.

Validation introduced by the patch

For proxy host values, the patch only allows typical host / port style input such as:
127.0.0.1:8080
proxy.example.com:3128
Unexpected characters are rejected.
For PAC URL values, the patch checks that:
the value is a string
the value length is reasonable
the value matches an expected http:// or https:// URL format
If validation fails, the value is rejected instead of being passed into command execution.

[CLAassistant]

All committers have signed the CLA.