Unfortunately not. 0patch is designed for applying small patches (hence micropatches), and currently only to native executable modules (typically EXEs and DLLs). Most critical remotely exploitable vulnerabilities on Windows are of this type, and we can micropatch them.
We currently cannot directly* micropatch:
- Vulnerabilities in Windows kernel; this is due to the fact that Windows have an active self-defense mechanism for preventing kernel code modification called PatchGuard (formally named Kernel Patch Protection), which our micropatches would trigger and cause the computer to reboot. We believe PatchGuard adds negligible security value and there are known ways of disabling/bypassing it, but we have for now decided not to do that. It is possible that we'll revisit this decision in the future and advise users to disable PatchGuard (e.g., for end-of-support Windows 7 and Windows Server 2008 R2 servers with 0patch installed) in order to apply kernel micropatches, should these become necessary.
- Vulnerabilities in .NET code; .NET applications are not compiled to native machine code but to managed code, which gets interpreted by .NET Framework's Common Language Runtime upon execution. We can, however, micropatch .NET Framework's native executables.
- Vulnerabilities in Java code; while we can micropatch the Java Runtime Interpreter (e.g., java.exe), we can't micropatch Java applications (typically delivered as class files in a JAR archive) because they, too, are not in native machine code.
- Vulnerabilities in scripted code; it would be relatively simple, technically, to modify scripted code in memory right before it got executed, but in contrast to binary files, which practically never get manually modified, scripted code is often modified by users or admins - and that makes it hard to identify a vulnerable version and pinpoint the vulnerability within. This is why we decided not to support micropatching of scripted code.
* While we cannot directly micropatch said types of vulnerabilities, we may be able to do so indirectly. For example, the BlueKeep vulnerability is located in Windows kernel code, but attacker's malicious data goes through a user-space process en-route to the kernel - and our BlueKeep micropatch modifies this user-space process to block the attack with exactly the same result as a kernel micropatch would.
0 Comments