Tag Archives: SBOM

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.

So You Think Your Open Source Software is Good?

I bet there is a large chunk of the folks reading this that will say that we don’t use open source software.

And then there is another large chunk that says we’re good; all up to date.

My guess is that both of these statements are wrong.

Synopsys did a study and found these two inter-related statistics:

99% of commercial software programs examined included at least one open-source component, so those of you who checked the first statement, unless you are part of the 1%, are wrong.

91% of those commercial software products contained OUT OF DATE or ABANDONED open-source code. So those of you you checked the second statement – you, too, are likely wrong.

I know you are probably tired of me beating on the software bill of materials drum, but I will keep doing it until the problem is fixed.

Synopsys says that of the 1,250+ software codebases that they reviewed, 91% contained components that were either more than FOUR YEARS OUT OF DATE or had seen NO DEVELOPMENT ACTIVITY IN THE LAST TWO YEARS.

Basically, we are making it very easy for the hackers to break in. Do you think that the code that is four years out of date had no bugs in it four years earlier? That doesn’t count the code that is three years out of date or two years out of date.

If hackers weaponize patches within 7 days of release on average, what do you think happens with code that is 4 years out of date?

This audit was of commercial software. Open source software is likely just as bad.

75% of the audited codebases included open source components with KNOWN VULNERABILITIES.

What could possibly go wrong?

49% contained HIGH RISK vulnerabilities.

Part of your vendor risk analysis needs to include auditing whether the vendor has a secure software development process and whether they have a software bill of materials management process.

THE EVIDENCE IS THAT MOST DON’T – AS IN ONE PERCENT PASS THE TEST.

What is the likelihood that all of your vendors – including cloud vendors – are in that one percent?

I’d say the likelihood is zero percent. Credit: ZDNet