Core Security, makers of the product Core Impact.
Nice folks.
I like the product.
Apparently they left the gate open and their brains ran away in the night. What am I talking about? Well, they posted a vulnerability in the software of SCADA vendor Wonderware.
From their posting:
A vulnerability was found in Wonderware SuiteLink Service (slssvc.exe) that could allow an un-authenticated remote attacker with the ability to connect to the SuiteLink service TCP port to shutdown the service abnormally by sending a malformed packet. Exploitation of the vulnerability for remote code execution has not been proven, but it has not been eliminated as a potential scenario.
Fine. Good catch. I have been lucky enough to work with 10+ vendors so far on security vulnerabilities including one donkey outfit in ’07. But, the rest were all professional. I was patient as I waited for them to get their **** together.
Now, on the SCADA side of the line we have another world that would make the Mad Hatter quite perplexed. There are some EMS vendors that require you speak to them slowly as more than several sentences per minute and they might, regrettably, spontaneously combust. It would appear, based on their apparent time line that WW is potentially one such firm.
That, however, doesn’t merit this,
An attacker can trigger the memory allocation operation failure by specifying an abnormally large length field in a Registration packet. The following binary excerpt shows where the problem is:
And here they provide the binary analysis.
They left the tracks at this point. I have released several vulnerabilities to date and not once did I release the actual code for the specific problem. What would that accomplish? I gave them the opportunity to patch the problem. They were able to address the issue with their respective customers and I got the byline.
Again from their time line,
Core has learned over the course of 13 years working in this particular field that it is fundamental to provide precise and accurate technical information about problems.
But, releasing the actual binary analysis? Let go of my leg.
Not cool. So much for responsible disclosure.
Thx to CJ, M, Darko, Melanie and Bob for sending this one in!
(ed note: I do enjoy stirring it up. Looks like this one did the trick.)
honestly anyone that can write an exploit probably just needs:
‘An attacker can trigger the memory allocation operation failure by specifying an abnormally large length field in a Registration packet”
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.
@CG
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!
For another point of view on this topic, Chris Eng of Veracode weighs in here:
http://www.veracode.com/blog/?p=97
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!