Debian Patches
Status for openvpn/2.5.1-3+deb11u1
| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| 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 | ||
| 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 | ||
| CVE-2022-0547.patch | [PATCH] plug-ins: Disallow multiple deferred authentication plug-ins The plug-in API in OpenVPN 2.x is not designed for running multiple deferred authentication processes in parallel. The authentication results of such configurations are not to be trusted. For now we bail out when this discovered with an error in the log. This is a backport of commit 282ddbac54f8d4923844f699 (master), taking the different man-page format into account. The code change is the same. Backported to Debian by Aquila Macedo Costa <aquilamacedo@riseup.net> Choose https://github.com/OpenVPN/openvpn/commit/58ec3bb4aac77131118dbbc39a65181e7847adee (v2.4.12) instead of https://github.com/OpenVPN/openvpn/commit/af3e382649d96ae77cc5e42be8270f355e5cfec5 (v2.5.6) because it properly handles the installation of the `openvpn.8` man page, ensuring it is recognized by the system. The v2.5.6 commit lacks necessary handling in the `debian/` directory, which would require additional manual adjustments. Changes: - Refresh patch context. |
David Sommerseth <davids@openvpn.net> | no | 2022-03-15 | ||
| CVE-2024-5594.patch | [PATCH] Properly handle null bytes and invalid characters in control messages This makes OpenVPN more picky in accepting control message in two aspects: - Characters are checked in the whole buffer and not until the first NUL byte - if the message contains invalid characters, we no longer continue evaluating a fixed up version of the message but rather stop processing it completely. Previously it was possible to get invalid characters to end up in log files or on a terminal. This also prepares the logic a bit in the direction of having a proper framing of control messages separated by null bytes instead of relying on the TLS framing for that. All OpenVPN implementations write the 0 bytes between control commands. This patch also include several improvement suggestion from Reynir (thanks!). (cherry picked from commit 414f428fa29694090ec4c46b10a8aba419c85659) Backported to Debian by Aquila Macedo Costa <aquilamacedo@riseup.net> Changes: - Refresh patch context. - Removed handling of "AUTH_PENDING" and "EXIT" messages from the `parse_incoming_control_channel_command` function in `src/openvpn/forward.c`. These features were not present in the openvpn version in debian bullseye, so their handling has been excluded to maintain consistency and prevent unintended behavior. - "AUTH_PENDING" handling relies on `receive_auth_pending(c, buf)`, which was introduced in commit https://github.com/OpenVPN/openvpn/commit/3f8fb2b2c1d664f421d36181846da89c4330c6cc (part of OpenVPN 2.6-beta1). Since this function is not present in the openvpn version in bullseye, its handling has been removed. - "EXIT" was introduced in commit https://github.com/OpenVPN/openvpn/commit/179b3728b71013413885e453e477997f5a396f78 (part of OpenVPN 2.6-beta1). |
Arne Schwabe <arne@rfc2549.org> | no | 2024-05-27 | ||
| debian_nogroup_for_sample_files.patch | Unpriviledged group in Debian is called nogroup instead of nobody=================================================================== | Alberto Gonzalez Iniesta <agi@inittab.org> | no | debian | ||
| 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 | ||
| 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 | ||
| 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 | |
| openvpn-pkcs11warn.patch | Warn users about deprecated pkcs11 options=================================================================== | Florian Kulzer <florian.kulzer+debian@icfo.es> | no | debian | ||
| sample-keys-renew-10-years.patch | [PATCH] sample-keys: renew for the next 10 years Old expiration was October 2024, less than a year away. Give everyone the chance to get the new keys before tests start failing. |
Frank Lichtenheld <frank@lichtenheld.com> | no | https://github.com/OpenVPN/openvpn/commit/78e0c5f2f57a18e8ea60951696a458a4b3ff3621 | 2023-11-21 | |
| systemd.patch | remove syslog.target | Jörg Frings-Fürst <debian@jff.email> | no | 2018-07-29 |
Showing 1 to 14 of 14 entries
All known versions for source package 'openvpn'
- 2.6.14-1 (trixie, sid)
- 2.6.3-1+deb12u2 (bookworm, bookworm-security)
- 2.6.3-1+deb12u2~bpo11+1 (bullseye-backports)
- 2.5.1-3+deb11u1 (bullseye-security)
- 2.5.1-3 (bullseye)