Impact
Modules for TCP syslog reception have a heap buffer overflow when octet-counted framing is used. The attacker can corrupt heap values, leading to data integrity issues and availability impact. Remote code execution is unlikely to happen but not impossible.
Affected modules
imtcpimptcpimhttp (contributed module)imgssapi (long-term semi-contributed module)imdiag
Details
The bug occurs when the octet count is read. While there is a check for the maximum number of octets, digits are written to a heap buffer even when the octet count is over the maximum, This can be used to overrun the memory buffer. This can also be used to corrupt other heap buffers. Once the sequence of digits stop, no additional characters can be added to the buffer. In our opinion, this makes remote exploits impossible or at least highly complex.
Octet-counted framing is one of two potential framing modes. It is relatively uncommon, but enabled by default on receivers.
Modules imtcp, imptcp, imgssapi, and imhttp are used for regular syslog message reception. It is best practice not to directly expose them to the public. When this practice is followed, the risk is considerably lower.
Module imdiag is a diagnostics module primarily intended for testbench runs. We do not expect it to be present on any production installation.
Patches
The patch is available via commit ID [PUT HERE].
Workarounds
Octet-counted framing is not very common. Usually, it needs to be specifically enabled at senders. If users do not need it, they can turn it off for the most important modules. This will mitigate the vulnerability. How to do this depends on the module:
Note that while octet-counted framing can be disabled sending systems have to explicitly enable it, but by default receiving systems autodetect if it's in use. The 'normal' reason to enable it is if you are sending logs with embedded newlines.
For more information
If you have any questions or comments about this advisory:
Pagten Analyst
Impact
Modules for TCP syslog reception have a heap buffer overflow when octet-counted framing is used. The attacker can corrupt heap values, leading to data integrity issues and availability impact. Remote code execution is unlikely to happen but not impossible.
Affected modules
imtcpimptcpimhttp(contributed module)imgssapi(long-term semi-contributed module)imdiagDetails
The bug occurs when the octet count is read. While there is a check for the maximum number of octets, digits are written to a heap buffer even when the octet count is over the maximum, This can be used to overrun the memory buffer. This can also be used to corrupt other heap buffers. Once the sequence of digits stop, no additional characters can be added to the buffer. In our opinion, this makes remote exploits impossible or at least highly complex.
Octet-counted framing is one of two potential framing modes. It is relatively uncommon, but enabled by default on receivers.
Modules
imtcp,imptcp,imgssapi, andimhttpare used for regular syslog message reception. It is best practice not to directly expose them to the public. When this practice is followed, the risk is considerably lower.Module
imdiagis a diagnostics module primarily intended for testbench runs. We do not expect it to be present on any production installation.Patches
The patch is available via commit ID [PUT HERE].
Workarounds
Octet-counted framing is not very common. Usually, it needs to be specifically enabled at senders. If users do not need it, they can turn it off for the most important modules. This will mitigate the vulnerability. How to do this depends on the module:
imtcp.imptcp, addSupportOctetCountedFraming="off"to theinput()definition.Docs: https://www.rsyslog.com/doc/v8-stable/configuration/modules/imtcp.html, https://www.rsyslog.com/doc/v8-stable/configuration/modules/imptcp.html, https://www.rsyslog.com/doc/v8-stable/configuration/modules/imhttp.html
imgssapioctet.-counted framing cannot be turned off.imdiagoctect-counted framing cannot be turned off. However,imdiagshould never be present on production systems.Note that while octet-counted framing can be disabled sending systems have to explicitly enable it, but by default receiving systems autodetect if it's in use. The 'normal' reason to enable it is if you are sending logs with embedded newlines.
For more information
If you have any questions or comments about this advisory: