Yesterday, Dave Lewis over at LiquidMatrix Security Digest cried foul at Core Security for releasing too much detail about a recent DoS vulnerability they had discovered. His specific gripe was that they provided an IDA Pro excerpt that showed where the vulnerability was triggered.

Dave asserts that publishing 16 commented assembly instructions makes this disclosure irresponsible. But look at the code — it’s completely generic, just a textbook example of what it looks like when you forget to check a return value after calling operator new. Sure, Core gives you the exact offsets into the executable, but so what? If I have the binary, then it’s not going to be too hard to find the vulnerability anyway. It’s not like Core is giving away a proof-of-concept exploit that generates the malformed registration packet required to trigger the DoS. What’s more, they provide a detailed timeline going back to January 30th of this year describing exactly how the disclosure process with the vendor transpired. This looks extremely responsible to me; I just can’t understand what is “not cool” here.

There’s another interesting angle to this, completely unrelated to Core’s disclosure process. The vulnerability itself is described in the advisory as follows:

Un-authenticated client programs connecting to the service can send a malformed packet that causes a memory allocation operation (a call to new() operator) to fail returning a NULL pointer. Due to a lack of error-checking for the result of the memory allocation operation, the program later tries to use the pointer as a destination for memory copy operation, triggering an access violation error and terminating the service.

This may bring to mind some recent discussions on whether callers of memory allocation functions should check the return value prior to use. To summarize, one camp says “caller should check”, the other camp says “callee should exit on allocation failure.” This is a gross oversimplification and if you want more detailed arguments, read the other blog posts that I linked to. In this case, if the “exit on failure” approach were taken, the DoS scenario might still happen, whereas if the caller were checking, the error could be handled more gracefully. More fuel for the debate!

Very true. After 6+ years working on critical infrastructure I get a little twitchy when I see something like this. Control systems are not easily patched. Trust me. It’s not like applying a patch for Adobe Reader. There is far more involved in addressing an issue like this. Hence my nose being out of joint in the particular instance.

@Tyler (if you are reading this) You have comments turned off on your site so I couldn’t reply to your post. Regarding, “We’ve seen it before and we’ll see it again… but the patch is out, so they aren’t helping the malicious individuals… just the good guys who have time constraints.” The time constraints are significant in the control system space.

—

Oh, and if everyone agreed it would be rather boring no? Thanks for the comments!

to figure out where to start. i highly doubt the assembly would really help someone that was not already otherwise capable of writing the exploit to figure it out.