Taking Patch Management To The Next Level By leveraging Hardware Virtualization And Trusted Execution For On-The-Fly Patching

I have explored use cases for trusted execution, Intel® SGX in specific, in several blog posts.  This talks about running SQLite within Intel® SGX's secure enclave.  And this, talks about running a cryptography library like Cryptlib within a secure enclave.  And the internet is full of such examples.  But, they are the more obvious use cases.  There are varied non obvious and at times out of the box use cases that could greatly benefit from leveraging trusted execution.  Patch management is one such area that may not seem like an obvious fit, yet stands to gain from leveraging trusted execution technologies. 

On-the-fly patch management in specific, is neither that prevalent nor likely to be perceived as a good practice from conventional software management perspective.  However, it does have its place.  The following are just two of several examples that comes to mind - 

• There are a sizable number of systems with obsolete technologies, like legacy OS, legacy applications and more, in production environments.  It would be an investment to upgrade them.  That investment may not have its appeal.  Yet, getting rid of them also may not be an option.  Obviously, they are likely to carry vulnerabilities and it shouldn't come as a surprise if the software they run is not even supported.  Even worse, they may not even have a functional or working build environment available!  In such cases, binary patching, if available at a reasonable cost, might be the only stop gap solution.
• Another scenario where on-the-fly patching is useful is with backdoors that one might stumble on or zero day vulnerabilities that need to be immediately patched, before a formal patch is issued by the vendor responsible for it.  Depending on the situation, the backdoor or vulnerability may not even be well known yet and/or for reasons outside the scope of this discussion, there might be a need to implement an immediate binary patch, under the radar.

Above mentioned use cases are nothing new.  On-the-fly patching software is just for that reason.  However, on-the-fly patching of binaries is still vulnerable.  Not only are they more prone to stability issues themselves, if not implemented with extra care, they could create more problems than solve any.  Even with meticulous implementation, they are still fragile by nature.  Plus, unlike re-spun binaries, they don't necessarily secure the fix with a signed patch that is verified and loaded by the platform/OS loader, although they could give away the vulnerability they patch in a more obvious way.  In other words, while on-the-fly patching patches vulnerabilities real time, it could potentially leave the system no less vulnerable!

Techniques like hooking and patching used by existing on-the-fly patching technologies are now nearly old relics.  Thus this type of patch management stands to be seen as outdated.  By leveraging hardware virtualization and trusted execution, it can be brought forward to keep up with the fast phased technology landscape.  And the entire process can be made more secure and far more obscure to prying eyes.  It could redefine the way vulnerable binary codes are scanned, guarded and substituted in real time, and right when the vulnerable code is about to be executed - just-in-time and on-the-fly.  Features provided by hardware virtualization can be leveraged towards scanning and guarding the vulnerable regions, in far more powerful ways than current ones.  Trusted execution can be used not only towards obscuring which vulnerable region is replaced and with what, the entire process could also be driven using secure remote computation, software attestation and more. So, at several levels, combining hardware virtualization with trusted execution could make on-the-fly patch management exponentially more secure and powerful.

While I consider further exploring this myself, I also wanted to invite others to this discussion.  So, I thought I would share this insight and seek others' thoughts on this matter.  I am especially keen on 0Patch's insight, as they appear to use the equivalency of on-the-fly patching.  If they or anyone else would like to further discuss this, please use the comments below or reach out to info@kryptoguard.com.