Windows agent with some locales cannot do proper security check

[savely-krasovsky]

We have faced with ovpnagent problem. In some cases Windows paths of client and server differ. It leads to server rejecting client connection via named pipe. I double checked source code and found nothing suspicious, but after adding additional logging we've found this:

Thu Feb 22 16:13:38 2024 C:\Program Files\OpenVPN\bin\service.exe not recognized as a valid client
Thu Feb 22 16:13:38 2024 exception in handle_accept: http_server_exception: client socket rejected
Thu Feb 22 16:13:41 2024 connection from C:\Program Files\OpenVPN\bin\service.exe
Thu Feb 22 16:13:41 2024 normalized client exe path: c:\Program Files\OpenVPN\bin
Thu Feb 22 16:13:41 2024 normalized server exe path: c:\program files\openvpn\bin

As you can imagine check compares paths and fails.

We have found that it was users who have English localization instead of Russian (as many others in our case). Probably it's easy to fix but converting both paths to lower case, but I am not it's good from security point.

[savely-krasovsky]

@schwabe I am not sure what cause problem and how it could be fixed properly. I double checked:

1. GetModuleFileNameW really returns lower case path.
2. QueryFullProcessImageNameW returns proper path.
3. Service is registered with proper path (ImagePath = C:\Program Files\OpenVPN...).
4. I think Windows for some reason attaches module (agent in our case) with wrong, lowered case path.

Man here has the same problem:
https://stackoverflow.com/questions/31239726/getmodulefilename-always-return-lowercase-in-service

[savely-krasovsky]

From what I found, Windows doesn't allow to set entire drive as case-sensitive. So administator can set C:\Program Files as case-sensitive, but user still won't be able to create (to exploit possible vulnerability) C:\program files as C:\ still case-insensitive, because directory will already exist from NTFS perspective.

I tried fsutil.exe file setCaseSensitiveInfo C:\ enable but it responded "not supported".

[savely-krasovsky]

Any comments in the new context?

[lstipakov]

I am not able to reproduce this. I used ovpnagent and ovpncliagent for testing, registered the service with ovpnagent install and checked that the server exe path is a case-sensitive.

We could use QueryFullProcessImageNameW to get the path - we already have all the code in place. Could you apply following patch and see if that works for you?

diff --git a/openvpn/win/modname.hpp b/openvpn/win/modname.hpp
index 00142dd1..d3cafb45 100644
--- a/openvpn/win/modname.hpp
+++ b/openvpn/win/modname.hpp
@@ -32,20 +32,15 @@
 #include <openvpn/common/wstring.hpp>
 #include <openvpn/win/winerr.hpp>
 #include <openvpn/win/reg.hpp>
+#include <openvpn/win/npinfo.hpp>
 
 namespace openvpn {
 namespace Win {
 
 inline std::wstring module_name()
 {
-    // get path to our binary
-    wchar_t path[MAX_PATH];
-    if (!::GetModuleFileNameW(NULL, path, MAX_PATH))
-    {
-        const Win::LastError err;
-        OPENVPN_THROW_EXCEPTION("GetModuleFileNameW failed: " << err.message());
-    }
-    return std::wstring(path);
+    auto current_process_handle = NamedPipePeerInfo::get_process(GetCurrentProcessId(), true);
+    return NamedPipePeerInfo::get_exe_path(current_process_handle());
 }
 
 inline std::string module_name_utf8()