Truncated L2CAP attack misalignment between script and paper

[mantegna10]

According to the White Paper:

If the total length of the packet (i.e. LL Length) has
a value lower than L2CAP Length + 4 for a valid payload,
then the truncated bytes are copied beyond the underlying
reception buffer.

In the example (fig. 6 of the white paper) the L2CAP Length is set to 3, while LL Length is 5 (5 < 3+4) and the L2CAP reception buffer is overflown by two bytes (i.e. L2CAP Length+4−LL Length)

Trying to execute:
DA14580_exploit_att_crash.py
at line 139, the bytes to send are set to:
length_req = BTLE('7083329a02070000040010edea874aac'.decode('hex')) # att

In the packet above the L2CAP Length is set to 0 and LL Length to 7 (LL Length > L2CAP Length + 4). This is not in accordance with what stated in the paper (See Wireshark capture in the attachment).

I've tried to change the script, but I'm not able to calculate the CRC.
Thanks for the support.

[Matheus-Garbelini]

Hi @mantegna10 I believe there was some swap by mistake on the scripts name for variants of this attack.
You can see the truncated l2cap here:

• https://github.com/Matheus-Garbelini/sweyntooth_bluetooth_low_energy_attacks/blob/master/extras/DA14680_att_mtu_length_5_malformed_accepted.py
• https://github.com/Matheus-Garbelini/sweyntooth_bluetooth_low_energy_attacks/blob/master/extras/DA14680_truncated_l2cap_crash.py

Note that the exact attack vector triggers a crash on DA14580, but not on DA14680, hence why it was added as non-compliance test for DA14680.

[alereds94]

Hi @Matheus-Garbelini, I have experienced the same issue.

I think the source problem is some mismatch on the table:
https://github.com/Matheus-Garbelini/sweyntooth_bluetooth_low_energy_attacks#available-ble-exploits

where the Truncated L2CAP (CVE-2019-17517), whose theoretical fundament is explained in Section 6.3 of the white paper, is associated with the script DA14580_exploit_att_crash.py.