A denial-of-service vulnerability in the stroke plugin was discovered in strongSwan. All versions are affected in certain configurations.
An independent researcher found a bug in the stroke plugin that may lead to a denial-of-service attack or even local code execution.
In the default configuration root privileges are required to trigger the vulnerability so this should generally not be an issue. However, all versions are potentially affected.
The stroke plugin did not verify the message length read from its socket before allocating memory and reading the message. Unless a group is configured, root privileges are required to access that socket, so in the default configuration this is not an issue.
CVE-2018-5388 has been assigned for this vulnerability.
Messages sent via stroke are basically C structs. The first member is the two byte length of the complete message. So the stroke plugin first reads those two bytes, allocates memory, and then reads the rest of the message. Unfortunately, it did not enforce a minimum value for the read length, so it could be shorter than the stroke_msg_t struct. This may result in a crash when the plugin tries to access struct members that point to memory that's not actually part of the allocated buffer.
Before 5.1.0, MSG_PEEK was used to peek the message length and the complete message was read later. With 5.1.0 this was changed and since then there is additionally an integer underflow if the supplied message length is 0 or 1 (the 2 bytes already read are subtracted from the read message length) resulting in a huge length passed to recv() (the length is passed as size_t).
This is technically a heap buffer overflow (the allocated buffer has a size of 1 or 2 bytes, the data is written after it) so the possibility of local code execution with the goal of privilege escalation can't be ruled out.
It's important to note that writing data to the stroke plugin's socket requires root privileges in the default configuration.
Only if a group is configured are users who are a member of that group then able to write data to the socket and crash the daemon via this vulnerability (however, they could also just terminate all SAs in a loop to achieve a DoS).
The just released strongSwan 5.6.3 fixes this vulnerability. For older releases we provide patches that fix the vulnerability in the respective versions and should apply with appropriate hunk offsets (please note that patches for versions < 4.4.0 are not provided).