From 3b9374fa57218c72306d372167724e88ef7d57be Mon Sep 17 00:00:00 2001 From: Neale Ranns Date: Thu, 1 Aug 2019 04:45:15 -0700 Subject: ipsec: Redo the anit-replay check post decrypt Type: fix Change-Id: I1fa8c5326d6f22cfb8dd40e97d8a22d11a716922 Signed-off-by: Neale Ranns --- src/vnet/ipsec/ah_decrypt.c | 7 +++++++ src/vnet/ipsec/esp_decrypt.c | 29 +++++++++++++++++++++++++++++ test/template_ipsec.py | 15 +++++++++++++++ 3 files changed, 51 insertions(+) diff --git a/src/vnet/ipsec/ah_decrypt.c b/src/vnet/ipsec/ah_decrypt.c index bc6b5c4ec9d..bbe6b647c52 100644 --- a/src/vnet/ipsec/ah_decrypt.c +++ b/src/vnet/ipsec/ah_decrypt.c @@ -303,6 +303,13 @@ ah_decrypt_inline (vlib_main_t * vm, if (PREDICT_TRUE (sa0->integ_alg != IPSEC_INTEG_ALG_NONE)) { + /* redo the anit-reply check. see esp_decrypt for details */ + if (ipsec_sa_anti_replay_check (sa0, pd->seq)) + { + b[0]->error = node->errors[AH_DECRYPT_ERROR_REPLAY]; + next[0] = AH_DECRYPT_NEXT_DROP; + goto trace; + } ipsec_sa_anti_replay_advance (sa0, pd->seq); } diff --git a/src/vnet/ipsec/esp_decrypt.c b/src/vnet/ipsec/esp_decrypt.c index c2b9bf4dc0c..986ac94676c 100644 --- a/src/vnet/ipsec/esp_decrypt.c +++ b/src/vnet/ipsec/esp_decrypt.c @@ -376,6 +376,35 @@ esp_decrypt_inline (vlib_main_t * vm, sa0 = vec_elt_at_index (im->sad, pd->sa_index); + /* + * redo the anti-reply check + * in this frame say we have sequence numbers, s, s+1, s+1, s+1 + * and s and s+1 are in the window. When we did the anti-replay + * check above we did so against the state of the window (W), + * after packet s-1. So each of the packets in the sequence will be + * accepted. + * This time s will be cheked against Ws-1, s+1 chceked against Ws + * (i.e. the window state is updated/advnaced) + * so this time the successive s+! packet will be dropped. + * This is a consequence of batching the decrypts. If the + * check-dcrypt-advance process was done for each packet it would + * be fine. But we batch the decrypts because it's much more efficient + * to do so in SW and if we offload to HW and the process is async. + * + * You're probably thinking, but this means an attacker can send the + * above sequence and cause VPP to perform decrpyts that will fail, + * and that's true. But if the attacker can determine s (a valid + * sequence number in the window) which is non-trivial, it can generate + * a sequence s, s+1, s+2, s+3, ... s+n and nothing will prevent any + * implementation, sequential or batching, from decrypting these. + */ + if (ipsec_sa_anti_replay_check (sa0, pd->seq)) + { + b[0]->error = node->errors[ESP_DECRYPT_ERROR_REPLAY]; + next[0] = ESP_DECRYPT_NEXT_DROP; + goto trace; + } + ipsec_sa_anti_replay_advance (sa0, pd->seq); esp_footer_t *f = (esp_footer_t *) (b[0]->data + pd->current_data + diff --git a/test/template_ipsec.py b/test/template_ipsec.py index 773531fe038..c3fc8bd434f 100644 --- a/test/template_ipsec.py +++ b/test/template_ipsec.py @@ -317,6 +317,21 @@ class IpsecTra4(object): replay_count += len(pkts) self.assert_error_counter_equal(replay_node_name, replay_count) + # + # now send a batch of packets all with the same sequence number + # the first packet in the batch is legitimate, the rest bogus + # + pkts = (Ether(src=self.tra_if.remote_mac, + dst=self.tra_if.local_mac) / + p.scapy_tra_sa.encrypt(IP(src=self.tra_if.remote_ip4, + dst=self.tra_if.local_ip4) / + ICMP(), + seq_num=35)) + recv_pkts = self.send_and_expect(self.tra_if, pkts * 8, + self.tra_if, n_rx=1) + replay_count += 7 + self.assert_error_counter_equal(replay_node_name, replay_count) + # # now move the window over to 257 (more than one byte) and into Case A # -- cgit 1.2.3-korg