A primitive way of access control is offered in rsyslog via the $AllowedSender configuration directive. It permits the operator to specify hosts from which messages are being accepted. If the directive is not specified, messages from all hosts are accepted. If it is, the set is limited to those senders that match the configured criteria (this can be network addresses or host name). Access control can be configured for UDP- based and TCP-based protocols independently.
Note that this directive may be used to simplify firewall setup, where the firewall permits incoming traffic from all remote machines on the port in question. Then rsyslog ACLs are used to control who is actually permitted. The down-side of this approach is that the packets reach rsyslog and any vulnerability in it can be exploited. Please note that UDP addresses can easily be spoofed (though thankfully not as easy any longer on the public Internet thanks to more careful configuration on most ISP's side). So an IP-based access control does not work very well for UDP (neither at the firewall nor at the rsyslog level - but the firewall may have more options at hand, given its comparatively broad knowledge of the perimeter).
Unfortunately, one vulnerability has been found in rsyslog's ACL handling. Due to a coding error in the modularization effort, the $AllowedSender directive is no longer honored but silently accepted. As such, rsyslog-based access control via $AllowedSender is not working and messages from every sender will be accepted by rsyslog. Most importantly, this could lead to misleading log entries or a remote DoS, by a malicious sender simply flooding the system logs with messages until the system runs out of disk space.
This problem was discovered due to a user bug report early this week and has immediately been addressed. Immediate notice has been sent to the rsyslog mailing list as well as mitigation strategies and patches as they came up.
The versions affected are rsyslog 3.12.1 to 3.20.0, 4.1.0 and 4.1.1. The v2-stable branch is not affected. The vulnerability can be fully mitigated by moving the access control to the firewall level. This is recommended in any case, not just as a mitigation (see reasoning above).
We also have now released fixed version of rsyslog. These are available here:
Users, which use $AllowedSender are urged either to mitigate the issue or update to the appropriate release. Note that rsyslog versions prior to 3.20.0 are no longer officially supported. The proper procedure here is to upgrade to the recent v3-stable branch.
For those interested in the root cause of this issue, please read Rainer's blog post "
root cause of security issue in rsyslog".
