As Davis said - several things can happen. Hard to predict. For very large octet counts (several thousand digits) rsyslog will very likely segfault.
Thus patch or disable octet counted framing. HTH Rainer El vie, 6 may 2022 a las 3:27, David Lang via rsyslog (<rsyslog@lists.adiscon.com>) escribió: > > 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 <pheerl...@hotmail.com> > > To: rsyslog-users <rsyslog@lists.adiscon.com>, David Lang <da...@lang.hm> > > Cc: John Chivian <jchiv...@chivian.com> > > 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 <rsyslog@lists.adiscon.com> > > Date: 5/5/22 3:26 PM (GMT-05:00) > > To: David Lang <da...@lang.hm> > > Cc: John Chivian <jchiv...@chivian.com>, John Chivian via rsyslog > > <rsyslog@lists.adiscon.com> > > 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 <da...@lang.hm> 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 <rsyslog@lists.adiscon.com> > >>> To: rsyslog-users <rsyslog@lists.adiscon.com> > >>> Cc: John Chivian <jchiv...@chivian.com> > >>> 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 > >>>> <rsyslog@lists.adiscon.com> 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. _______________________________________________ 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.
