From f27bf12e3206cc6ee80cc603d43ac913745a4c9a Mon Sep 17 00:00:00 2001 From: Mathy Vanhoef Date: Mon, 21 Jun 2021 23:57:45 +0400 Subject: [PATCH] fragattacks: README: clarify ping-frag-sep tests --- README.md | 13 ++++++++----- research/fragattack.py | 10 +++++++--- 2 files changed, 15 insertions(+), 8 deletions(-) diff --git a/README.md b/README.md index 710eb1a64..df2702049 100644 --- a/README.md +++ b/README.md @@ -315,13 +315,16 @@ CVEs as a way to easily refer to each type of discovered implementation flaw. - `ping-frag-sep`: This tests sends a fragmented Wi-Fi frame that is seperated by an unrelated frame. That is, it sends the first fragment, then a (normal) unrelated Wi-Fi frame, and finally the second fragment. - In case this test fails, the mixed key attack and cache attack will likely also fail (since they require - sending other frames between two fragments). The only purpose of this test is to better understand the - behaviour of a device and to learn why other tests might be failing. + In case this test fails, the (default) mixed key attack and cache attack will likely also fail (since they require + sending other frames between two fragments). This test will also fail in case the reciever checks whether fragments + have consecutive packet numbers (see the next test `ping-frag-sep --pn-per-qos`). - `ping-frag-sep --pn-per-qos`: Same as above, but adding the `--pn-per-qos` parameter assures both fragments - have a consecutive Packet Number (PN). This is something that a reciever should be verifying in order to be - secure. Unfortunately, many implementations don't verify whether PNs are consecutive. + of the ping request have a consecutive Packet Number (PN). This is something that a reciever _should_ be + verifying in order to be secure. Unfortunately, before the disclosure of our results, many implementations + don't verify whether PNs are consecutive. This test might fail in case the reciever doesn't track the latest + received packet counter per QoS TID, in which case you can ignore other tests that contain the `--pn-per-qos` + parameter. ## 7.3. A-MSDU attack tests (ยง3 -- CVE-2020-24588) diff --git a/research/fragattack.py b/research/fragattack.py index 1b58df411..2615a108a 100755 --- a/research/fragattack.py +++ b/research/fragattack.py @@ -65,9 +65,13 @@ def prepare_tests(opt): elif opt.testname == "ping-frag-sep": # Check if we can send frames in between fragments. The seperator by default uses a different - # QoS TID. The second fragment must use an incremental PN compared to the first fragment. - # So this also tests if the receivers uses a per-QoS receive replay counter. By overriding - # the TID you can check whether fragments are cached for multiple sequence numbers in one TID. + # QoS TID. The second fragment of the ping request will NOT have an incremental PN compared + # to the first fragment. So this test fails if the receivers checks for consecutive PNs. By adding + # `--pn-per-qos` both ping fragments will use consecutive PNs, but this will only be accepted if + # the receiver checks PNs for each QoS TID separately. + # By overriding the TID to 2 you can check whether fragments are cached for multiple sequence numbers + # in one TID (since all fragments use the same TID but the ping fragments use a different sequence + # number compared to the seperator). tid = 1 if stractions == None else int(stractions) separator = Dot11(type="Data", subtype=8, SC=(33 << 4) | 0)/Dot11QoS(TID=tid)/LLC()/SNAP() test = PingTest(REQ_ICMP,