Debian Patches

Status for openvpn/2.5.1-3

Patch Description Author Forwarded Bugs Origin Last update
move_log_dir.patch Set default logdir to /var/log/openvpn https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=553303 Jörg Frings-Fürst <debian@jff-webhosting.net> not-needed debian 2017-10-03
auth-pam_libpam_so_filename.patch Fix libpam.so filename to /lib/libpam.so.0 in pam plugin=================================================================== Alberto Gonzalez Iniesta <agi@inittab.org> no debian
debian_nogroup_for_sample_files.patch Unpriviledged group in Debian is called nogroup instead of nobody=================================================================== Alberto Gonzalez Iniesta <agi@inittab.org> no debian
openvpn-pkcs11warn.patch Warn users about deprecated pkcs11 options=================================================================== Florian Kulzer <florian.kulzer+debian@icfo.es> no debian
match-manpage-and-command-help.patch [PATCH] Change command help to match man page and implementation Arne Schwabe <arne@rfc2549.org> no 2017-01-04
systemd.patch remove syslog.target Jörg Frings-Fürst <debian@jff.email> no 2018-07-29
CVE-2020-15078-0.patch [PATCH] Move context_auth from context_2 to tls_multi and name it multi_state

context_2 and tls_multi have the same life cycle for TLS connections
but so this move does not affect behaviour of the variable.

OpenVPN TLS multi code has a grown a lot more complex and code that
handles multi objects needs to know the state that the object is in.
Since not all code has access to the context_2 struct, the code that
does not have access is often not checking the state directly but
checks other parts of multi that have been affected from a state
change.

This patch also renames it to multi_state as this variable represents
the multi state machine status rather than just the state of the connect
authentication (more upcoming patches will move other states
into this variable).

Patch V2: also rename context_auth to multi_state, explain a bit why this
change is done.
Patch V3: Add comments for c2->multi NULL check forwarding. Fix compile
with ENABLE_ASYNC_PUSH.

(backported from commit 0767d5b447044e4cdcfd198058aef1f85f63bbe6)
Arne Schwabe <arne@rfc2549.org> no 2021-03-28
CVE-2020-15078-1.patch [PATCH] Move auth_token_state from multi to key_state
The auth-token check is tied to the username/password that is coming
via a specific SSL session, so keep the state also in the key_state
structure.

This also ensures the auth_token_state is always set to 0 on a new
session since we clear the key_state object at the start of a new
SSL session.

This is a prerequisite patch to fix 2020-15078 in the following two
commits.

2nd patch, squashed into the first one:

This also applies the changes to the auth_token_test.c. The change of
tls_session to a pointer is necessary since before that we had tls_session
not tied to the multi and had two tls_session used in the test. One
implicitly in tls_multi and one explicit one. Merge these to one.
Arne Schwabe <arne@rfc2549.org> no 2021-03-27
CVE-2020-15078-2.patch [PATCH] Ensure auth-token is only sent on a fully authenticated session

This fixes the problem that if client authentication is deferred, we
send an updated token before the authentication fully finished.

Calling the new ssl_session_fully_authenticated from the two places
that do the state transition to KS_AUTH_TRUE is a bit suboptimal but
a cleaner solution requires more refactoring of the involved methods
and state machines.

This bug allows - under very specific circumstances - to trick a
server using delayed authentication (plugin or management) *and*
"--auth-gen-token" into returning a PUSH_REPLY before the AUTH_FAILED
message, which can possibly be used to gather information about a
VPN setup or even get access to a VPN with an otherwise-invalid account.

CVE-2020-15078 has been assigned to acknowledge this risk.
Arne Schwabe <arne@rfc2549.org> no 2021-03-27
CVE-2020-15078-3.patch [PATCH] Ensure key state is authenticated before sending push reply
This ensures that the key state is authenticated when sending
a push reply.

This bug allows - under very specific circumstances - to trick a
server using delayed authentication (plugin or management) into
returning a PUSH_REPLY before the AUTH_FAILED message, which can
possibly be used to gather information about a VPN setup.

In combination with "--auth-gen-token" or user-specific token auth
solutions it can be possible to get access to a VPN with an
otherwise-invalid account.

CVE-2020-15078 has been assigned to acknowledge this risk.
Arne Schwabe <arne@rfc2549.org> no 2021-04-06
Fix-condition-to-generate-session-keys.patch [PATCH] Fix condition to generate session keys
When OpenVPN sees a new (SSL) connection via HARD_RESET or SOFT_RESET with
the same port/ip as an existing session, it will give it the slot of the
renegotiation session (TM_UNTRUSTED). And when the authentication
succeeds it will replace the current session. In the case of a SOFT_RESET
this a renegotiation and we will generated data channel keys at the of
key_method_2_write function as key-id > 0.

For a HARD RESET the key-id is 0. Since we already have gone through
connect stages and set context_auth to CAS_SUCCEEDED, we don't
call all the connect stages again, and therefore also never call
multi_client_generate_tls_keys for this session.

This commit changes postponing the key generation to be done only if
the multi_connect has not yet been finished.

Patch V2: Explain better in the commit message why this change is done.

This is "sort of" a backport of commit a005044be9ca, except that the
master commit only got 1 of 3 hunks from the mailing list patch merged
while release/2.5 needs all 3. So this is exactly the patch as it was
sent to the list, URL below.
Arne Schwabe <arne@rfc2549.org> no 2021-03-28

All known versions for source package 'openvpn'

Links