ICS-CERT Updates GE HART Device DTM Advisory

Today ICS-CER published an update of the GE and MACTek version of the HART Device DTM advisory. No changes have yet been published for the similar advisories for systems from Emerson, Honeywell, Magnetrol, and Pepperl+Fuchs or the latest update of the CodeWrights advisory. The update provides new information in three separate areas of the advisory.

Updated Impact Information

The first area changed deals with the ‘Impact Information’ section of the advisory. A new paragraph has been inserted in between the two paragraphs found on the original:

“The buffer overflow exploited could be used to execute arbitrary code on the system running the Frame Application. The researcher has provided proof of concept to ICS-CERT and the vendor. The updated HART Device DTM provided by the GE and MACTek will resolve this issue. Successful exploitation requires that the Frame Application is running and connected to a DTM‑configured HART‑based device at the time of the exploit.”

Since no change was made to the initial paragraph of the advisory, this vulnerability still does not appear to affect the “information, control, or view by the control system of the HART devices on the 4-20 mA HART Loop”.

Vulnerability Overview

The second section to be changed is the ‘Vulnerability Overview’ section of the ‘Vulnerability Characterization’ portion of the advisory. Once sentence has been added to the existing initial paragraph:

“Overflow involved could be used to execute arbitrary code on the system running the Frame Application.”

Probably more importantly, the CVSS base score was changed from 1.8 to 6.8 and the vector string has been changed from (AV:A/AC:H/Au:N/C:N/I:N/A:P) to (AV:A/AC:H/Au:N/C:C/I:C/A:C). None of the above data is reflected in the current version of CVE-2014-9203 that was last updated on February 9^th, 2015; four days after the original GE advisory was published.

Mitigation

The final area changed is the addition of two paragraphs to the ‘Mitigation’ section of the advisory. They were added after the listing of available updates:

Device DTM software with the identified vulnerable versions listed as impacted should be used only within an offline secure network until patched. ICS-CERT strongly recommends performing configuration changes in a nonproduction environment where proper testing and risk evaluation can be performed. ICS-CERT also recommends that asset owners employ a least privilege practice and avoid unnecessary services within their production environment.

Some processes may require continual configuration changes. ICS-CERT recommends asset owners maintain all software with the latest security releases, limit connections outside the control process, and monitor approved connections for suspicious traffic.

The second paragraph sounds like generic advice. Much of the first paragraph is also generic, but it is a tad bit more strongly worded than we normally see in a ICS-CERT advisory. The strengthened verbiage seems appropriate based upon the additional scope of the vulnerability described earlier in the revised advisory.

GE Advisory

I went back to see if the changes found in this revision were also reflected in the advisory published by GE. Unfortunately there is a security certificate problem with the GE Advisory. Microsoft provides a warning that there is a mismatch between the address on the site (Https://geog.prod.acquia-sites.com/sites/geog.dev.local/files/geog_15-01_security_advisory_hart_dtm.pdf) and the address on the certificate (Https://geog.prod.com/sites/geog.dev.local/files/geog_15-01_security_advisory_hart_dtm.pdf ).

If you ignore the warning and open the file anyway you find that GE has not updated their advisory since the original ICS-CERT advisory was published last month. (Note: the link from the earlier version of this advisory now takes one to the same certificate conflicted site)

Commentary

There has been a number of odd things about the way that ICS-CERT has handled this vulnerability, almost from the get-go. We now have six separate advisories for a vulnerability in DLL library common to all of the affected systems and there are at three separate versions of the advisory found in the six current versions.

I have never used a HART based system and I am certainly not a control systems engineer, but it really looks like ICS-CERT is having problems coordinating the facts about this issue with the various vendors involved. It could be, of course, that the conflicts are due to different implementations of the library. If that is the case, it would be helpful if ICS-CERT would make that matter public.

As it stands now it looks like this is an ICS-CERT issue not a vendor issue.