SBoM is NOT a Four Letter Word

I have been ranting about Software Bills of Material or SBoM for a while. This week I have two examples of why this is important – even critical.

The first story is about a TCP/IP network stack and the vulnerability is called Amnesia:33. It impacts four open source libraries – uIP, FNET, picoTCP and Nut/Net. Contrary to some opinions, these open source, free TCP libraries are not only NOT bug-free, they are vulnerable to remote code execution, denial of service, information leaks and DNS cache poisoning.

The impact of these vulnerabilities depends on how the device is used, whether it is publicly visible and other factors.

The code is used, THEY THINK, by at least 150 different vendors on an unknown number of products. The researchers at Forescout think that at least a million devices are impacted, but that, along with the number of vendors impacted is mostly a guess. The vendor count is likely much higher as these were vendors they were able to identify.

Since these vendors (and most others) do not have a Software Bill of Materials process – EVEN INTERNALLY TO THE COMPANIES -, most vendors are scrambling to figure out which products and which product versions use the impacted software. Credit: Forescout Research

In many cases, the IoT and IIoT devices are out of warranty and will never be patched and since the companies and people who bought these devices do not have a Software Bill of Material which would, at least, tell them if they have an affected device, so that they could decide if they want to replace the vulnerable devices, the hackers will have a field day.

The second case is for Gnu TLS. Gnu TLS is a free, open source TLS (HTTPS) library that has been around for 17 years and is used in a lot of software. It turns out that GnuTLS 3.6.x before 3.6.14 uses “incorrect cryptography”, which is a nice way to say that the crypto can be trivially bypassed.

So now all you have to do is figure out which of the hundreds of software products in your organization use this library. A few of the well known products that use GnuTLS are apt; cadaver, which is WebDAV, essentially; cURL; Wget; Git; GNOME; CenterIM; Exim; WeeChat; MariaDB; Mandos; Mutt; Wireshark; Rsyslog; slrn; Lynx; CUPS; gnoMint; GNU Emacs; Slapd; Samba; the Synology DiskStation Manager; OpenConnect; and a whole bunch of various VNC implementations.

So since everyone received a Software Bill of Material (SBoM) with the very most recent version of each product you use and that list is in a standardized form that you can import into a spreadsheet or database, it is each to determine which products use GnuTLS 3.6.x where x is less than 14.

Obviously, I am being sarcastic here. I know of no manufacturers that provide computer readable SBoMs to their customers, but there is help in the wings.

The federal government is working on an SBoM standard. While you say that might not help you, consider this. NIST is required to define standards for IoT and IIoT that the government buys. It is likely that SBoM will be one of those requirements. If a company like, say, Wireshark from the list above wants to continue to be able to offer their hardware to the government, they would have to provide an SBoM, assuming NIST goes this route. If they provide an SBoM to the government then you should be able to get a copy too. Credit: Security Now

These are only two examples from this month alone of the problem. The problem is massive and most companies are not prepared to deal with it.

Companies should create a SBoM plan, understanding that this is going to be a work in progress for a while. The first place to start is with ALL internally developed and custom third party software. Getting the information for these products should be easy. Something is definitely better than nothing and even a partial SBoM for a product is better than no SBoM.

If you need assistance, please contact us.

by