From $URL: A trusted partner privately reported an authentication bypass vulnerability (CVE-2014-2338) in the strongSwan IKEv2 code. Affected are all strongSwan versions back to 4.0.7, including the latest 5.1.2. The bug can be triggered by rekeying an unestablished IKE_SA while it gets actively initiated. This allows an attacker to trick the peer's IKE_SA state to established, without the need to provide any valid authentication credentials. Only installations that actively initiate or re-authenticate IKEv2 IKE_SAs are affected. This means when re-authentication is disabled (reauth=no) or not possible (because of the use of asymmetric EAP or virtual IP exchanges), a connection with auto=add is not exploitable. If re-authentication is enabled and no EAP/virtual IP exchange is in use, an attacker may just wait for the peer to initiate the re-authentication to start its attack. The issue does not allow remote code execution, nor is IKEv1 affected in charon or pluto. Fix === The just released strongSwan 5.1.3 fixes this vulnerability. For older releases we provide patches that fix the vulnerability and should apply with appropriate hunk offsets. See also: https://bugzilla.redhat.com/show_bug.cgi?id=1081760 Gentoo has net-misc/strongswan-5.1.1 and net-misc/strongswan-5.1.2 in tree. Both versions are vulnerable. 5.1.3 is not yet available in tree. Reproducible: Always
Thanks for the report.
5.1.2 has been removed, and 5.1.3 has been added to the tree. Please stabilize 5.1.3 asap, and remove 5.1.1 once that's done.
Arches, please test and mark stable: =net-misc/strongswan-5.1.3 Target keywords : "amd64 arm ppc x86"
amd64 stable
x86 stable
arm stable
ppc stable. Maintainer(s), please cleanup. Security, please vote.
Old version has been removed, so now only the fixed version is in the tree.
Maintainer(s), Thank you for cleanup! Security please Vote!
GLSA Vote: Yes
CVE-2014-2338 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-2338): IKEv2 in strongSwan 4.0.7 before 5.1.3 allows remote attackers to bypass authentication by rekeying an IKE_SA during (1) initiation or (2) re-authentication, which triggers the IKE_SA state to be set to established.
YES too, request filed.
This issue was resolved and addressed in GLSA 201412-26 at http://security.gentoo.org/glsa/glsa-201412-26.xml by GLSA coordinator Sean Amoss (ackle).