|
Message-ID: <CADk+mPB6u97n6EsXZtmUXKn1kXaH7xtSUz3vo3Q4FoOv-RF9UQ@mail.gmail.com> Date: Thu, 5 May 2022 14:10:43 +0200 From: Rainer Gerhards <rgerhards@...adiscon.com> To: oss-security@...ts.openwall.com Subject: CVE-2022-24903: rsyslog < 8.2204.1 heap buffer overrun Severity: High | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H This is a worst case rating. When syslog best practices are applied (no Internet access to rsyslog receivers) the severity is lower. Details below. Advisory: https://github.com/rsyslog/rsyslog/security/advisories/GHSA-ggw7-xr6h-mmr8#advisory-comment-72243 Advisory content: ### 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 * `imtcp` * `imptcp` * `imhttp` (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: * For `imtcp`. `imptcp`, add `SupportOctetCountedFraming="off"` to the `input()` 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 * For `imgssapi`octet.-counted framing cannot be turned off. * For `imdiag` octect-counted framing cannot be turned off. However, `imdiag` should 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: * Open an issue in [rsyslog repo](http://github.com/rsyslog) * Post to the [rsyslog mailing list](https://lists.adiscon.net/mailman/listinfo/rsyslog) Credits to Peter Agten for initially reporting the issue and working with us on the resolution. Rainer Gerhards
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.