Reader Comment – 3rd Party KEV’s

Earlier today, an anonymous reader left a comment on Saturday’s Public ICS Disclosure post. The reader questioned my note that the Broadcom advisory contained “vulnerabilities that is listed in the CISA Known Exploited Vulnerabilities Catalog in multiple”. The reader noted that the advisory “states that "No Brocade Fibre Channel Products from Broadcom Products are known to be affected by this vulnerability." so it also unlikely to be in the CISA KEV list.”

First, the advisory reports that Brocade Fabric OS, Brocade SANnav, and Brocade Support Link products are affected by the vulnerability; the ‘Brocade Fibre Channel’ note is confusing a lot of people. Second, the vulnerability (CVE-2023-4911) is a third-party vulnerability, found in the GNU C Library. As shown below (a clip from the NVD.NIST.gov site for the vulnerability), that vulnerability is listed in CISA’s Known Exploited Vulnerabilities Catalog.

We are starting to see a number of these KEV vulnerabilities being reported as third-party vulnerabilities. How vulnerable these new products are to the KEV depends a great deal on how the original program is utilized and implemented in the new product. Even where the product is susceptible to the vulnerability, existing exploits will need to be revised in most cases to work. 

Reader Comment – Software Bill of Materials

Yesterday, Jake Brodsky, a long-time reader and significant control system commentator in his own right, left a comment on my blog post about detecting third-party vulnerabilities. He suggests that a possible solution to the problem could be found in requiring vendors to prepare/publish a software bill of materials (SBOM) for control system products. The comment should be read by all with an interest in control system security.

SBOM is not a new idea. It is based upon the ‘bill of materials’ concept used in manufacturing where a manufacturer maintains a list of components (and their supplier) used to assemble a product. It allows the vendor to trace back faults reported by customers and identify appropriate corrective actions. Similarly, a software vendor could use a SBOM to track third-party components in its own products and the vulnerabilities reported in those components. This would allow the vendor to update their product with appropriate security fixes. There is an interesting blog post over on Synopsys.com outlining the importance of this use of a SBOM.

What Jake is suggesting, however, is to make the SBOM available to the end user. Legislation (HR 5793) was actually introduced in the closing days of the 113^th Congress to require SBOM submissions to federal agencies for any item purchased that contained software or firmware, but no action was taken. It was not subsequently introduced in the next session. I did not review the text because it was published after the session was ended. It is a short bill and worth reading even with the convoluted legislative-speak used by Rep Royce’s staff.

There are a couple of major problems, however, with providing an SBOM to owner/operators. First, there is the problem of tracking vulnerability reporting across the wide spectrum of libraries and software components. The National Institute of Standards NVD database is searchable and it is probably the most comprehensive database, but it does have its limitations. The most notable limitation is described on its search page: “Linux kernel vulnerabilities are categorized separately from vulnerabilities in specific Linux distributions.” The second problem is that there is no reporting capability in the NVD database, you have to physically do a search for each component listed in the SBOM each time that you want to verify that there have been no changes to the vulnerability status of the components. Are you going to do that search once a week, once a month, once a year?

To be fair to Jake, the suggestion that I made in the original blog post for researchers to establish test procedures that would identify the vulnerability they reported has essentially the same problem. How would a manufacturer know when that particular researcher published a new tool that may or may not apply to the equipment they own/operate?

We are starting to see SBOM products for developers (see the Revenera web site for example). These tools help developers track the components they employ in their software. Some even provide the developer with “Actionable alerts for newly discovered vulnerabilities in current and shipped products.” For SBOM to be a useful security management tool for owner/operators similar tracking software would be needed.

ICS-CERT Publishes Rockwell Advisory

Today the DHS ICS-CERT published a control system security advisory for Rockwell Allen-Bradley Stratix 5950 security appliances. The advisory describes five vulnerabilities in software from the Cisco Adaptive Security Appliance which Rockwell uses as the central operating system for their Stratix 5950 security appliance. Sharp eyed readers will recognize that I reported on these vulnerabilities almost two weeks ago shortly after Rockwell published their advisory.

There are system setup workarounds that reduce the risk of a denial of service attack from one of the improper input validation vulnerabilities and a Cisco provided Snort Rule for one of the others. There are currently no mitigation measures for the remaining three vulnerabilities.

The five reported vulnerabilities are:

• Improper input validation (3) - CVE-2018-0228, CVE-2018-0231, and CVE-2018-0296;

• Improper certificate validation - CVE-2018-0227; and

• Resource management errors - CVE-2018-0240

ICS-CERT reports that a relatively low-skilled attacker could remotely exploit the vulnerabilities to bypass client certification to create connections to the affected device or cause the device to crash.

*Insert standard third-party vulnerability rant*