Protecting Servers from HeartBleed. Yes, HeartBleed.

HeartBleed… kind of sounds like a love song from the 1970s. It’s not. HeartBleed is a serious vulnerability (CVE-2014-0160) affecting the OpenSSL shared library. It’s been around since 2014, but unlike the oldies you hear once in a while on the radio, this cyber weakness is very much with us today. NTT’s 2020 Global Threat Intelligence Report reveals that HeartBleed helps make OpenSSL the second most targeted software technology in the world—accounting for 19% of hostile activity globally.

HeartBleed is an attack that takes advantage of a memory handling bug in OpenSSL versions 1.0.1 to 1.0.1f. With HeartBleed, attackers are able to decode 64 kilobytes of encrypted data during each of the OpenSSL software’s “heartbeats.” They can exploit the “bleed” of data to mount a man-in-the-middle attack or gain access to sensitive information such as passwords and user IDs.

Contents:

1. The Solution is Patching. The Problem is Also Patching
2. Live Patching as a Way to Mitigate Heartbleed with Rebooting
3. Conclusion

The Solution Is Patching. The Problem Is Also Patching.

Mitigating HeartBleed and comparable threats involves patching vulnerable OpenSSL libraries as well as those of the GNU C Library (glibc). The library updating process may take the form of the MITRE Adversarial Tactics, Techniques and Common Knowledge (ATT&CK) framework. ATT&CK recommends that organizations regularly “scan externally facing systems for vulnerabilities and establish procedures to rapidly patch systems when critical vulnerabilities are discovered through scanning and through public disclosure.” 

Then, having identified critical vulnerabilities, sysadmins typically schedule downtime to execute the patching process itself. This has always meant shutting down the stack, patching the OS and restarting the stack. It also usually requires time and attention from a lot of people, such as Linux admins, database administrators (DBAs), middleware admins and business users. Assuming there are no problems (not always a reliable assumption) the sysadmin next validates the updated stack and puts it back into production.

Several problems arise in this process:

• Uncertainty about which libraries need updates—Sysadmins usually don’t have a clear idea of which of their libraries needs to be patched. As a result, they typically do a system-wide reboot.
  Reboot cycles lead to service degradations and/or outages. After rebooting, it can take a while for server performance to stabilize. Sometimes, servers don’t come back properly after a reboot. 
• Windows of vulnerability—Due to the labor required for a reboot, along with the potential disruption, enterprises often schedule reboots for pre-arranged downtimes, such as on weekends. This delay leaves their servers open to attack. Even if a sysadmin reboots every 30 days to comply with security standards, the servers may be vulnerable for two weeks or more.
• Incomplete patching—When servers get patched manually, without a reboot, shared libraries may still contain vulnerabilities. For example, when libraries are updated on disk, old unpatched files can persist in a server’s memory. And, vulnerability scanners don’t detect these old unpatched library files in memory. 

Using UChecker to Mitigate HeartBleed and Other Shared Libraries Vulnerabilities

When servers get patched manually, without a reboot, shared libraries may still contain vulnerabilities. For example, when libraries are updated on disk, old unpatched files can persist in memory. And, vulnerability scanners don’t detect these old unpatched library files residing in memory.  It is now possible to identify if the system is still susceptible to HeartBleed or similar vulnerabilities by scanning the libraries in memory with KernelCare’s Uchecker. 

 Here’s how it works:

• UChecker gets the current latest BuildIDs from a resource on our site, e.g. https://patches04.kernelcare.com/userspace.json
• It takes a running process by iterating over /proc/
• It then gets a linked shared library from /proc/<pid>/maps
• At this point, the tool checks if the shared library been replaced or deleted
• Depending on the state of the process, the tool then either parses the Executable and Linkable Format (ELF) from the file system or from mapped memory
• The tool fathers BuildID from .note.gnu.build-id
• The tool then iterates through this cycle to scan additional libraries, as needed

Figure 1: How Uchecker Works

Visit the Uchecker Github page and watch the demonstration of how it works.

UChecker helps to search for vulnerable libraries for free; however, to update them, the reboot is necessary. If you need to scan for vulnerabilities and update libraries without restarting processes or rebooting servers, try KernelCare+: it checks to see if any running processes are using outdated libraries in memory and then updates vulnerable shared libraries without restarting them.

Conclusion

Shared libraries remain a serious source of security risk exposure for companies that use Free and Open Source Software (FOSS). Uchecker and KernelCare Live Patching Technology enable updating of shared libraries with the disruptions and extended risks of a server reboot. Together, Uchecker and KernelCare enable faster and more effective patching of shared libraries. HeartBleed and other similar vulnerabilities can now be addressed in ways that do not slow down the entire organization. Learn more at https://lp.kernelcare.com/kernelcare-early-access