boaks
commented
8 months ago @mengrj
Just in the case, you're interested, the original eclipse/tinydtls project has fixed quite a lot of bugs in the past years. Unfortunately, no one here in contiki-ng seems to be able (or interested) in updating it.
If you want to help improving the quality of eclipse/tinydtls, please retest the issues using the current main there.
In the master branch (until current 53a0d97), an illegal buffer over-read in the dtls_sha256_update function of TinyDTLS has been found. This bug allows remote attackers to cause a denial of service (crash) and possibly read sensitive information via sending a malformed packet with an over-large fragment length field, due to servers incorrectly handling malformed packets.
Here is the bug trace: Program received signal SIGSEGV, Segmentation fault. 0x000055555556134e in dtls_sha256_transform (context=context@entry=0x7fffffffe090, data=0x55555558c002, data@entry=0x55555558bffa) at sha2/sha2.c:494 494 REVERSE32(*data++,W256[j]); (gdb) bt
0 0x000055555556134e in dtls_sha256_transform (context=context@entry=0x7fffffffe090, data=0x55555558c002, data@entry=0x55555558bffa) at sha2/sha2.c:494
1 0x000055555556157f in dtls_sha256_update (len=4849685, data=0x55555558bffa "", context=0x7fffffffe090) at sha2/sha2.c:587 2 dtls_sha256_update (context=0x7fffffffe090, data=, len=) at sha2/sha2.c:553
3 0x000055555555ea72 in dtls_hash_update (len=, input=, ctx=) at dtls-hmac.h:39
4 dtls_hmac_update (ctx=, input=, ilen=) at dtls-hmac.c:60
5 0x00007fffffffe3c0 in ?? ()
6 0x0000000000000023 in ?? ()
7 0x0000000000000000 in ?? ()
Here are captured packets by Wireshark. We could clearly find the reason for causing this bug. After receiving a malformed packet, whose value in the Length field is larger than the real one, servers try to read more bytes than the real one, which leads to disclosing sensitive information and denial of service.