ktsdesign - Fotolia

Ticketbleed flaw: How can SSL session identities be protected?

The Ticketbleed flaw in F5 Networks' BIG-IP appliances leaks uninitialized memory and SSL session identities. Expert Michael Cobb explains how enterprises can mitigate it.

A Cloudflare Inc. engineer discovered a Ticketbleed flaw in F5 Networks' BIG-IP appliances that causes the virtual servers to leak uninitialized memory and SSL session identities. How can attackers use this information, and what can enterprises do to mitigate this vulnerability?

A buffer overread flaw that undermines the security of encrypted connections in F5 Networks' BIG-IP SSL appliances was discovered by Cloudflare engineer Filippo Valsorda. Like all serious vulnerabilities, it has a name -- Ticketbleed, tracked as CVE-2016-9244 -- and its own website. It affects 10 F5 products, where the virtual servers running on them have nondefault session tickets enabled in the client SSL profile.

A session ticket is used to speed up repeated connections over transport layer security (TLS). It contains some encrypted key material from the previous session to enable the server to resume that session immediately, instead of negotiating a new one. The default setting in the client SSL profile is to not use SSL session tickets, but many administrators override this as they improve performance.

According to RFC 5077, "TLS Session Resumption without Server-Side State," when a client presents a ticket, it may generate and include a session ID in the TLS ClientHello. If the server accepts the ticket and the session ID is not empty, then it must respond with the same session ID present in the ClientHello to signal acceptance of the ticket.

Session IDs can be anywhere between one and 31 bytes in length, but the F5 stack always echoes back 32 bytes of memory, even if the session ID is shorter. This is extremely poor coding practice; it could have been a genuine error, but was most likely deemed too much of a performance hit to initialize the right size block of memory.

This flaw in the code means that, if an attacker sends a 1-byte session ID, the server sends back an additional 31 bytes of whatever unallocated memory was in the extra bytes, creating a situation where a remote attacker could obtain TLS session IDs from other sessions by stringing together enough requests. Other sensitive data from uninitialized memory could also be returned.

The Heartbleed flaw exposed 64 kilobytes of data at a time, so it would take more requests to carry out an attack using Ticketbleed; even so, it is regarded as a serious vulnerability.

Ticketbleed has some similarities to the Heartbleed vulnerability, but the user base affected is a lot smaller. Heartbleed was present in the OpenSSL cryptographic software library used by the majority of web servers, putting the entire internet at risk, whereas Ticketbleed is only present in F5 Networks' propriety TLS stack.

It's unclear exactly what data might be exfiltrated via Ticketbleed, but Heartbleed showed that uninitialized memory can lead to complete compromise. Heartbleed leaked memory contents from the server to the client and from the client to the server, leaving private keys and protected content exposed to the internet.

Enterprises that use BIG-IP virtual servers can completely mitigate this vulnerability by disabling session tickets on the affected client SSL profile using the configuration utility to clear the Session Ticket check box. F5 Networks includes a list of vulnerable versions in its K05121675 security advisory. This will cause minor performance degradation in the setup phase of resumed connections, so the preferred mitigation option is to upgrade to a nonvulnerable version where possible.

The Ticketbleed website can test whether a publicly accessible server is vulnerable or not. System administrators should subscribe to F5 Networks' email notifications regarding its products to stay abreast of updates and patches.

Next Steps

Find out why so many internet-connect services remain vulnerable to the Heartbleed flaw

Learn how to overcome SSL security vulnerabilities

Read how enterprises can regain control over SSH key management

This was last published in July 2017

Dig Deeper on Application and platform security