1
0
forked from pool/strongswan
strongswan/0005-ikev1-Don-t-retransmit-Aggressive-Mode-response.patch
Nirmoy Das 8cfc35877a Accepting request 513652 from home:ndas:branches:network:vpn
- 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

OBS-URL: https://build.opensuse.org/request/show/513652
OBS-URL: https://build.opensuse.org/package/show/network:vpn/strongswan?expand=0&rev=99
2017-08-01 07:21:05 +00:00

28 lines
1.1 KiB
Diff

From 4e16732c1c668c27e73574724d2d90537a74f67a Mon Sep 17 00:00:00 2001
From: Tobias Brunner <tobias@strongswan.org>
Date: Fri, 17 Jun 2016 18:19:48 +0200
Subject: [PATCH] ikev1: Don't retransmit Aggressive Mode response
These could theoretically be used for an amplified DDoS attack.
---
src/libcharon/sa/ikev1/task_manager_v1.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/libcharon/sa/ikev1/task_manager_v1.c b/src/libcharon/sa/ikev1/task_manager_v1.c
index 48ec3e7..0912555 100644
--- a/src/libcharon/sa/ikev1/task_manager_v1.c
+++ b/src/libcharon/sa/ikev1/task_manager_v1.c
@@ -770,8 +770,7 @@ static status_t build_response(private_task_manager_t *this, message_t *request)
continue;
case NEED_MORE:
/* processed, but task needs another exchange */
- if (task->get_type(task) == TASK_QUICK_MODE ||
- task->get_type(task) == TASK_AGGRESSIVE_MODE)
+ if (task->get_type(task) == TASK_QUICK_MODE)
{ /* we rely on initiator retransmission, except for
* three-message exchanges */
expect_request = TRUE;
--
2.13.2