A denial-of-service and potential remote code execution vulnerability triggered by crafted IKE messages was discovered in strongSwan. Versions 5.2.2 and 5.3.0 are affected.
An independent researcher privately reported a denial-of-service and possible remote code execution vulnerability in strongSwan. Affected are strongSwan versions 5.2.2 and 5.3.0.
CVE-2015-3991 has been assigned for this vulnerability.
The bug can be triggered by an IKEv1 or IKEv2 message that contains payloads that are only defined for the respective other IKE version. For instance, sending an IKEv1 Main Mode message containing a payload with type 41 (IKEv2 Notify) will crash the daemon when a short summary of the contents of the message is logged ("parsed ID_PROT request 0 [... ]"). Other payload types may trigger crashes in other places.
The message/payload parser in the IKE daemon charon is shared by both IKE versions and payloads for the respective other IKE version initially were fully parsed even if they were later not used. With 5.2.2 we added a check to avoid this so that only payloads valid for the current IKE version are parsed. For invalid payloads an object of type unknown_payload_t is created, which previously was mainly used for IKEv2 to reject messages if the critical bit is set on payloads of unknown type.
Unfortunately, the original numeric type of the payload was retained, so when the daemon worked with received payloads later, such objects could
be treated as objects of the original type, not as instances of unknown_payload_t. In the example above, when the payloads in the message are logged, the type is checked and the generic pointer is casted to the expected type to get more information. In this particular case the unknown_payload_t object with type 41 is casted to a notify_payload_t object, and an attempt is made to call methods defined on that struct, causing a dereference of uninitialized memory, which might lead to remote code execution. Actually, because the unknown_payload_t struct is smaller than some of the structs of other payload types and a pointer to the contents of the original payload (after the generic IKE payload header) is stored in the unknown_payload_t object it is possible that an attacker may even directly control the code that is executed if the offset of the called function happens to align with the pointer to that content. It may also align with pointers in neighboring payloads, which, too, may point to data controlled by an attacker.
Thanks to Javantea for reporting the issue responsibly. He found it using his own IKEv1 fuzzer.
Fix
The just released strongSwan 5.3.1 fixes this vulnerability. For older releases we provide a patch that fixes the vulnerability and should apply with appropriate hunk offsets.