Multiple Vulnerabilities Reported in CoDeSys by ICS-CERT

Yesterday the DHS Industrial Control System Cyber Emergency Response Team (ICS-CERT) published an interesting advisory for the 3S Smart Software System CoDeSys product. The advisory actually covers 5 separate vulnerabilities in the system, one reported by Celil Unuver (SignalSec LLC; a coordinated disclosure) and five (one reported by both) reported by our old friend Luigi (Unanticipated; a new term being used by ICS-CERT for uncoordinated disclosures).

Political Oddities

Before looking at the actual vulnerabilities, let’s look at some odd things about this advisory that make it interesting. First I thought that it was odd that Luigi would report five vulnerabilities on a particular ICS at the same time that ICS-CERT was preparing to publish an advisory on the same system, containing one of the same vulnerabilities. I went back and re-read the ‘Overview’ section of the advisory to see if there had been a previous alert on the Luigi vulnerabilities and there is no listing of one.

But the CoDeSys vulnerabilities sounded familiar so I searched my blog and sure enough I reported twice (December 3^rd, December 8^th) on an ICS-CERT alert (ICS-ALERT-11-366-01A) on these CoDeSys vulnerabilities. In the latest blog on that alert I posited that it appeared that Celil Unuver had become dissatisfied with the pace of the mitigation development on the vulnerability that he had identified and as a result he publicly disclosed the vulnerability.

Now ICS-CERT normally refers back to alerts when their advisory provides the mitigation for a publicly disclosed vulnerability; no rule says they have to, but that has been their general practice. Does not referring back in this instance have to do with 3S finally getting the mitigation completed so ICS-CERT no longer wants to apply pressure to them? I don’t know, but it looks that way.

Security Implications

The second odd thing about this advisory is related to an issue that I have discussed on a number of occasions, software components. ICS-CERT has previously noted that a couple of their reported vulnerabilities could affect more than just the reported software as that product is used as a component of other control system software products (and never did identify which products were vulnerable by association). This advisory extends that problem into the hardware realm.

According to this advisory “CoDeSys is used across several sectors of the automation industry by manufacturers of industrial controllers or intelligent automation devices [emphasis added]and by end users in different industries including system integrators who offer automation solutions using CoDeSys” (page 2). I’m not sure, but it sounds to me like CoDeSys is incorporated in the firmware or software embedded within the control devices. That could, in turn, make those devices susceptible to one or more of the vulnerabilities listed in the alert. Does that mean that these manufacturers should offer firmware updated to correct the security problems? I think so.

The Vulnerabilities

As noted earlier there are five vulnerabilities listed in this advisory. They all would allow a low skill level attacker to remotely execute a DOS attack and a higher skilled attacker to remotely execute arbitrary code. The vulnerabilities are (with active CVE file links):

• Integer Overflow, CVE-2011-5008;

• Stack Overflow, CVE-2011-5007;

• Content-Length NULL Pointer, CVE-2011-5009;

• Invalid HTTP Request NULL Pointer, CVE-2011-5009

• Folders Creation, no CVE #

Luigi noted in his disclosure that the file folder creation situation wasn’t really a vulnerability since he couldn’t see how it could be used in an attack, but it was an odd enough thing that he wanted to report it. ICS-CERT seems to accept that reasoning and that may be why there is no CVE # associated with that vulnerability.

3S has produced a new version of CoDeSys that does not contain these vulnerabilities and, according to the advisory, Luigi has verified that the new version corrects these problems.