Ticketbleed: The next black swan
Ticketbleed is a software vulnerability in a feature of the TLS/SSL stack that allows a remote attacker to extract sensitive information.
Last week a researcher disclosed a software vulnerability in a feature of the TLS/SSL stack that allowed a remote attacker to extract sensitive information. Sound familiar? In 2014, the Heartbleed vulnerability in the OpenSSL implementation of the heartbeat function in SSL affected some 600,000 websites worldwide and risked exposing passwords and other private keys. Ticketbleed, announced last Wednesday, has some similarity, but at the end of the day, it’s no Heartbleed.
Software vulnerabilities really should not be surprising. But the big events are becoming as rare as black swans. So why are we still focusing on the next big event?
Ticketbleed
Researcher Filippo Valsorda, from Cloudflare, coined the name Ticketbleed, which refers to the information leakage vulnerability in the implementation of a session ticket within TLS/SSL. Valsorda said he was resolving a bug report from a Cloudflare customer who was using a F5 webserver product when he first noticed an incompatibility between the Cloudflare TLS stack and the F5 one.
“When a client supplies a Session ID together with a Session Ticket,” Valsorda explained in a blog,”the server is supposed to echo back the Session ID to signal acceptance of the ticket. Session IDs can be anywhere between 1 and 31 bytes in length. The F5 stack always echoes back 32 bytes of memory, even if the Session ID was shorter. An attacker providing a 1-byte Session ID would then receive 31 bytes of uninitialized memory.”
Heartbleed
Heartbleed refers to the information leakage vulnerability that lies in the implementation of the heartbeat feature within OpenSSL. It was discovered while testing TLS protocol which contains the heartbeat functionality. It was co-discovered by a team from Codenomicon (now Synopsys) along with Neel Mehta of Google’s security team.
According to Rauli Kaksonen, Global Director with Synopsys, the Defensics team was looking through fuzz test results when it noticed the difference between the responses for this particular test case. “We were looking at the logs and realized that OpenSSL is responding with more content than it should,” he said. “So it was a manual verification after the automation that found the basic symptom.”
Differences between Ticketbleed and Heartbleed
- Ticketbleed can only siphon data at 1 byte per session vs the more than 64 kilobytes obtained through Heartbleed). With Ticketbleed, an attacker would need several rounds of 1 byte data before it becomes significant. With Heartbleed, you could get several kilobytes of sensitive data in one shot.
- The Ticketbleed vulnerability is limited to certain F5 products using the BIG-IP SSL virtual server. Heartbleed affected open source software found on more than 600,000 IP addresses across the internet.
- Like Heartbleed, the Ticketbleed vulnerability is not in the original RFP for TLS/SSL but in the F5 implementation. Heartbleed wasn’t in SSL, only its implementation of OpenSSL. This speaks to supply chain, that when you procure a new piece of software–even firmware in a device–you should always test its composition for vulnerabilities.
The software industry is maturing
The lack of significant new software vulnerabilities does suggest a growing maturity in the software industry. The most egregious coding errors are being caught early in the software development life cycle. Even diverse industries such as automotive and medical are starting to recognize the need for secure coding standards.
While this is good news, there are some troubling aspects to having fewer big software vulnerabilities as well.
Out of sight, out of mind
The lack of big profile vulnerabilities can lull organizations into a state of complacency. If we’re not at a risk today, then why spend the effort? The software threat landscape becomes background noise. That doesn’t mean the threats go away, only that they are internally demoted. “If no one complains, why should we mitigate this?”
There’s also the issue of coordinated disclosure. Some organizations resist going public with a software flaw, particularly when the vendor lacks a security team to work with the researcher. As a result, some researchers have gone public themselves. This is not productive. Having coordinated disclosure is best for all. And some vulnerabilities are simply not reported but quietly patched by the vendors themselves. This too is counterproductive in that we stand to learn from each vulnerability.
Misprioritization
Finally, the fact Ticketbleed has a logo and a website might seem significant. It’s not. Last year, a team at SerNet announced what could have been a major flaw in Samba implementations on Windows. Coined “Badlock” and given a logo, it fell markedly short in terms of being a severe vulnerability. The Badlock team did go on to win a Pwnie Award for Most Over-hyped Bug. At least Ticketbleed is worth consideration.
When Heartbleed was named, it was out of the need to get people over 600,000 IP addresses, most in the finance and e-commerce verticals, to talk about OpenSSL vulnerability CVE-2014-0160. People were not going to say “CVE-2014-0160” over and over. A name, in this case, was appropriate.
Plenty of work ahead
Our continuing efforts to end all coding flaws to some degree will be asymptotic, never reaching 100%. But the effort will always be worth every penny we spend toward that goal in quality and safety. What’s important that every organization have a secure software initiative that continually assesses new threats and vulnerabilities as it concerns that organization.
There are thousands of Common Vulnerability Enumerations (CVE) in the National Vulnerability Database, with more disclosed every day. The question isn’t which one got the most press, or had a best logo. The question is which one affects you the most. If you can’t answer that question, then you have your answer on where to begin.
