topic Re: Splunk SSL renegotiation in Deployment Architecture

Splunk SSL renegotiation

mpavlas — Mon, 15 Oct 2012 11:54:21 GMT

I got report from Nessus saying Splunk is vulnerable to CVE-2011-1473 - renegotiation DoS over SSLv3.
How can I fix this?

Re: Splunk SSL renegotiation

beaumaris — Tue, 29 Jan 2013 20:00:28 GMT

I also have found the same vulnerability after running Nessus Security scan. We are running v4.3.4, is there any update to this issue in v5.0?

53491 (1) - SSL / TLS Renegotiation DoS
Synopsis
The remote service allows repeated renegotiation of TLS / SSL connections.
Description
The remote service encrypts traffic using TLS / SSL and permits clients to renegotiate connections. The computational
requirements for renegotiating a connection are asymmetrical between the client and the server, with the server
performing several times more work. Since the remote host does not appear to limit the number of renegotiations
for a single TLS / SSL connection, this permits a client to open several simultaneous connections and repeatedly
renegotiate them, possibly leading to a denial of service condition.
See Also
http://orchilles.com/2011/03/ssl-renegotiation-dos.html
http://www.ietf.org/mail-archive/web/tls/current/msg07553.html
Solution
Contact the vendor for specific patch information.
Risk Factor
Medium
CVSS Base Score
4.3 (CVSS2#AV:N/AC:M/Au:N/C:N/I:N/A:P)
CVSS Temporal Score
3.9 (CVSS2#AV:N/AC:M/Au:N/C:N/I:N/A:P)
References
BID 48626
CVE CVE-2011-1473
XREF OSVDB:73894
Plugin Information:
Publication date: 2011/05/04, Modification date: 2012/10/04
Hosts
10.20.22.140 (tcp/8089)
The remote host is vulnerable to renegotiation DoS over TLSv1 / SSLv3.

Re: Splunk SSL renegotiation

jbsplunk — Thu, 31 Jan 2013 17:57:16 GMT

Openssl doesn't consider this an actual vulnerability which is why it hasn't been fixed in v0.9.8x. It's a way of DoS'ing a server by requesting lots of expensive crypto operations. If you have unfettered access to the REST port you can flood Splunk with plenty of other types of requests that consume just as much CPU.

Any app that allows an operation like SSL negotiation to an untrusted host is subject to resource exhaustion. The correct answer is to restrict hosts if this is an issue.

Note also that if the OS firewall is not enabled, any OS is subject to a DOS through resource exhaustion some how, even if it's just TCP port exhaustion.

This was brought up to Engineering in SPL-58707 and the information provided here serves as an official answer on the topic.