well formatted messages cannot trigger this problem. This problem only happens
if someone sends a message that starts with digits (instead of the <pri> value
that it's supposed to start with), and the number specified by those digits is
checked for exceeding a given size, but the sender can play games (for example,
adding leading zeros) that can overflow the buffer without being too large a
number.
this could happen with badly malformed messages being sent, but not on anything
remotely resembling legitimate syslog messages. (which is how it remained
undetected for so long)
I'm not 100% sure, but if you are getting messages that look like they are octet
counted, it would manifest as corrupt messages, possibly with logs about invalid
octet counting, but possibly not.
Sending messages with octet counting is very rare, so unless you are doing it
deliberatly (usually to send multi-line logs wihtout escaping newlines in them),
just disable it on the receiver and you are safe from both attacks (which this
patch also protects you from) and from corruption caused by malformed messages
that are mistaken as the start of octect counted messages
David Lang
On
Thu, 5 May 2022, Steven D wrote:
Date: Thu, 5 May 2022 23:15:01 +0000
From: Steven D <[email protected]>
To: rsyslog-users <[email protected]>, David Lang <[email protected]>
Cc: John Chivian <[email protected]>
Subject: RE: [rsyslog] rsyslog security vulnerability in versions < 8.2204.1
Is there a way to detect this vulnerability if it's occuring on existing
versions?
Via pstats or rsyslogs behavior?
Does it cause rsyslog to cycle or just the vulnerable input?
Curious if any normal inbound syslog data could inadvertently trigger it?
Regards,
Steven.
-------- Original message --------
From: John Chivian via rsyslog <[email protected]>
Date: 5/5/22 3:26 PM (GMT-05:00)
To: David Lang <[email protected]>
Cc: John Chivian <[email protected]>, John Chivian via rsyslog
<[email protected]>
Subject: Re: [rsyslog] rsyslog security vulnerability in versions < 8.2204.1
Agreed. Unexpected octet counting of rawmsg can also cause other problems. Best
to disable by default.
Thanks all!
On May 5, 2022, at 14:04, David Lang <[email protected]> wrote:
octet counting is an unusual enough use case, I would suggest that distros
consider disabling it by default (for new installs, not changing existng
installs)
David Lang
On Thu, 5 May 2022, John Chivian via rsyslog wrote:
Date: Thu, 5 May 2022 13:31:19 -0500
From: John Chivian via rsyslog <[email protected]>
To: rsyslog-users <[email protected]>
Cc: John Chivian <[email protected]>
Subject: Re: [rsyslog] rsyslog security vulnerability in versions < 8.2204.1
Hello Rainer -
Can you please confirm that the input in the following configuration snippet
is NOT vulnerable…
module(load=“imptcp")
input(
type="imptcp"
name="userdata"
port="5140"
ruleset="userdata_input"
supportoctetcountedframing="no"
)
Thanks,
On May 5, 2022, at 07:11, Rainer Gerhards via rsyslog
<[email protected]> wrote:
Dear List,
there is heap buffer overflow vulnerability in rsyslog tcp reception
components, most notably imtcp and imptcp. This can only happen in
octet-counted mode, which is enabled by default.
If the receiver ports are exposed to the public Internet AND are used
without authentication, this can lead to remote DoS and potentially to
remote code execution. It is unclear if remote code execution is
actually possible. If so, it needs a very sophisticated attack.
When syslog best practices with proper firewalling and authentication
is used, thean attack can only be carried out from within the Intranet
and authorized systems. This limits the severity of the vulnerability
considerably (it would obviously require an attacker already to be
present inside the internal network).
Advisory:
https://github.com/rsyslog/rsyslog/security/advisories/GHSA-ggw7-xr6h-mmr8#advisory-comment-72243
A patch is available, updated packages are already available or will
be within the next few hours. The daily stable will contain the patch
later today.
Credits to Peter Agten for initially reporting the issue and working
with us on the resolution.
Rainer
_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
