CVE-2020-24588

[D3adP3nguin]

We have a test case where amsdu-inject passes (vulnerable) and amsdu-inject-bad fails (not vulnerable) according to the language used in the README.md if either test succeeds then the device is vulnerable to CVE-2020-24588. However, when reading over the beginning of the amsdu-inject-nad definition it states the following: ‘Some devices incorrectly parse A-MSDU frames that start with a valid LLC/SNAP header causing the above test to fail.’ Would this mean if ams-inject fails (not vulnerable) and amsdu-inject-bad passes (vulnerable) this is due to an incorrectly parsed A-MSDU frame?

[vanhoefm]

Would this mean if ams-inject fails (not vulnerable) and amsdu-inject-bad passes (vulnerable) this is due to an incorrectly parsed A-MSDU frame?

Yes. See the last paragraph of Section 3.6 in https://papers.mathyvanhoef.com/usenix2021.pdf

[D3adP3nguin]

In the detailed white paper it states the following:

We can exploit this design flaw by manipulating a normal 802.11 frame such that, when it is processed as an A-MSDU frame, one of the subframes will correspond to a packet that we want to inject. This requires the frame's payload to contain a specially crafted packet

So in the README.md for amsdu-inject-bad it states "some devices incorrectly parse A-MSDU frames..."

Is the above section from the white paper explaining why the A-MSDU frame is being incorrectly parsed or is there another reason causing that?

Another thought is is the A-MSDU frame is created in a way it's causing the device to incorrectly parse the entire payload? I'm not sure I'm just trying to get a better understanding is to why it is still vulnerable under amsdu-inject-bad

[vanhoefm]

From the last paragraph in Section 3.6:

When testing the attack against FreeBSD and Linux 4.9 and above, we noticed that we were unable to inject packets as described in Section 3.2.

In other words, amsdu-inject didn't work against FreeBSD and Linux 4.9.

Upon closer inspection we found that these operating systems strip away the first 8 bytes of an A-MSDU frame if these bytes look like a valid LLC/SNAP header, and then further process the frame. This behavior is not compliant with the 802.11 standard.

In other words, the frame that the adversary must inject to exploit the vulnerability is parsed in an incorrect manner by these operating systems.

When the first 8 bytes are stripped, the length field of the first A-MSDU subframe corresponds with the first two bytes of the source IP address. If the victim is not behind a firewall, we can spoof the source address of our IPv4 packets such that the injected packet will again be contained in the second A-MSDU subframe.

Nevertheless, using some clever tricks, we can still perform the attack against FreeBSD and Linux 4.9. This corresponds to the amsdu-inject-bad test.

Whenever the test amsdu-inject-bad succeeds it means that the device is vulnerable and that it incorrectly parses the frame.

[vanhoefm]

Closing this since this seems to be resolved. You can still reply if you have related questions.