GHSA-246w-jgmq-88fg

Описание

Summary

When openvpn-auth-oauth2 is deployed in the experimental plugin mode (shared library loaded by OpenVPN via the plugin directive), clients that do not support WebAuth/SSO (e.g., the openvpn CLI on Linux) are incorrectly admitted to the VPN despite being denied by the authentication logic. The default management-interface mode is not affected because it does not use the OpenVPN plugin return-code mechanism.

Impact

Authentication bypass — any VPN client that does not advertise WebAuth/SSO support (IV_SSO=webauth) is granted full network access without completing OIDC authentication.

This affects only deployments running the experimental plugin mode in versions 1.26.3 through 1.27.2. The default and recommended deployment via the management interface is not affected.

An unauthenticated attacker can connect to the OpenVPN server using any standard OpenVPN client that does not support webauth (e.g., the Linux openvpn CLI). The plugin correctly issues a client-deny command via the management interface, but returns OPENVPN_PLUGIN_FUNC_SUCCESS (status=0) to OpenVPN. Because the auth_control_file content is only consulted when the plugin returns FUNC_DEFERRED, OpenVPN interprets status=0 as "authentication passed" and admits the client — granting full access to the internal network behind the VPN.

Root Cause

In lib/openvpn-auth-oauth2/openvpn/handle.go, the ClientAuthDeny branch of handleAuthUserPassVerify wrote "0" (deny) to the auth_control_file but returned OPENVPN_PLUGIN_FUNC_SUCCESS. OpenVPN only reads the auth_control_file when the plugin returns FUNC_DEFERRED; a synchronous FUNC_SUCCESS return is treated as immediate approval regardless of file contents.

Before fix:

After fix (commit 36f69a6):

Patches

This vulnerability is fixed in v1.27.3. Users of the experimental plugin mode should upgrade immediately.

• Fix commit: 36f69a6
• Fix PR: #829

Workarounds

• Switch to standalone management client mode (the default, non-plugin deployment). This mode is not affected by the vulnerability because authentication decisions are communicated entirely through the management interface protocol, not through the plugin return code.
• Restrict VPN access at the network level to only clients known to support WebAuth/SSO (e.g., OpenVPN Connect 3+), although this is difficult to enforce reliably and is not recommended as a sole mitigation.