- Updated to strongSwan 5.3.5 providing the following changes:
*Fixed a DoS vulnerability in the gmp plugin 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.
This vulnerability has been registered as CVE-2017-9022.
Please refer to our blog for details.
*Fixed a DoS vulnerability in the x509 plugin 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.
This vulnerability has been registered as CVE-2017-9023.
Please refer to our blog for details.
*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.
*The 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