]> git.ipfire.org Git - thirdparty/openvpn.git/commit
Refuse clients if username or password is longer than USER_PASS_LEN
authorArne Schwabe <arne@rfc2549.org>
Mon, 28 Oct 2024 13:55:04 +0000 (14:55 +0100)
committerGert Doering <gert@greenie.muc.de>
Mon, 28 Oct 2024 14:24:20 +0000 (15:24 +0100)
commita7f80d402fb95df3c58a8fc5d12cdb8f39c37d3e
tree60be405972b62f103743175a555afb03439b25ef
parent5dd1b8b06335831206077a1eb4aa81c3ceb3f3ee
Refuse clients if username or password is longer than USER_PASS_LEN

When OpenVPN is compiled without PKCS11 support USER_PASS_LEN is 128
bytes. If we encounter a username larger than this length, we would
only read the 2 bytes length header of the username/password.  We did
then also NOT skip the username or password field meaning that we would
continue reading the rest of the packet at the wrong offset and get
garbage results like not having peerinfo and then rejecting a client
because of no common cipher or missing data v2 support.

This will tell the client that username/password is too regardless
of whether password/username authentication is used.  This way we
do not leak if username/password authentication is active.

To reproduce this issue have the server compiled with a USER_PASS_LEN
set to 128 (e.g. without pkcs11 or manually adjusting the define) and
have the client with a larger USER_PASS_LEN to actually be able to
send the larger password. The server must also be set to use only
certificate authentication while the client must use certificates
and auth-user-pass because otherwise the user/pass verification will
reject the empty credentials.

Using the openvpn3 test client with overlong username/password also
works.

Change-Id: I60f02c919767eb8f1b95253689a8233f5f68621d
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20241028135505.28651-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg29675.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
src/openvpn/ssl.c