Package: libreswan / 3.27-6+deb10u1
Metadata
Package | Version | Patches format |
---|---|---|
libreswan | 3.27-6+deb10u1 | 3.0 (quilt) |
Patch series
view the series filePatch | File delta | Description |
---|---|---|
0001 do not use git version.patch | (download) |
packaging/utils/setlibreswanversion |
2 1 + 1 - 0 ! |
do not use git version avoid using git version when building debian package |
0002 debian pam.d pluto.patch | (download) |
pam.d/pluto |
27 11 + 16 - 0 ! |
debian-pam.d-pluto debian: fix /etc/pam.d/pluto to work with debian Signed-off-by: Tuomo Soini <tis@foobar.fi> |
0003 update README.nss to match debian defaults for IPSEC.patch | (download) |
README.nss |
14 7 + 7 - 0 ! |
update readme.nss to match debian defaults for ipsec_nssdir |
0004 move to python3 scripts are compatible.patch | (download) |
programs/show/show.in |
2 1 + 1 - 0 ! |
move to python3 (scripts are compatible) |
0005 pluto set hdr.isa_length to 0 in informational.patch | (download) |
programs/pluto/ikev2_parent.c |
1 1 + 0 - 0 ! |
pluto: set hdr.isa_length to 0 in informational() (cherry picked from commit 16859c49e67903a913e38f6410718f6b42647a89) |
0006 sort all wildcarded object files for reproducibility.patch | (download) |
programs/algparse/Makefile |
2 1 + 1 - 0 ! |
sort all wildcarded object files for reproducibility Without this sort, the linker may assemble the final object files in the order in which their source files are found in the filesystem (or however make chooses to interpret the $(wildcard ...) function). By sorting the results lexicographically, we aim to assemble byte-identical output files, regardless of the filesystem order or other possible non-determinism introduced by make. |
0007 libreswan 3.27 CVE 2019 12312.patch | (download) |
programs/pluto/ikev2_send.c |
11 11 + 0 - 0 ! |
libreswan 3.27 cve-2019-12312 This is a cleaned up patch for https://github.com/libreswan/libreswan/issues/246 as applied directly against 3.27. -- |
0008 Resolve CVE 2019 10155 IKEv1 Informational exchange .patch | (download) |
programs/pluto/ikev1.c |
26 26 + 0 - 0 ! |
resolve cve-2019-10155: ikev1 informational exchange integrity check failure This alert (and any possible updates) is available at the following URLs: https://libreswan.org/security/CVE-2019-10155/ The Libreswan Project has found a vulnerability in its processing IKEv1 informational exchange packets. These packets are encrypted and integrity protected using the established IKE SA encryption and integrity keys, but as a receiver, the integrity check value (ICV) was not verified for IKEv1 Informational Exchange packets. The code containing the vulnerability is also present in openswan and older strongswan releases. The impact of this vulnerability is low, as it cannot be exploited. (for libreswan; for strongswan and openswan see below) Vulnerable versions: libreswan < 3.29 strongswan < 5.0 openswan - all versions (as of writing: 2.6.51.3) Not vulnerable: libreswan 3.29 and later, strongswan 5.0 and later, freeswan Vulnerability information ========================= IKEv1 informational packets are not integrity checked. As these packets are encrypted under the negotiated IKE SA's encryption key, the impact of this is very limited. An attacker would have no access to the encryption key, meaning an on-path attacker can at best send mangled messages that would be processed for decryption, but these messages once decrypted would result in nonsense data that would be rejected as an invalid IKE packet. Even if the attacker somehow managed to accidentally forge an encrypted message that would decrypt in a valid IKE packet (or if it would otherwise obtain the encryption key of the IKE session), the damage it can do is limited, as the IKEv1 informational exchange is only used for two type of messages: Dead Peer Detection (DPD) messages and Delete/Notify messages terminating IPsec and IKE SA's. Since the attacker needs to be on-path for this attack, it is much easier for the attacker to filter the packets to accomplish the same thing. An IKE point that required a connection to be established, would also re-establish a connection that is brought down by a Notify/Delete message. As such, the impact is deemed low. Exploitation ============ There is no known method for exploiting this vulnerability for libreswan. Due to the missing the integrity check, a concern was investigated to see if the vulnerability could be used as an oracle to attack the IKE SA encryption key. Due to the way libreswan has implemented encryption, using the NSS crypto library, no RSA padding attacks are possible. While it would be possible to determine the unencrypted message length, this information yields no useful information to an attacker. For strongswan, no versions have been vulnerable since 2012, when the shared vulnerable code was replaced by a new IKEv1 implementation that is not vulnerable. Those old versions would be vulnerable to the openswan RSA oracle attack as well. For openswan versions before v2.6.51.3 (released March 2019) that are not compiled to use the NSS crypto library, there is a risk these versions are vulnerable to an RSA oracle attack that could yield the IKE SA encryption key. While older versions of Red Hat Enterprise Linux (RHEL) used to support openswan, these are not vulnerable to an RSA oracle attack as these versions used the NSS crypto library. All current versions of RHEL now use libreswan and cannot be exploited. If still using openswan, please consult your vendor or upgrade to libreswan. Workaround ========== A possible workaround is to reconfigure IKEv1 connections to use IKEv2, using the keyword ikev2=insist. However, this must be supported and allowed by the IKE peer as well. History ======= All vulnerable versions listed above, inherited the vulnerable code from the patched freeswan codebase known at the time as "super-freeswan". Freeswan itself never supported any Informational Exchange message. Strongswan and openswan are forks of "super-freeswan", and libreswan is a fork/continuation of openswan-2.6.38. Strongswan removed the "super-freeswan" inherited code in version 5.0.0. Credits ======= This vulnerability was found by the Libreswan Project |
0009 security Fix for CVE 2020 1763.patch | (download) |
programs/pluto/ikev1.c |
2 1 + 1 - 0 ! |
security: fix for cve-2020-1763 |