AAA  AAA 

US-CERT Livedata ICCP Vulnerability Note

US-CERT released Vulnerability Note VU#190617: LiveData ICCP Server heap buffer overflow today after a number of months of “vendor coordination.”

I won’t go beyond the technical details in the VU, but to recap the highlights:

  • This is a protocol implementation flaw in RFC 1006, not in the inherent security of the protocol, ICCP or RFC 1006.
  • A remote unauthenticated attacker can crash the ICCP server by sending malformed messages.
  • This particular problem only impacts the LiveData server. However the LiveData server is resold by a number of other vendors including Invensys, Telvent, S&C, and several others.
  • A fix is available, and has been for quite some time.
  • This issue will appear in the NIST National Vulnerability Database as CVE-2006-0059
  • Digital Bond reported the issue to US-CERT after notifying LiveData.

Not mentioned in the vulnerability note:

  • Another ICCP server bug was announced by Sisco in February 2005.
  • Our ICCP Signatures might be helpful in detecting malicious activity directed against ICCP servers that could trigger this vulnerability, although the signatures probably aren’t terribly useful for coming up with an exploit.
  • There is no mention of this issue on the LiveData support site although there are several post-fix maintenance releases.

After biting my tongue and sticking to the facts, now for some commentary…

To our knowledge, this is the first SCADA security vulnerability that has gone through the disclosure process established by US-CERT (with the assistance of CERT/CC who did the bulk of the time-consuming, tedious vendor coordination work) for control systems vulnerabilities.

This demonstrates that coordination centers (or at least CERT/CC) are capable of handling a products and protocols outside their comfort (or experience) zone. They took action. Whether it was the right action might be up for debate, but they did not lose or sit on the bug–which can happen. I know this from personal experience.

As the bug finders, I think we were quite restrained. We did not push the process. As a result the process took a little longer than it probably could have, but was still within the mean timelines of IT vulnerabilities.

We waited 6-8 weeks to report the issue to US-CERT after notifying the vendor. The time to fix (from report to the vendor) was between 3-6 months and the release of the advisory was between 6-9 months after we initially notified the vendor.

I wouldn’t wanto to generalize, but to the uninitiated, the “utility stack” is quite complex. Complexity leads to coding errors, so “stay tuned.”

While Windows patching “steals the show” there are some number of ICCP (and other SCADA/EMS application servers that use proprietary protocols) out there with “issues.” SCADA admins, check with your SCADA/EMS vendor. Patching isn’t just a Windows issue.

Finally, one of the biggest takeaways for me, is the that you think if find one humble flaw in a single product, but that may not be the case. Many other vendors resell LiveData’s ICCP server.
Unfortunately, if you check the list of impacted vendors, there are more questions than answers. In fact, 9 of the 11 vendors listed did not provide any information on whether or not they were affected. If these vendors don’t know (or won’t say), how will end-users know?

As we’ve said before, this topic (and some other sanitized details on other SCADA vulns we have “in the pipe”) will be a topic of (hopefully) intense debate and discussion at the upcoming Spring PCSF Meeting in San Diego.

BTW, we’d love to get some feedback on this issue. End of the world? You are arming the terrorists? A lot of hot air about nothing?

Author: Matt Franz
Posted: May 16th, 2006 under ICCP, Vulnerability Disclosure.
Comments: 3

Comments

Comment from Tim Anderson
Time: May 18, 2006, 10:05 am

ICCP vulnerabilities could pose a big risk to SCADA systems. In the implementations that I have seen, ICCP is a tightly integrated component of the SCADA system. It ties directly to the part of SCADA that can read all real-time data, and has full access to supervisory control. ICCP by its nature is exposed to the external world, so this introduces a real risk that some kind of buffer overflow vulnerability could expose the most critical parts of a SCADA system.

We would like to add a layer of insulation between external ICCP links and our SCADA system. It seems to me that few utilities have implemented anything like this. I am very interested in hearing about potential or recommended solutions. Perhaps this could be discussed further on this blog?

Comment from Matt Franz
Time: May 18, 2006, 11:16 pm

Tim,

Good question on a number of levels.

It sounds like you are suggesting one build a ICCP proxy server as buffer of sorts to buy you time. If it is compromised, or crashed at least the proper functioning of the SCADA/EMS is not hit as badly as if the lower level commnication drivers get hit on a tightly-bound system. Even if it might not enforce a lot of policy (i.e. an “ICCP firewall”) this probably buys you a lot.

Or perhaps folks are already deploying this sort of “ICCP Relay” of sorts–perhaps choosing two different vendors for a diversity of defense?

The challenge is complexity of implementing the 7-10 layers of the protocol stack correctly in the more exposed “proxy.” You could use an existing stack or write a new stack from scratch. Not sure which is worse.

[Here is where I removed a cheap shot about complex international standards vs. the simplicity and freedom (as in beer) of Internet standards ;]

However, the true impact of a “just an ICCP DoS” is probably worth discussing in a smaller forum, because all my testing was (obviously) done in a “lab” environment.

Pingback from Liquidmatrix Security Digest » Toronto Hydro Selects N-Dimension For Cyber Security
Time: March 30, 2007, 5:28 pm

[…] SCADA circles. I guess one could say that it’s better late than never. Recently the folks at Digital Bond created waves when they submitted a security vulnerability to CVE. For SCADA providers this is a new phenomenon. […]

Write a comment