jengelh/strongswan
SHA256
1
0
Fork 0
forked from pool/strongswan
Code Pull Requests Activity
fe861579d5
strongswan/0005-ikev1-Don-t-retransmit-Aggressive-Mode-response.patch

28 lines
1.1 KiB
Diff
Raw Normal View History

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 09:21:05 +02:00
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
Copy Permalink