summaryrefslogtreecommitdiffhomepage
path: root/windows/nsis-plugins/src/string/string.cpp
diff options
context:
space:
mode:
authorLinus Färnstrand <linus@mullvad.net>2020-01-08 16:32:42 +0100
committerLinus Färnstrand <linus@mullvad.net>2020-01-09 15:49:42 +0100
commit882c4bcaa4163e91ed7a97ba86f30f1fdf1dc420 (patch)
tree572c8273c5f925e2deb4f534570c6a43e92c0d02 /windows/nsis-plugins/src/string/string.cpp
parent96f6003a3d514b51ed257e9b0fb9e6d448e14888 (diff)
downloadmullvadvpn-882c4bcaa4163e91ed7a97ba86f30f1fdf1dc420.tar.xz
mullvadvpn-882c4bcaa4163e91ed7a97ba86f30f1fdf1dc420.zip
Bump binaries submodule
A user reported the following: I noticed that when Mullvad for Windows starts OpenVPN, an attempt is made to read the file C:\etc\ssl\openssl.cnf. On most systems this file isn't present. By default Windows allows any authenticated users to create new files in the system roots, meaning that a user can created a directory structure C:\etc\ssl\ containing a file openssl.cnf. When present the file will be read and processed by the OpenSSL library (OpenVPN). A local attacker can abuse this situation by creating a configuration file containing a malicious engine entry pointing to an attacker-controlled DLL. When the configuration is processed, an attempt is made to load this DLL by the OpenVPN binary. Since OpenVPN is running as LocalSystem, it is possible for any authenticated user to run arbitrary code as LocalSystem. Adding the no-autoload-config to the OpenSSL build options disable loading this file on initialization. So I added this and re-built OpenVPN on all platforms.
Diffstat (limited to 'windows/nsis-plugins/src/string/string.cpp')
0 files changed, 0 insertions, 0 deletions