One strongSwan users reported a denial-of-service vulnerability in
strongSwan. Affected are strongSwan versions 4.5.0 and newer, including
the latest 5.2.1.
The bug can be triggered by an IKEv2 Key Exchange (KE) payload that
contains the Diffie-Hellman (DH) group 1025. This identifier is from
the private-use range and only used internally by libtls for DH groups
with custom generator and prime (MODP_CUSTOM). As such the instantiated
method expects that these two values are passed to the constructor.
This is not the case when a DH object is created based on the group in
the KE payload. Therefore, an invalid pointer is dereferenced later,
which causes a segmentation fault. This means that the daemon can be
crashed with a single IKE_SA_INIT message containing such a KE payload.
Remote code execution is not possible due to this issue, nor is IKEv1
affected in charon or pluto.
The attached patches fix the vulnerability in the different strongSwan
versions and should apply with appropriate hunk offsets.
This issue is fixed in strongSwan 5.2.2 which will be released on
Dec 22nd, 12:00 noon UTC.
This issue did not affect the versions of strongimcv as shipped with Red Hat Enterprise Linux 7 as they did not include support for strongswan IKEv1/IKEv2.
Red Hat would like to thank the strongSwan developers for reporting this issue. Upstream acknowledges Mike Daskalakis as the original reporter.
Created attachment 967203 [details]
Created attachment 967204 [details]
Upstrem decided to move dislosure date earlier:
Due to feedback we received we will not do the release in Christmas
week. Instead we'll disclose the vulnerability and release 5.2.2 on
Friday Dec 19th, 12:00 noon UTC.
Another upstream update, disclosure date moved to Jan 5th 2015:
Our integration tests that we run before every release revealed that
these patches were inadequate. They broke most of the TLS scenarios.
The intention was to increase the identifier of MODP_CUSTOM beyond the
16-bit size limit of DH identifiers in IKEv2 so this DH group can't be
negotiated anymore. A side effect of this is that the size of the
diffie_hellman_group_t enum increases to 32-bit. The problem with that
is that it went unnoticed that the Diffie Hellman implementations in the
different plugins (gmp, openssl etc.) internally used u_int16_t instead
of diffie_hellman_group_t to store the group identifier.
One set of the attached patches fix this specific problem in the
respective strongSwan versions and should apply with appropriate hunk
offsets. Patches that include both fixes are attached too.
I'm terribly sorry we missed this issue earlier and having to send this
email so close to the intended release date. Instead of rushing out the
5.2.2 release and the vulnerability disclosure today, we will move the
release date to Jan 5th, 12:00 noon UTC.
For a coordinated public disclosure of the issue we're kindly asking
to hold back any prepared release for today and defer such releases to
the mentioned date.
Once again, our apologies for the inconvenience.
Created attachment 971115 [details]
Created attachment 971116 [details]
Created attachment 971117 [details]
Created attachment 971118 [details]
Created attachment 971119 [details]
Created attachment 971120 [details]
Created attachment 971121 [details]
Created attachment 971122 [details]
Created attachment 971123 [details]
Created strongswan tracking bugs for this issue:
Affects: fedora-all [bug 1178956]
Affects: epel-all [bug 1178957]
strongswan-5.2.2-2.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
strongswan-5.3.2-1.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.