Amazing-Mirror/fragattacks
1
0
Fork 0
mirror of https://github.com/vanhoefm/fragattacks.git synced 2024-11-24 16:28:23 -05:00
Code Issues Projects Releases Wiki Activity

fragattacks: README: clarify ping-frag-sep tests

Browse Source
This commit is contained in:
Mathy Vanhoef 2021-06-21 23:57:45 +04:00
parent e35da72fdf
commit f27bf12e32
2 changed files with 15 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
README.md
View File

@ -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.
<a id="id-test-amsdu"></a>
## 7.3. A-MSDU attack tests (§3 -- CVE-2020-24588)

10
research/fragattack.py
View File

@ -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,