Finding Ticketbleed(blog.filippo.io)
blog.filippo.io
Finding Ticketbleed
https://blog.filippo.io/finding-ticketbleed/
24 comments
This is pretty big. Heartbleed was exactly this but with the heartbeat extension instead of the session ticket extension, and with OpenSSL instead of F5's TLS implementation.
> ... a vulnerability ... of certain F5 products
I.e. this being "big" depends on whether you have "certain F5 products" in your setup.
I.e. this being "big" depends on whether you have "certain F5 products" in your setup.
same with OpenSSL really.
There's a pretty big difference in the amount of memory leaked. Ticketbleed reveals 31 Bytes of uninitialized memory. Heartbleed revealed 64KB.
In the end it doesn't mean that Ticketbleed would reveal a private key more slowly. But since nobody proved that this vuln is exploitable... Heartbleed was proven exploitable thanks to Cloudflare who organized a challenge. (It was also easier to test for exploitability.)
Session tickets are not enabled by default on F5 Big-IP.
Only thing it wonder is why would you 'test' for the bug with only 1 byte of memory leaked? False negatives would be a lot smaller if you reversed it and send a 1-byte session id and have 31 bytes to test.
He says "By picking 31 bytes I ensured the sensitive information leakage would be negligible." but if you don't save/inspect other than verifying it's not 31x0, I don't see the problem?
He says "By picking 31 bytes I ensured the sensitive information leakage would be negligible." but if you don't save/inspect other than verifying it's not 31x0, I don't see the problem?
As I understand it from RFC 5077, when a client sends a session id + session ticket, a conforming server will only ever send back exactly the session id the client sent, or no session id. If the client sends a 31 byte session id, and gets back a 32 byte session id, it knows the server must be sending back some extra data (which may or may not contain any information).
If the first 31 bytes are not the same, then the server is likely generating a new session id, which is a bug but probably not leaking any information.
If the first 31 bytes are the same, then either the server is padding the session id with zeros (which, while buggy, would not be an information leak) or the server is sending back some uncleared memory. These cases could be checked by seeing if the padding is zero (which would have at least a 0.4% false negative rate with just the one byte) but the zgrab test in the article doesn't bother distinguishing them and just assumes any extra data may be an information leak.
EDIT: Re-reading RFC 5077 again, I'm not certain that the server is prohibited from sending back a new session id. If it is allowed to then the second paragraph above doesn't indicate a bug, just a rejection of the session ticket.
If the first 31 bytes are not the same, then the server is likely generating a new session id, which is a bug but probably not leaking any information.
If the first 31 bytes are the same, then either the server is padding the session id with zeros (which, while buggy, would not be an information leak) or the server is sending back some uncleared memory. These cases could be checked by seeing if the padding is zero (which would have at least a 0.4% false negative rate with just the one byte) but the zgrab test in the article doesn't bother distinguishing them and just assumes any extra data may be an information leak.
EDIT: Re-reading RFC 5077 again, I'm not certain that the server is prohibited from sending back a new session id. If it is allowed to then the second paragraph above doesn't indicate a bug, just a rejection of the session ticket.
The session ID isn't encrypted and that means that a passive observer can intercept the test traffic and gain information. Filippo decided to protect against that possibility.
And by so doing, protect himself (as I'm sure you're already aware).
Never underestimate the ability of a company to suddenly invoke the CFAA in the USA (equivalent laws are available elsewhere). IANAL
In this case, I'd like to publicly applaud F5 for being so cool about it. Kudos, F5!
Never underestimate the ability of a company to suddenly invoke the CFAA in the USA (equivalent laws are available elsewhere). IANAL
In this case, I'd like to publicly applaud F5 for being so cool about it. Kudos, F5!
[deleted]
good research ethic + avoiding leaking information to passive man-in-the-middles.
How much fallout will F5 really see from this bug though?
Little to none, but I think this story was actually genuinely cool to read for some reason. I still can't put my finger on it.
I found it cool also and ultimately I'm Filippo's boss. The fun part is that he found this by accident while debugging a customer problem and he worked quietly with F5 to disclose (so quietly I found out about this a couple of days ago).
Also Filippo does a good job of telling the story in his blog post. I don't get the "fallout for F5" part. A bug was found, a vendor informed, everyone worked together in a responsible manner. Happiness!
Also Filippo does a good job of telling the story in his blog post. I don't get the "fallout for F5" part. A bug was found, a vendor informed, everyone worked together in a responsible manner. Happiness!
It's a story about competent people handling a bug responsibly. Nothing sensational, but deeply satisfying nonetheless.
It's straightforward, it's not trying to shill Cloudflare products too much, it's not self-congratulatory, and it's told from the chronological first-person perspective of an engineer trying to debug a protocol issue and accidentally uncovering a critical vuln.
Basically, it wasn't written by a marketing department like most of these other company-found vuln disclosures.
Basically, it wasn't written by a marketing department like most of these other company-found vuln disclosures.
Probably none. Especially when you see mentioned in the article that chromium makes sure their ClientHello is not in the 256-512b range to avoid breaking F5 servers. https://bugs.chromium.org/p/chromium/issues/detail?id=315828
The cause of that particular bug was that a ClientHello in that size range looked like a SSL2 (!) handshake, and these boxes were looking for a SSL2 handshake before looking for a SSL3 handshake: https://www.ietf.org/mail-archive/web/tls/current/msg10423.h...
Interestingly, this new "ticketbleed" vulnerability could completely erradicate that bug, in the quite probable case that all versions of the F5 software which fix ticketbleed also have the much older fix for that ClientHello bug.
Interestingly, this new "ticketbleed" vulnerability could completely erradicate that bug, in the quite probable case that all versions of the F5 software which fix ticketbleed also have the much older fix for that ClientHello bug.
The SSL2 issue was fixed in 11.2.1 HF11 and 11.4.0, so it should be long fixed in all supported versions at this point.
Maybe I'm missing something, but I don't see how these issues are related. One is a compatibility workaround, the other is a vulnerability that exposes server memory to a remote attacker.
F5's poor coding practices are the common denominator.