So back in May we saw a LiveData Heap Overflow result in the first US-CERT Vulnerability Note for SCADA.

Today we have the second. Once again RFC1006/TPKT is the culprit, although this a clearly different flaw than the earlier one. It is important to note that the flaw was found in an IEC61850 implementation (used in substations) not in ICCP.

I like the Tamarack response, short and to the point:

Tamarack fixed the vulnerability as soon as we were made aware of it, and released the fix in V7.992. So far, we are not aware of anyone having experienced any difficulty regarding this vulnerability. We take all security issues seriously, and will work immediately to resolve them. It is recommended that IEC61850 products (and all substation networked devices) should be used in secure environments.

My only concern (as the finder, but also thinking about the end user perspective) is we don’t know which IED (or substation automation gear) products actually use the vulnerable Tamarack MMsd component. A US IED vendor? A European IED vendor? Have these vendors notified their end users and released a patch.

No idea.

So for those folks running IEC61850 they might want to check with their vendors.

We are also considering releasing (to trusted parties with a need to know who actually have this gear, NOT on our web-site) the crude ISIC-style TPKT-fuzzer that found this problem.

But, to avoid confusion, ISIC did not find this flaw.

Oh, one more interesting bit. Lately, I’ve been doing some VoiP Security Research and I stumbled upon some Cisco IPS Product Documentation with the following relevant info:

TPKT Validation and Length Checks
For TCP streams, checks on the format of the TPKT (RFC 1006), version number, and maximum length are performed. This helps protect the gateway from very large TPKTs or bad TPKT length attacks, which in turn helps to ensure the sanity of the TPKT fields and that the TPKT length is within the bounds defined by the policy.

So the H.323 stack appears to use TPKT/RFC1006 as well. Perhaps some users might be already protected for this vuln (and the previous ICCP vuln) based on existing signatures?

One last caveat and hopefully not blowing the FUD-horn too loudly.

It is important to remember that the number of disclosed SCADA vulnerabilities never equals the actual number of SCADA vulns that have been discovered. We continue to hear of activity on this front in various circles.