Bug 1279514 - rsyslog: Server does not clean TLS contexts on connection loss
rsyslog: Server does not clean TLS contexts on connection loss
Status: CLOSED NOTABUG
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,public=20151109,reported=2...
: Security
Depends On: 1279515 1360350
Blocks: 1279517
  Show dependency treegraph
 
Reported: 2015-11-09 10:51 EST by Adam Mariš
Modified: 2016-08-15 11:00 EDT (History)
17 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-08-15 11:00:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Adam Mariš 2015-11-09 10:51:52 EST
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.
Comment 1 Adam Mariš 2015-11-09 10:52:17 EST
Created rsyslog tracking bugs for this issue:

Affects: fedora-all [bug 1279515]
Comment 2 Adam Mariš 2015-11-30 09:11:07 EST
Original bug report:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804525
Comment 3 Adam Mariš 2015-12-16 06:44:51 EST
This issue occurs when the remote receiver does not complete TCP handshake, acking the CLIENT HELLO but not sending SERVER HELLO back. Socket appears to be established, but in fact it waits for the handshake to complete, blocking all the other logging while queuing for the remote connection.
Comment 6 Cedric Buissart 2016-08-10 08:18:25 EDT
The problem is resolved by having a queue for the forwarding action, allowing to get the network part asynchronous.

E.g. :
$ActionQueueType LinkedList
$ActionQueueFileName forward_to_server
$ActionResumeRetryCount -1
$ActionQueueSaveOnShutdown on
*.* @@<server>:10514 # forward everything to remote server

See https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/s1-working_with_queues_in_rsyslog.html
Comment 7 Cedric Buissart 2016-08-15 10:57:13 EDT
All versions of rsyslog shipped support queuing. Therefore I am closing this flaw NOTABUG.

Note You need to log in before you can comment on or make changes to this bug.