Florian Picca reported a bug in
charon-tkm (the TKM-backed version of the charon IKE daemon) related to handling DH public values that can lead to remote code execution.
Buffer Overflow When Handling DH Public Values
The TKM-backed version of the charon IKE daemon (
charon-tkm) doesn't check the length of received Diffie-Hellman public values before copying them to a fixed-size buffer on the stack, causing a buffer overflow (CWE-121) that could potentially be exploited for remote code execution by sending a specially crafted and unauthenticated IKE_SA_INIT message. Affected are
all strongSwan versions since 5.3.0.
CVE-2023-41913 has been assigned for this vulnerability.
Missing Length Check for DH Public Values in charon-tkm
Before 5.3.0, the length of Diffie-Hellman public values of known DH groups was directly verified by the code that handles KE payloads. This was changed with 0356089d0f94 ("diffie-hellman: Verify public DH values in backends") and 41fc94c92454 ("encoding: Remove DH public value verification from KE payload"), both released with 5.3.0. They made DH
implementations responsible for verifying the public values themselves in their implementation of
key_exchange_t::set_public_key() in newer releases). A helper function was added to simplify this for known DH groups.
Unfortunately, the implementation of that method in
charon-tkm, which acts as proxy for DH operation between the IKE daemon and the Trusted Key Manager (TKM), was forgotten and since then contained an unchecked
memcpy() that copied whatever public DH value the peer sent in its unauthenticated IKE_SA_INIT message to a buffer of 512 bytes on the
stack, potentially causing a buffer overflow. The length is only limited by the maximum length for accepted IKE messages, which defaults to 10'000 bytes.
Remote code execution might be possible due to this issue.
As mentioned in the introduction, credit to Florian Picca at Stackered for finding this vulnerability and reporting it responsibly.
Setups that don't use
charon-tkm as IKE daemon are not vulnerable. Note that the
charon-tkm version that supports multiple key exchanges is not vulnerable either (tkm-multi-ke branch, which will be released with strongSwan 6 in the future).