strongSwan - Design by Margo Galas <galas (at) solnet (dot) ch>

Main Sponsors

secunet

secunet

revosec

Hochschule für Technik Rapperswil

strongSwan 5.5.3 Released

We are happy to announce the release of strongSwan 5.5.3 which avoids traffic loss during IKEv2 CHILD_SA rekeying, runs on the ARM64 iOS platform, and fixes two vulnerabilities and several other issues.


Denial-of-Service Vulnerability in the gmp Plugin (CVE-2017-9022)

A denial-of-service vulnerability in the gmp plugin was fixed that was caused by insufficient input validation when verifying RSA signatures. More specifically, mpz_powm_sec() has two requirements regarding the passed exponent and modulus that the plugin did not enforce, if these are not met the calculation will result in a floating point exception that crashes the whole process. All versions since 4.4.0 are affected.

More information is provided in a separate blog entry.

Denial-of-Service Vulnerability in the x509 Plugin (CVE-2017-9023)

A denial-of-serviced vulnerability in the x509 plugin was fixed that was caused because the ASN.1 parser didn't handle ASN.1 CHOICE types properly, which could result in an infinite loop when parsing X.509 extensions that use such types. All versions are affected.

More information is provided in a separate blog entry.

Improved IKEv2 CHILD_SA Rekeying Behavior

The behavior during IKEv2 CHILD_SA rekeying has been changed in order to avoid traffic loss. When responding to a CREATE_CHILD_SA request to rekey a CHILD_SA the responder already has everything available to install and use the new CHILD_SA. However, this could lead to lost traffic as the initiator won't be able to process inbound packets until it processed the CREATE_CHILD_SA response and updated the inbound SA. To avoid this the responder now only installs the new inbound SA and delays installing the outbound SA until it receives the DELETE for the replaced CHILD_SA.

The messages transporting these DELETEs could reach the peer before packets sent with the deleted outbound SAs reach it. To reduce the chance of traffic loss due to this the inbound SA of the replaced CHILD_SA is not removed for a configurable amount of seconds (charon.delete_rekeyed_delay) after the DELETE has been processed.

Port to the ARM64 iOS Platform

The strongSwan code base has been ported to Apple's ARM64 iOS platform, which required several changes regarding the use of variadic functions. This was necessary because the calling conventions for variadic and regular functions are different there. This means that assigning a non-variadic function to a variadic function pointer, as we did with our enumerator_t::enumerate() implementations and several callbacks, will
result in crashes as the called function accesses the arguments differently than the caller provided them. To avoid this issue the enumerator_t interface has been changed and the signature of the callback functions for enumerator_create_filter() and two methods on linked_list_t have been changed. Refer to the changelog on our wiki for details.

Fuzzing

Support for fuzzing the certificate parser provided by the default plugins (x509, pem, gmp etc.) on Google's OSS-Fuzz infrastructure (or generally with libFuzzer) was added. Several issues found while fuzzing these plugins were fixed (including the two vulnerabilities mentioned above).

Other Notable Features and Fixes

  • Two new options have been added to charon's retransmission settings: retransmit_limit and retransmit_jitter. The former adds an upper limit to the calculated retransmission timeout, the latter randomly reduces it.
  • A bug in swanctl's --load-creds command was fixed that caused unencrypted private keys to get unloaded if the command was called multiple times. The load-key VICI command now returns the key ID of the loaded key on success.
  • Adds support for hardware offload of IPsec SAs as introduced by Linux 4.11 for specific hardware that supports this.
  • The credential manager now enumerates local credential sets before global ones. This means certificates supplied by the peer will now be preferred over certificates with the same identity that may be locally stored (e.g. in the certificate cache).

Download Complete Changelog