On Tue, Aug 13, 2024 at 7:02 PM David W Graham <da...@plasmatronics.com.au> wrote:
> CryptProtectMemory function (dpapi.h) > > "The CryptProtectMemory function encrypts > <https://learn.microsoft.com/en-us/windows/desktop/SecGloss/e-gly> memory > to prevent others from viewing sensitive information in your process. For > example, use the CryptProtectMemory function to encrypt memory that > contains a password. Encrypting the password prevents others from viewing > it when the process is paged out to the swap file. > > "Encrypt and decrypt memory in the same process. An application running > in a different process will not be able to decrypt the data." > > This is not a generic c library function, which makes cross-platform code > more complex, but that's no excuse. Simple memory-recovery exploits have > been demonstrated so often in the last 40 years that there is pretty much > no excuse for not using CryptProtectMemory or RtlEncryptMemory for memory > storage of passwords on Windows.ty > The CWE report is about *OpenVPN 3.4.3* --- no idea what version is that. If you are using the "OpenVPN 2.x community version" on Windows with the Windows-GUI, you can use "--auth-nocache" and choose to save passwords in the GUI instead. Then passwords are in memory only during the authentication cycle. Instead, a blob encrypted using DPAPI is persisted. 2FA code is not saved anywhere. During renegotiations, the GUI fetches the saved password, decrypts and submits it, and promptly scrubs the memory. On other platforms, "--mlock" will provide some protection by disabling swapping to disk. If not using the GUI (e.g., started at boot by a service), any required password is usually supplied in clear text from a file or inlined in the config. If so, it would be easier to steal it from there instead of scavenging the process memory. Nonetheless, on Windows, we could easily add CryptProtectMemory() with SAME_PROCESS access for good measure, especially for those who cannot use "--auth-nocache". That will also add some protection to proxy passwords which are always cached for some reason. As for username, we have not been careful about encrypting it in the GUI though we had plans to do it. Selva
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
