Bug 953817 - (CVE-2015-8023) VUL-0: CVE-2015-8023: strongswan: eap-mschapv2 authentication bypass vulnerability
(CVE-2015-8023)
VUL-0: CVE-2015-8023: strongswan: eap-mschapv2 authentication bypass vulnerab...
Status: RESOLVED FIXED
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
unspecified
Other Other
: P2 - High : Major
: ---
Assigned To: Security Team bot
Security Team bot
CVSSv2:SUSE:CVE-2015-8023:7.5:(AV:N/A...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-05 16:03 UTC by Alexander Bergmann
Modified: 2016-04-27 18:22 UTC (History)
5 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Bergmann 2015-11-05 16:03:21 UTC
Pre-Announcement from Tobias Brunner <tobias@strongswan.org>
Date: Thu, 5 Nov 2015 14:23:39 +0100
Subject: [security@suse.de] strongSwan security vulnerability: CVE-2015-8023
CRD: 16.11.2015, 12:00 UTC
------------------------------

Dear strongSwan partner,

While looking into a different issue I recently discovered a serious
authentication bypass vulnerability in our eap-mschapv2 plugin.  All
strongSwan versions since 4.2.12 are affected.

CVE-2015-8023 has been assigned for this vulnerability.

Affected are IKEv2 connections that use EAP-MSCHAPv2 to authenticate
clients via our own eap-mschapv2 plugin.  It doesn't matter if it is
used directly (rightauth=eap-mschapv2) or tunneled in EAP-PEAP or
EAP-TTLS (rightauth=eap-peap|ttls and phase2_method = mschapv2) or if
the eap-dynamic plugin is used (rightauth=eap-dynamic) with the
eap-mschapv2 plugin being loaded.
Installations that use RADIUS to provide EAP-MSCHAPv2 authentication to
their clients (rightauth=eap-radius) are not affected (provided the
RADIUS server's EAP-MSCHAPv2 implementation is correct).

The EAP-MSCHAPv2 protocol works roughly as follows:  The server sends a
Challenge message to the client containing a challenge string.  The
client uses that string together with the username and password to
calculate a response that it sends back in a Response message, which
also contains a challenge provided by the client.  The server validates
the response and, in turn, uses the client's challenge string, username
and password to calculate a response that proves it also knows that
shared secret.  This response is sent to the client in a Success Request
message.  The client verifies the server's response and, if valid, sends
an empty Success Response message to the server, which successfully
concludes the EAP method.  If the authentication was successful an EAP
MSK (Master Session Key) is calculated based on the password and the
client's original response.  Please refer to [1] and RFC 2759 for details.

Due to insufficient validation of its local state the server
implementation of the EAP-MSCHAPv2 protocol in the eap-mschapv2 plugin
can be tricked into successfully concluding the authentication without
providing valid credentials.  In fact, the client can simply send the
last message in the process described above (i.e. an empty Success
message) as response to the server's Challenge message to pass the
EAP-MSCHAPv2 authentication successfully.

Since no MSK is established if this happens it's possible to recognize
such attacks by looking at the server logs.  The following log message
would be seen during the client authentication:

  EAP method EAP_MSCHAPV2 succeeded, no MSK established

Please let us know if you noticed such attacks on your servers.

The attached patches fix the vulnerability in the affected strongSwan
versions and should apply with appropriate hunk offsets.

Please prepare updated releases and patch your installations, but do not
yet publicly disclose any information about this vulnerability.  We want
to give you as a partner enough time to prepare new releases and will
publicly disclose the vulnerability with the strongSwan 5.3.4 release on
Mon Nov 16th, 12:00 noon UTC.

The issue I originally looked into (reported by a user at [2]) also
concerns the eap-mschapv2 plugin and mostly affects setups where a
client's EAP-Identity is used for accounting purposes or duplicate
checking.  Because the username used during the EAP-MSCHAPv2 exchange
was not tied to the identity exchanged in an earlier EAP-Identity
exchange (or the IKE identity) a client could choose an arbitrary
EAP-Identity and then authenticate itself using its own username and
passsword (a regular client usually uses the same identity/username for
the two exchanges, but that's quite obviously not a requirement).
Subsequently, the client is identified by its chosen EAP-Identity and
not its actual username.  The upcoming release will also include a fix
for this issue.

Our apologies for the inconvenience.

Kind Regards
Tobias Brunner
strongSwan Developer

[1] https://tools.ietf.org/html/draft-kamath-pppext-eap-mschapv2
[2] https://wiki.strongswan.org/issues/1182
Comment 1 Swamp Workflow Management 2015-11-05 23:00:15 UTC
bugbot adjusting priority
Comment 5 Bernhard Wiedemann 2015-11-13 15:04:17 UTC
This is an autogenerated message for IBS integration:
This bug (953817) was mentioned in
https://build.suse.de/request/show/80339 SLE-12 / strongswan
Comment 7 Marius Tomaschewski 2015-11-16 15:30:02 UTC
Issue is public: https://wiki.strongswan.org/projects/strongswan/wiki/Changelog53

updates requested in obs rq:
   344761 openSUSE:Leap:42.1:Update
   344762 openSUSE:Factory
   344763 openSUSE:13.2:Update
   344764 openSUSE:13.1:Update
Comment 8 Bernhard Wiedemann 2015-11-16 16:00:16 UTC
This is an autogenerated message for OBS integration:
This bug (953817) was mentioned in
https://build.opensuse.org/request/show/344761 Leap:42.1 / strongswan
https://build.opensuse.org/request/show/344762 Factory / strongswan
https://build.opensuse.org/request/show/344763 13.2 / strongswan
https://build.opensuse.org/request/show/344764 13.1 / strongswan
Comment 12 Swamp Workflow Management 2015-11-25 21:11:44 UTC
openSUSE-SU-2015:2103-1: An update that fixes one vulnerability is now available.

Category: security (moderate)
Bug References: 953817
CVE References: CVE-2015-8023
Sources used:
openSUSE Leap 42.1 (src):    strongswan-5.2.2-7.1
openSUSE 13.2 (src):    strongswan-5.1.3-4.14.1
openSUSE 13.1 (src):    strongswan-5.1.1-14.1
Comment 13 Alexander Bergmann 2015-12-01 09:00:18 UTC
All good from the submission side. Removing needinfo.
Comment 14 Swamp Workflow Management 2015-12-03 17:11:41 UTC
SUSE-SU-2015:2183-1: An update that fixes one vulnerability is now available.

Category: security (moderate)
Bug References: 953817
CVE References: CVE-2015-8023
Sources used:
SUSE Linux Enterprise Server 12 (src):    strongswan-5.1.3-21.1
SUSE Linux Enterprise Desktop 12 (src):    strongswan-5.1.3-21.1
Comment 15 Swamp Workflow Management 2015-12-03 17:13:12 UTC
SUSE-SU-2015:2186-1: An update that fixes one vulnerability is now available.

Category: security (moderate)
Bug References: 953817
CVE References: CVE-2015-8023
Sources used:
SUSE Linux Enterprise Server for VMWare 11-SP3 (src):    strongswan-4.4.0-6.32.1
SUSE Linux Enterprise Server 11-SP4 (src):    strongswan-4.4.0-6.32.1
SUSE Linux Enterprise Server 11-SP3 (src):    strongswan-4.4.0-6.32.1
SUSE Linux Enterprise Desktop 11-SP4 (src):    strongswan-4.4.0-6.32.1
SUSE Linux Enterprise Desktop 11-SP3 (src):    strongswan-4.4.0-6.32.1
SUSE Linux Enterprise Debuginfo 11-SP4 (src):    strongswan-4.4.0-6.32.1
SUSE Linux Enterprise Debuginfo 11-SP3 (src):    strongswan-4.4.0-6.32.1
Comment 16 Andreas Stieger 2015-12-21 19:00:34 UTC
releasing SLE 12 / SLE 12 SP1 update
Comment 17 Andreas Stieger 2015-12-21 19:21:29 UTC
All done
Comment 18 Swamp Workflow Management 2015-12-21 22:11:01 UTC
SUSE-SU-2015:2183-2: An update that fixes one vulnerability is now available.

Category: security (important)
Bug References: 953817
CVE References: CVE-2015-8023
Sources used:
SUSE Linux Enterprise Server 12-SP1 (src):    strongswan-5.1.3-22.1
SUSE Linux Enterprise Desktop 12-SP1 (src):    strongswan-5.1.3-22.1