CVE-2011-1473: Medium severity openssl vulnerability

Published Mar 13, 2011
·
Updated

DISPUTED OpenSSL before 0.9.8l, and 0.9.8m through 1.x, does not properly restrict client-initiated renegotiation within the SSL and TLS protocols, which might make it easier for remote attackers to cause a denial of service (CPU consumption) by performing many renegotiations within a single connection, a different vulnerability than CVE-2011-5094. NOTE: it can also be argued that it is the responsibility of server deployments, not a security library, to prevent or limit renegotiation when it is inappropriate within a specific environment.

Other sources

It was reported [1] that a flaw exists in how openSSL handles SSL renegotiation. Because of the processing power required to handle an SSL/TLS handshake, with renegotiation enabled, a user can send multiple handshakes per second due to the renegotiation request being permitted. This could allow a malicious user to send multiple renegotiation requests and exhaust server resources.

Note that this is not the only way to cause a denial of service on an SSL-enabled service; there are many other ways to accomplish the same thing, this just makes it easier.

What makes this bug even more confusing is that this report is recent, with a 2011 CVE, however the recommended fix in the report is to upgrade to OpenSSL 0.9.8l, which is what disabled renegotiation, however it was subsequently re-enabled when OpenSSL added support for RFC5746 in OpenSSL 0.9.8m (which the reporter seems to imply isn't sufficient). I'm not sure where the CVE assignment came from; on MITRE's site is is reserved yet and I have not seen this discussed anywhere else but in a Nessus scan report [2].

As an aside, and to reference something we may need to look at, there seems to be some concern with Apache and how it works with SSL renegotiation disabled [3], so we will need to look into cases where disabling SSL renegotiation may impact expected behaviour of currently released products.

[1] http://orchilles.com/2011/03/ssl-renegotiation-dos.html [2] https://discussions.nessus.org/message/10629 [3] http://old.nabble.com/TLS-renegotiation-disabling-%3A-modssl-and-OpenSSL--0.9.8l-td26285568.html

Red Hat

Affected Software

13 affected components
OpenSSL OpenSSL=0.9.8m
OpenSSL OpenSSL=0.9.8n
OpenSSL OpenSSL=0.9.8p
OpenSSL OpenSSL=0.9.8u
OpenSSL OpenSSL=0.9.8m-beta1
OpenSSL OpenSSL=0.9.8s
OpenSSL OpenSSL=0.9.8r
OpenSSL OpenSSL=0.9.8t
OpenSSL OpenSSL=0.9.8o
OpenSSL OpenSSL=0.9.8w
OpenSSL OpenSSL=0.9.8v
OpenSSL OpenSSL=0.9.8x
OpenSSL OpenSSL<=0.9.8k

Event History

Mar 13, 2011
CVE Published
12:00 AM
Data Sourced
12:00 AM
RemedyDescriptionSeverity
May 23, 2011
Data Sourced
via Red Hat·09:01 PM
DescriptionSeverityAffected Software
Jun 16, 2012
CVE Published
via MITRE·09:00 PM
Data Sourced
via MITRE·09:00 PM
Description
Disputed
09:55 PM

Frequently Asked Questions

1

What is the severity of CVE-2011-1473?

CVE-2011-1473 has a designation that indicates a denial of service vulnerability potentially affecting server performance.

2

How do I fix CVE-2011-1473?

To mitigate CVE-2011-1473, upgrade OpenSSL to a version that is newer than 0.9.8l.

3

What systems are affected by CVE-2011-1473?

CVE-2011-1473 affects multiple versions of OpenSSL including 0.9.8k and earlier versions.

4

Can CVE-2011-1473 be exploited remotely?

Yes, CVE-2011-1473 can be exploited remotely, allowing attackers to initiate numerous renegotiations.

5

What are the consequences of an exploit of CVE-2011-1473?

Exploiting CVE-2011-1473 may lead to denial of service through excessive CPU consumption due to continuous renegotiations.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203