Patch & Protect Yourself Against the New Linux Kernel Zero-Day Vulnerability

On January 19th, Perception Point disclosed a new Linux Kernel Zero-day Vulnerability patch that has the potential of affecting millions of users. The vulnerability affects any Linux operating system with kernel version 3.8+. In addition, Android device KitKat or higher are also affected, which is approximately 60% of the Android devices out on the market today. As such, the vulnerability has the potential of affecting millions of users.

If exploited, the vulnerability will allow a regular user to gain kernel level privileges, therefore it is a critical zero-day finding.

The list of Linux distros affected by this vulnerability is (according to a post on nixCraft):

  1. Red Hat Enterprise Linux 7
  2. CentOS Linux 7
  3. Scientific Linux 7
  4. Debian Linux stable 8.x (jessie)
  5. Debian Linux testing 9.x (stretch)
  6. SUSE Linux Enterprise Desktop 12
  7. SUSE Linux Enterprise Desktop 12 SP1
  8. SUSE Linux Enterprise Server 12
  9. SUSE Linux Enterprise Server 12 SP1
  10. SUSE Linux Enterprise Workstation Extension 12
  11. SUSE Linux Enterprise Workstation Extension 12 SP1
  12. Ubuntu Linux 14.04 LTS (Trusty Tahr)
  13. Ubuntu Linux 15.04 (Vivid Vervet)
  14. Ubuntu Linux 15.10 (Wily Werewolf)
  15. Opensuse Linux LEAP 42.x and version 13.x
  16. Oracle Linux 7

Even though it requires local access to exploit the vulnerability, the affected Linux distros are often used in the deployment of containers, which means a malicious container on the host can exploit the vulnerability and in turn take control over other containers on the same host.

Twistlock’s technologies, however, can easily catch any exploit attempting to take advantage of this newly discovered vulnerability, even though signatures are not yet available for potential exploits.

This is because our runtime defense capabilities do not require signatures. We automatically build runtime profiles of containers to identify potential anomalies or compromises. To catch exploits targeting this vulnerability, our function would utilize two behavior-detection capabilities

  • Syscall anomaly:  To exploit this vulnerability, the exploit requires calling a rarely used Linux syscall “keyctl“. In the environments that we protect, we scan every container image before they get deployed. The image scan analysis allows us to know exactly whether a particular container should be using this syscall. In runtime, when we see “keyctl” in the syscall activity, we would process its parameters to identify unusual patterns. This, combined with the fact that we know that this container should not be calling “keyctl“, we can therefore identify, with 100% certainty, that this is an exploit.
  • Process anomaly: In addition, our technologies allow us to develop an allowed process map for every container. Since the exploit will fork new processes and may execute a shell command in the end with admin rights. We can detect the presence of these new processes and compare them with the expected process map automatically and detect the presence of unwanted processes and unwanted shells. 
Once we detect any of the aforementioned behavior, we can either block the container, kill it altogether (by policy), or simply report the presence of exploits.
It is important to know that we can do this because our technologies allow us to analyze the container image together with the runtime environment in which the container will be run. This combination of knowledge significantly increases the precision of our syscall() and process map creation, and leads to a higher confidence in detection accuracy. This is materially different from traditional anomaly detection technologies that are essentially dynamic monitoring capabilities on a blackbox application for which there is little assurance that the execution would have covered most of the potential execution paths, hence can easily lead to false positives.

 

← Back to All Posts Next Post →