Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 565384 - app-admin/rsyslog: Server does not clean TLS contexts on connection loss
Summary: app-admin/rsyslog: Server does not clean TLS contexts on connection loss
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal minor (vote)
Assignee: Gentoo Security
URL: http://www.rsyslog.com/rsyslog-error-...
Whiteboard: B3 [upstream]
Keywords:
Depends on:
Blocks:
 
Reported: 2015-11-10 14:43 UTC by Agostino Sarubbo
Modified: 2017-04-22 08:50 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Agostino Sarubbo gentoo-dev 2015-11-10 14:43:08 UTC
From ${URL} :

If the TCP connections breaks without proper indication, the server side does not seem to clean some context or state. This results in the connection not being re-established after the network comes back, which breaks logging on the client because the log buffers 
run over and Syslog is designed to block in that case. Attacker who is able to break the TLS connection over the untrusted network, can cause DoS on the server for rsyslog service.



@maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
Comment 1 Thomas Deutschmann (RETIRED) gentoo-dev 2016-08-15 16:31:54 UTC
RedHat who reported the problem in the past closed the issue today with the following comment:

> All versions of rsyslog shipped support queuing. Therefore I am closing
> this flaw NOTABUG.


Some background: The bug was filed after a RedHat customer run into a problem where the remote rsyslog instance couldn't be reached and because the customer didn't set up queuing the local system couldn't be use anymore after syslog queued was filled up (normal documented behavior).

It isn't clear if the remote server really recovered but the local rsyslog instance didn't catch up (i.e. did not detect that the remote server became available again to re-establish the connection to drain queue getting back to normal operation). Also nobody really verified if there's a bug within rsyslog network code or GnuTLS which maybe cause such a problem (it isn't that easy to simulate broken TCP).

Again: It is well known and documented that if your rsyslog instance is configured to send its logs to a remote server that you have to configure what to do in cases like that when the remote server isn't reachable anymore. If you don't set up rsyslog properly (i.e. don't allow rsyslog to remove unsent messages when queue become full or don't configure large enough on-disk queue) it is a wanted behavior that rsyslog no longer accept messages therefor anything sending messages to that instance will fail or hang (sshd for example won't allow you to connect anymore if it can't log).


@ Gentoo-Security: I am suggesting to follow RedHat and to close this bug as well.
Comment 2 Thomas Deutschmann (RETIRED) gentoo-dev 2017-04-22 08:50:25 UTC
Not a bug, see comment #1.