To operate servers securely, it’s not enough to patch their Linux kernels. Their shared software libraries must be patched as well. Otherwise, an enterprise lays itself open to attacks that exploit vulnerabilities such as Heartbleed or GHOST.
The usual way that enterprises deal with library vulnerabilities is by rebooting their servers. Admins rarely know exact libraries that services were using, so they just reboot the whole server to update them all. These reboots, however, bring serious problems:
Server downtime
When servers are down, websites go down, and display only error messages to visitors. After rebooting, it can take some time for server performance to stabilize, and occasionally servers don’t come back up properly after a reboot.
Windows of vulnerability
Because rebooting is laborious and problematic, enterprises often only do it on a periodically scheduled basis, leaving their servers open to attack. Even if they reboot every 30 days to comply with security standards, their servers may be vulnerable for two weeks or more.
In case servers have been patched manually, without a reboot, shared libraries may still contain vulnerabilities. When libraries are updated on disk, old unpatched files can persist in a server’s memory. Also, vulnerability scanners don’t detect these old unpatched library files in memory.
Live patching for Linux kernels, OpenSSL & glibc.
NEW
KernelCare with out-of-the-box integration with automation tools & vulnerability scanners, priority support and separate ePortal server Specially tailored for companies with 1000+ servers
Essential functions of automated Live patching for Linux kernels.
Live patching for Linux kernels in Arm-based devices.
.png "pci dss")
