Positively Impacting Vulnerability Disclosures With On-The-Fly Patch Management

In an earlier blog, I talked about on-the-fly patch management.  While I expressed my apprehensions about on-the-fly patching, I mentioned how newer technologies in trusted execution space and virtualization can be leveraged, to make on-the-fly patching more resilient, in comparison to where it stands now.  I also acknowledged that on-the-fly patch management has its place, in spite of some misgivings.  I recently stumbled on a vulnerabilities disclosure called ripple20, that further accentuated the potential value of on-the-fly patch management.

It is nothing new for security researchers to go on bug hunts, looking for holes in software(s), either with bug bounty in mind, or for other reasons.  They generally focus on popular, widely used or generally known to be buggy software(s) and/or the ones that are more likely to be on internet facing systems, as a starting point.  At times I have noticed that they do look for arcane or offshoot software that might be pervasive but not necessarily popular.  Ripple20 appears to fall under the latter kind, zoning in on an embedded TCP/IP software, by Treck Inc.  Apart from the fact that they were perhaps more methodical and far sighted about how they went about their disclosure, presumably in an attempt to positively impact their future course, there are several things about that disclosure that got my attention, especially from on-the-fly patch management perspective.  For example, to quote from that link, "In the case of Ripple20, the starting point was embedded into Treck’s TCP/IP low-level Internet protocol suite library. The library could be used as-is, configured for a wide range of uses, or incorporated into a larger library. The user could buy the library in source code format and edit it extensively. It can be incorporated into the code and implanted into a wide range of device types. The original purchaser could decide to rebrand, or could be acquired by a different corporation, with the original library history lost in company archives. Over time, the original library component could become virtually unrecognizable. This is why, long after the original vulnerability was identified and patched, vulnerabilities may still remain in the field, since tracing the supply chain trail may be practically impossible."  This level of non-streamlined/disorganized and/or chaotic nature of Treck's software distribution could at times make on-the-fly patch management indispensable! Following quote from the same link further confirms it - "Over the course of the disclosure process we found that while patching was difficult for some vendors, it could potentially be even more difficult or close to impossible for some end users to install the patches. (For example, if the library is on a separate physical component or the company that produced the component has ceased operations.)"

This link, also pertaining to Ripple20, makes the following comparable statements - "Experts now fear that all products using this library will most likely remain unpatched due to complex or untracked software supply chains."  ... "Problems arise from the fact that the library was not only used by equipment vendors directly but also integrated into other software suites, which means that many companies aren't even aware that they're using this particular piece of code, and the name of the vulnerable library doesn't appear in their code manifests."

I hope patch management solutions like 0patch are taking notice of these kinds of disclosures, to positively impact the situation by creating micropatches, as applicable.  While creating such patches, it should also be remembered that on-the-fly patch management could be taken to the next level, with trusted execution and virtualization, as mentioned in the earlier blog post.