packaging/utils/setlibreswanversion | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 do not use git version

avoid using git version when building debian package

pam.d/pluto | 27 11 + 16 - 0 !
1 file changed, 11 insertions(+), 16 deletions(-)

 debian-pam.d-pluto

debian: fix /etc/pam.d/pluto to work with debian

Signed-off-by: Tuomo Soini <tis@foobar.fi>

README.nss | 14 7 + 7 - 0 !
1 file changed, 7 insertions(+), 7 deletions(-)

 update readme.nss to match debian defaults for ipsec_nssdir

programs/show/show.in | 2 1 + 1 - 0 !
programs/verify/verify.in | 2 1 + 1 - 0 !
2 files changed, 2 insertions(+), 2 deletions(-)

 move to python3 (scripts are compatible)

programs/pluto/ikev2_parent.c | 1 1 + 0 - 0 !
1 file changed, 1 insertion(+)

 pluto: set hdr.isa_length to 0 in informational()

(cherry picked from commit 16859c49e67903a913e38f6410718f6b42647a89)

programs/algparse/Makefile | 2 1 + 1 - 0 !
programs/cavp/Makefile | 2 1 + 1 - 0 !
programs/spi/Makefile | 2 1 + 1 - 0 !
3 files changed, 3 insertions(+), 3 deletions(-)

 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.

programs/pluto/ikev2_send.c | 11 11 + 0 - 0 !
1 file changed, 11 insertions(+)

 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.

--

programs/pluto/ikev1.c | 26 26 + 0 - 0 !
programs/pluto/ikev1_quick.c | 8 4 + 4 - 0 !
programs/pluto/ipsec_doi.h | 5 5 + 0 - 0 !
3 files changed, 35 insertions(+), 4 deletions(-)

 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

programs/pluto/ikev1.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 security: fix for cve-2020-1763