Mailing List Archive

rsyslog security vulnerability in versions < 8.2204.1
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.
Re: rsyslog security vulnerability in versions < 8.2204.1 [ In reply to ]
The rsyslog binary packages hosted on SuSe OBS are now updated.

Rainer

El jue, 5 may 2022 a las 14:11, Rainer Gerhards
(<rgerhards@hq.adiscon.com>) escribió:
>
> 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.
Re: rsyslog security vulnerability in versions < 8.2204.1 [ In reply to ]
RHEL/CentOS packages as well as Ubuntu Launchpad packages are also now updated.

Florian

Am Do., 5. Mai 2022 um 15:12 Uhr schrieb Rainer Gerhards via rsyslog
<rsyslog@lists.adiscon.com>:
>
> The rsyslog binary packages hosted on SuSe OBS are now updated.
>
> Rainer
>
> El jue, 5 may 2022 a las 14:11, Rainer Gerhards
> (<rgerhards@hq.adiscon.com>) escribió:
> >
> > 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.
Re: rsyslog security vulnerability in versions < 8.2204.1 [ In reply to ]
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.
Re: rsyslog security vulnerability in versions < 8.2204.1 [ In reply to ]
Correct. Not vulnerable.

Rainer

John Chivian <jchivian@chivian.com> schrieb am Do., 5. Mai 2022, 20:31:

> 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.
Re: rsyslog security vulnerability in versions < 8.2204.1 [ In reply to ]
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 <jchivian@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.
Re: rsyslog security vulnerability in versions < 8.2204.1 [ In reply to ]
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 <david@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 <jchivian@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.
Re: rsyslog security vulnerability in versions < 8.2204.1 [ In reply to ]
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 <david@lang.hm>
Cc: John Chivian <jchivian@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 <david@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 <jchivian@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.
Re: rsyslog security vulnerability in versions < 8.2204.1 [ In reply to ]
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 <pheerless@hotmail.com>
> To: rsyslog-users <rsyslog@lists.adiscon.com>, David Lang <david@lang.hm>
> Cc: John Chivian <jchivian@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 <david@lang.hm>
> Cc: John Chivian <jchivian@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 <david@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 <jchivian@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.
Re: rsyslog security vulnerability in versions < 8.2204.1 [ In reply to ]
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 <pheerless@hotmail.com>
> > To: rsyslog-users <rsyslog@lists.adiscon.com>, David Lang <david@lang.hm>
> > Cc: John Chivian <jchivian@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 <david@lang.hm>
> > Cc: John Chivian <jchivian@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 <david@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 <jchivian@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.