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 -
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 firstname.lastname@example.org.
I learnt of Google's decision to block code injection in Chrome processes and McAfee's reaction to it's impact on DLP software providers, including theirs, via Brian Reed's tweet. Code injection is a topic that is viewed as a nightmare by software platform providers and as something inevitable by some ISVs like security software makers and developer tools builders. That was a decade or two back or at least it should have been that way! The fact that we are still stagnating by using classic means to inject, hook and patch is why we are still having this tug of war between platform providers and other ISVs on this matter.
In their defense, platform providers have tried to provide extensions and APIs as an alternate to dissuade ISVs from injecting code the way we do. However, they are not nearly powerful enough for ISV needs and thus ISVs ultimately resort to much cruder means like code injection. And Google Chrome team, as Microsoft has realized for sometime now, is right in thinking that approaches like code injection is a significant cause for instability introduced into their environment. ISVs on the other hand have tried to make the injection process more stable by navigating away from chasing byte code patterns which are likely to break even with the release of a service pack to relying on more static regions that are less likely to break. Nevertheless, it is not 100% failsafe and thus the tug of war between platform providers and ISVs.
Rather than having to sacrifice useful features because of changes to the platform that leaves them crippled, ISVs ought to have caught up to more sophisticated means towards achieving the equivalency of code injection. As long as we are in a headlock working at the same level in the software stack, platform providers, as those hosting that layer are bound to have their way and for their own good. Security software makers ought to have moved one layer down already to be able to better monitor the platform they are trying to secure. Having a thin layer of Microvisor or hypervisor to accomplish just this is inevitable for any security software maker. In fact, McAfee itself has or had DeepSafe technology that could have helped with just this kind of situation. Of course, as the use of such technologies become ubiquitous, we are going to have to battle problems relating to chaining of Microvisors/hypervisors, bottlenecks in that area and other problems as that layer gets more attention. At that point hardware support/awareness for such needs is likely to gain traction. Nevertheless, we should have by now moved out of the layer in which we are fighting this code injection problem and the fact that we haven't fully is why there is this tug of war. DLP and other software shouldn't have to suffer because we are not catching up to this need fast enough.
Founder of KryptoGuard™ technology initiative, product and services.