Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 507722 (CVE-2014-2338) - <net-misc/strongswan-5.1.3: Authentication Bypass Vulnerability in IKEv2 (CVE-2014-2338)
Summary: <net-misc/strongswan-5.1.3: Authentication Bypass Vulnerability in IKEv2 (CVE...
Status: RESOLVED FIXED
Alias: CVE-2014-2338
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal minor
Assignee: Gentoo Security
URL: http://www.strongswan.org/blog/2014/0...
Whiteboard: B3 [glsa]
Keywords:
Depends on:
Blocks: CVE-2014-2891
  Show dependency tree
 
Reported: 2014-04-15 14:17 UTC by Thomas Deutschmann (RETIRED)
Modified: 2014-12-13 19:20 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Deutschmann (RETIRED) gentoo-dev 2014-04-15 14:17:34 UTC
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
Comment 1 Agostino Sarubbo gentoo-dev 2014-04-15 14:28:45 UTC
Thanks for the report.
Comment 2 Bjarke Istrup Pedersen (RETIRED) gentoo-dev 2014-04-16 09:07:25 UTC
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.
Comment 3 Agostino Sarubbo gentoo-dev 2014-04-17 12:58:39 UTC
Arches, please test and mark stable:
=net-misc/strongswan-5.1.3
Target keywords : "amd64 arm ppc x86"
Comment 4 Agostino Sarubbo gentoo-dev 2014-04-19 10:05:31 UTC
amd64 stable
Comment 5 Agostino Sarubbo gentoo-dev 2014-04-19 10:07:38 UTC
x86 stable
Comment 6 Agostino Sarubbo gentoo-dev 2014-04-22 12:28:23 UTC
arm stable
Comment 7 Agostino Sarubbo gentoo-dev 2014-05-10 14:02:15 UTC
ppc stable.

Maintainer(s), please cleanup.
Security, please vote.
Comment 8 Bjarke Istrup Pedersen (RETIRED) gentoo-dev 2014-05-10 15:22:59 UTC
Old version has been removed, so now only the fixed version is in the tree.
Comment 9 Yury German Gentoo Infrastructure gentoo-dev 2014-05-15 02:45:33 UTC
Maintainer(s), Thank you for cleanup!

Security please Vote!
Comment 10 Yury German Gentoo Infrastructure gentoo-dev 2014-06-16 04:15:28 UTC
GLSA Vote: Yes
Comment 11 GLSAMaker/CVETool Bot gentoo-dev 2014-07-06 14:37:30 UTC
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.
Comment 12 Tobias Heinlein (RETIRED) gentoo-dev 2014-08-04 19:27:42 UTC
YES too, request filed.
Comment 13 GLSAMaker/CVETool Bot gentoo-dev 2014-12-13 19:20:52 UTC
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).