rsyslog imdtls permitted-peer authorization bypass
rsyslog's imdtls module keeps DTLS sessions active when permitted-peer checks fail after a successful handshake.
Rainer Gerhards reported that rsyslog's optional imdtls input module does not enforce tls.permittedpeer after a CA-authenticated DTLS handshake when tls.authmode is "name" or "fingerprint". After SSL_accept() succeeds, a failed permitted-peer identity check only logs a warning and leaves the DTLS session active, so records continue to be read and received. The disclosure cites no CVE and does not say the flaw is being exploited.
- Optional imdtls fails to enforce tls.permittedpeer after a successful DTLS handshake.
- Affects tls.authmode set to name or fingerprint.
- A failed identity check logs a warning but leaves the session active.
- The report names no CVE and does not claim exploitation.
Posted by Rainer Gerhards on Sep 22 Hello, The optional rsyslog imdtls input module did not enforce tls.permittedpeer after a successful CA-authenticated DTLS handshake when configured with tls.authmode="name" or tls.authmode="fingerprint". After SSL_accept() succeeds, imdtls performs the permitted-peer identity check. When that check fails, the module logged a warning but left the DTLS session active. The session was subsequently read and received records...
This source does not provide full text. Read it at seclists.org.