openssl on Windows built with openssldir set from the build machine (Uncontrolled Search Path Element)

### 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](https://www.zerodayinitiative.com/) 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.

CVSS 3.1

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Severity from

GitHub (reviewed advisory)

Weakness

CWE-427

• github.com/microsoft/vcpkg/security/advisories/GHSA-p322-v6vw-vrq9
• github.com/microsoft/vcpkg