OpenSSL HollowByte: A DoS Hiding in 11 Bytes
5 points by refp
5 points by refp
Good lord, does this bug really need a brand name and a thriller subtitle too?
I tend to agree with you, though I'm also somewhat thankful for these "marketable" vuln-titles.
It for sure makes it easier to "casually" talk about a vuln in a conversation, rather than referring to some obscure CVE-XXXX-YYYYY that pretty much always results in "Which one was that again?".
I mean, what rings the strongest bell "heartbleed" or CVE-2014-0160?
On the other hand, research companies flaunting buzzworthy vulns as not only "hey, pay attention" but rather "look at what we can do, hire us!" is both a blessing and a curse.
Let's be honest, though, it's predominantly that other hand. Very few vulns deserve a name, much less need one. No one says the CVE number; you just describe the bug, e.g., "recent Okta OpenSSL DoS".
Perhaps it depends in what field you happen to circle. I for one has been within settings where CVE's are discussed on a daily basis, and in such cases it helps if a "popular" one is just referred to by an alias.
From my experience, if you within a research team are "keeping up to date" and wanna discuss things longer than simply a stand-up, if there's no buzzworthy associated name.. you and your team would just make up an alias, or as you say "the openssl memory exhaustion thing".
But yeah, there are many many CVE's that does not need an alias in that regard, I do agree - but I still have found it helpful in scenarios, that I must be honest with.
Hm, I don't do vulnerability management, but I do security research. In our group, we would never refer to a vulnerability by CVE number nor its PR name. We use a short description s.t. for those that haven't heard of it, they at least get context.
DoS bugs are still bugs, especially if they're solvable, and this one should clearly just be fixed. But more generally, I find that DoS vulnerabilities are usually not necessarily because of a programming mistake but simply a consequence of not even the design of the service, but the requirements of the service. [1] Protection against common DoS vectors tends to mean doing complicated things to degrade service in well-chosen ways (at well-chosen times) that protect... against degraded service?
It may be that I've only hosted simple services, but I typically decide that being robust against DoS is just more trouble than it's worth. Are there DoS protection techniques (of any kind) that do have an effort-to-payoff ratio that is firmly on the payoff side? Apart from shoving Cloudflare in front of a service, I guess.
EDIT: [1]: examples: a pastebin is vulnerable to DoS by filling the disk. Well... yes, it is? Any service that does nontrivial compute on the server is vulnerable to DoS because handling a request is more expensive than sending it. Obviously? "Fixing" these DoS vulnerabilities degrades service, just in different ways than the DoS would have.
I for one thinks this one is getting less attention then it should; if I can deterministically start eating memory of a live service simply by sending a few (ill-intended) bytes to the point of exhaustion.. well, I for one would not wanna wake up to my services being down/sluggish simply due to my services (potentially) happen to rely on openssl.
But hey, most things like this ain't a problem until it becomes a problem.
You're right, and as I said, I do think this issue should be fixed. My comment was admittedly a bit tangential to this thread, and intended to be about DoS vulnerabilities in general. I was hoping to get some pointers from people who know more about this stuff for the next time I implement something that is in principle DoSable but feels almost impossible to defend robustly. :)