You might say that KernelCare lags slightly behind the upstream distributions of patches. This, however, is normal, and regardless of the delay, most of the time you will be protected by KernelCare much faster than you would do the reboot yourself. The main cause of such delay is that upstream does not disclose the vulnerability until updated kernel is actually available. When it is disclosed, then we start working on making a patch available super-fast.
Yet, sometimes KernelCare truly shines and delivers protection way before updated kernel is even available from the OS maker. Let’s look at an example of a local privilege vulnerability CVE-2016-0728 that was announced on January 19th. Local privilege vulnerabilities are particularly dangerous in shared and container-based hosting, where attacker can pose as a customer, run 'exploit' and get root access of the server.
Now, even though proof of concept code was released on January 19th as part of the announcement - no known attacks were recorded using this vulnerability. Yet, we have seen other cases when attacks happen right after proof of concept code is released.
Let’s look at the timeline now:
CVE-2016-0728 vulnerability was announced on Jan 19th
KernelCare patched the vulnerability on Jan 21th at 5:15am.
Updated Kernel from RedHat was released on 25th - followed by CentOS.
KernelCare secured systems 4 days before RHEL and CentOS servers were secured against such attacks.
Our team consists of a dozen of Linux, kernel and security experts that work day and night on monitoring security lists and getting to work on patching vulnerabilities instantly. Our KernelCare agent pings the service every 4 hours, so, the most it will take for your kernel to be updated with the most recent patch release is 4 hours.
To learn more about KernelCare, take a look here.