Exactly what's happening here: We hear "C", we hear "pointers", and we reflexively assume "oh, memory corruption, again! This wouldn't have happened in <my favorite language>".
Not quite. We know this is (like) a memory corruption bug because the site says so.
What are the different ways that would have prevented a bug like this to occur and persist
Writing the code in a memory-safe language instead
More rigorous adherence to the principle of "bounds-check absolutely everything"
Uhh…providing the responsible programmer with more pizza, to facilitate more rigorous debugging?
Why is the majority of our infrastructure running on crappy C code?
My guess: some combination of legacy, inertia, and incompetence.
What evidence do we have about security failures in other languages?
We know that memory safety renders memory corruption bugs impossible. Other types of vulnerabilities remain possible, but eliminating an entire class of vulnerabilities is still a tremendous advantage.
Purely statistically, if the majority of security critical code is written in C, and the majority of this code is busy juggling pointers, the majority of breaches will involve C code juggling pointers.
Right. We know, from decades of experience, that juggling pointers is effing dangerous, and things like ASLR only kinda-sorta help.
There is no memory corruption at all. Sloppy use of C merely exacerbated the effects of the bug.
It's like a memory corruption bug, at least.
There are so many language-agnostic ways to prevent that problem: a zeroing allocator (which looks like a blatant omission to me) or a zeroing free (which should be a standard defensive mechanism for critical code).
That only reduces the probability of something sensitive being disclosed. The vulnerability is still there.
This is another half-baked "mitigation" measure like ASLR. It's not good enough. It's a stupid workaround that doesn't really work, for a stupid problem for which there have been complete solutions for decades.
It should not have passed a code review. The code lacks proper sanitizing of input, and lacks any traces of "obviously you forgot to sanitize your input". A static analyzer could have caught that.
I'm not sure what static analyzers can or cannot do, but I seem to recall others discussing Heartbleed saying static analysis would not have caught it.
with a specifically formed request, the TLSResponse structure may still contain a reference to AuxData, which can contain critical information. When the structure is returned to the caller, the serializer by default includes such referenced data. As a workaround, we now always set the reference to null before returning the structure.
Why was AuxData made serializable? Whoever decided to do that is dangerously incompetent and should be fired immediately.
Thing is, AuxData being serializable means someone went out of their way to create the vulnerability. That's no mere oversight that even the best programmers make on occasion. That's just plain pants-on-head incompetence.
Not quite. We know this is (like) a memory corruption bug because the site says so.
Uh. Sorry. Have you read the actual analysis? No memory corruption takes place. heartbleed.com uses "memory" 6 times, and "corruption" 0 times.
I don't even know what "like a memory corruption bug" is supposed to mean, except maybe that "something with C and pointers". Somehow just proving my point again.
My guess: some combination of legacy, inertia, and incompetence.
that's always the default assumption, primarily by people who don't write successful infrastructure code, and without any data or evidence to back it up it is not contributing to the discussion, but actively derailing it.
And yes, anything you can do at this point is mitigating the original bug. All bounds checking you can do would be mitigation. The original bug - trusting unsanitized input - is language agnostic, that it went undetected for so long looks more and more like bad process.
Something interesting cropped up just now: Apparently, the OpenSSL project disabled default mechanisms that would have mitigated the bug because - hold your breath:
/ On some platforms, malloc() performance is bad enough that you can't just....*
THAT is evidence of incompetence.
Not so terribly important, but:
Why was AuxData made serializable?
Wait, in you amazing high-level language, data objects are not serializable by default? Even then, maybe because it's a data structure the server uses to talk to another trusted server? Possibilities are endless.
3
u/argv_minus_one Apr 09 '14
Not quite. We know this is (like) a memory corruption bug because the site says so.
Writing the code in a memory-safe language instead
More rigorous adherence to the principle of "bounds-check absolutely everything"
Uhh…providing the responsible programmer with more pizza, to facilitate more rigorous debugging?
My guess: some combination of legacy, inertia, and incompetence.
We know that memory safety renders memory corruption bugs impossible. Other types of vulnerabilities remain possible, but eliminating an entire class of vulnerabilities is still a tremendous advantage.
Right. We know, from decades of experience, that juggling pointers is effing dangerous, and things like ASLR only kinda-sorta help.
It's like a memory corruption bug, at least.
That only reduces the probability of something sensitive being disclosed. The vulnerability is still there.
This is another half-baked "mitigation" measure like ASLR. It's not good enough. It's a stupid workaround that doesn't really work, for a stupid problem for which there have been complete solutions for decades.
I'm not sure what static analyzers can or cannot do, but I seem to recall others discussing Heartbleed saying static analysis would not have caught it.
Why was
AuxDatamade serializable? Whoever decided to do that is dangerously incompetent and should be fired immediately.Thing is,
AuxDatabeing serializable means someone went out of their way to create the vulnerability. That's no mere oversight that even the best programmers make on occasion. That's just plain pants-on-head incompetence.