Summary
vcpkg's Windows builds of OpenSSL set openssldir to a path on the build machine, making that path be attackable later on customer machines.
Details
This was initially reported by Xavier DANEST working with TrendAI Zero Day Initiative and assigned ZDI-CAN-29616 (visible on https://www.zerodayinitiative.com/advisories/upcoming/ ). There is a 'file lay in wait' class of elevation of privilege vulnerabilities arising from OpenSSL hard coding search paths for DLLs. vcpkg's OpenSSL port sets openssldir to a path from the build machine in order to get built results to be placed correctly, but this means OpenSSL will search that path for engines to load in the future.
A low privilege user on a different machine can create the same path, which would hijack a later high privilege user deploying an OpenSSL vcpkg happened to build at that location.
The OpenSSL documentation explicitly notes this problem and says that redirecting built results needs to be done with DESTDIR, not by changing openssldir: https://github.com/openssl/openssl/blob/master/INSTALL.md#directories + https://github.com/openssl/openssl/blob/master/INSTALL.md#additional-directories
vcpkg port 3.6.1#3 for OpenSSL changes vcpkg's build for Windows to not set openssldir at all, leaving OpenSSL's default path under Program Files. Program Files is assumed to be acceptable because writing there generally requires administrative permissions. In an ideal universe we would configure OpenSSL to not search this at all, but they don't appear to offer such a setting.
Summary
vcpkg's Windows builds of OpenSSL set
openssldirto a path on the build machine, making that path be attackable later on customer machines.Details
This was initially reported by Xavier DANEST working with TrendAI Zero Day Initiative and assigned ZDI-CAN-29616 (visible on https://www.zerodayinitiative.com/advisories/upcoming/ ). There is a 'file lay in wait' class of elevation of privilege vulnerabilities arising from OpenSSL hard coding search paths for DLLs. vcpkg's OpenSSL port sets
openssldirto a path from the build machine in order to get built results to be placed correctly, but this means OpenSSL will search that path for engines to load in the future.A low privilege user on a different machine can create the same path, which would hijack a later high privilege user deploying an OpenSSL vcpkg happened to build at that location.
The OpenSSL documentation explicitly notes this problem and says that redirecting built results needs to be done with
DESTDIR, not by changingopenssldir: https://github.com/openssl/openssl/blob/master/INSTALL.md#directories + https://github.com/openssl/openssl/blob/master/INSTALL.md#additional-directoriesvcpkg port
3.6.1#3for OpenSSL changes vcpkg's build for Windows to not setopenssldirat all, leaving OpenSSL's default path under Program Files. Program Files is assumed to be acceptable because writing there generally requires administrative permissions. In an ideal universe we would configure OpenSSL to not search this at all, but they don't appear to offer such a setting.