openssl config is loaded from the build location by default
|Reported by:||Owned by:|
|uname -a:||Windows 10|
Description (last modified by )
I have noticed that the official Windows builds of nginx contain a vulnerability that can potentially be exploited to escalate privileges, by injecting an arbitrary OpenSSL engine library.
http://nginx.org/download/nginx-1.22.1.zip (Stable version; SHA1: 15f51260a00624fd83aa33e544448a52e4fe9029)
http://nginx.org/download/nginx-1.23.2.zip (Mainline version; SHA1: 1e00daa40d61bc22884d82c2e9b9e3477ba4528a)
Windows 10, x64, 21H2
When nginx is launched, it tries to load the OpenSSL configuration file from
A low-privileged user can create the expected path (creating folders from C:\ can be done by regular users), including a malicious OpenSSL configuration file, to load an arbitrary OpenSSL Engine library. In many instances nginx will be executed either from an administrator or in the context of NT AUTHORITY\SYSTEM, leading to privilege escalation.
1) As a non-administrator user, create the following folder structure:
2) Create the following openssl.cnf and place it in the above path (again as a non-administrator user):
# openssl.cnf openssl_conf = openssl_init [openssl_init] engines = engine_section [engine_section] woot = woot_section [woot_section] engine_id = poc dynamic_path = C:\\MinGW\\msys\\1.0\\home\\Administrator\\nginx\\objs.msvc8\\lib\\openssl-1.1.1q\\openssl\\ssl\\poc.dll init = 0
3) To create a simple DLL, msfvenom can be used:
msfvenom -p windows/exec -a x86 cmd='notepad.exe' Exitfunc=thread -f dll -o poc.dll
As a non-administrator, copy the poc.dll to
4) Execute nginx as a different user (e.g., administrator or through a service account)
The result is that the arbitrary DLL will get loaded and executed by nginx, in the context of the user who executed nginx, leading to privilege escalation.
The issue might have been introduced with the latest legacy build, nginx-1.20.2.zip (SHA1: 3670568e32b40fb9cd0166879f3f35b8df6b8522), which suffers from the same issue, although the path is slightly different (C:\nginx\nginx-stable\objs.msvc8\lib\openssl-1.1.1l\openssl\ssl\openssl.cnf).
In this case, the official prebuilt Windows binaries are available through an archive, not through an installer or similar, so the risk is likely reduced, as the execution context will be as whoever executed the binary. However, since this behaviour is not documented anywhere on the official website, and products might rely on the official Windows nginx builds, it is probably worthwhile to get fixed.
For reference, here are some examples of other software that suffered from the same kind of security issue in the past:
McAfee Agent: CVE-2022-0166 (https://www.kb.cert.org/vuls/id/287178)
Tychon: CVE-2022-26872 (https://kb.cert.org/vuls/id/730007)
VMware Workstation: CVE-2021-21999
Change History (4)
comment:2 by , 11 months ago
|Status:||new → accepted|
|Summary:||nginx Windows Builds Privilege Escalation Vulnerability → openssl config is loaded from the build location by default|