-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


Release date: Monday Jun 10, 2019
Contact: team@libreswan.org
PGP key: 907E790F25C1E8E561CD73B585FF4B43B30FC6F9

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

About libreswan (https://libreswan.org/)
========================================
Libreswan is a free implementation of the Internet Key Exchange (IKE)
protocols IKEv1 and IKEv2. It is a descendant (continuation fork) of
openswan 2.6.38. IKE is used to establish IPsec VPN connections.

IPsec uses strong cryptography to provide both authentication and
encryption services. These services allow you to build secure tunnels
through untrusted networks. Everything passing through the untrusted
network is encrypted by the IPsec gateway machine, and decrypted by
the gateway at the other end of the tunnel. The resulting tunnel is a
virtual private network (VPN).

Upgrading
=========
To address this vulnerability, please upgrade to libreswan 3.29.
For those who cannot upgrade to 3.29, the URL above contains a  minimal
patch that can be used to patch older libreswan releases, and possibly
can be used as a basis for an openswan patch.
======================================================================
-----BEGIN PGP SIGNATURE-----


+SY9RHoVs1y+Bw==
=oIA6
-----END PGP SIGNATURE-----
