<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=645174729237247&amp;ev=PageView&amp;noscript=1">
We are updating the structure and design of KernelCare blog for your convenience. Today, you may experience some text formatting inconvenience which will be fixed shortly.

Spectre just won't remain dead

 Spectre just won't remain dead

Shortly after exploit code was found in a public repository, two new vulnerabilities (CVE-2020-27170 and CVE-2020-27171) have been found in the Linux Kernel code that protects against it.

 

Both vulnerabilities allow a local user to read kernel memory which could contain sensitive information like encryption keys. Proof-of-concept code has also been made available privately, but it is safe to assume it will eventually reach public outlets.

The code flaw is present on all kernel versions up to 5.12-rc3, the most up-to-date release candidate. All distributions are vulnerable. 

KernelCare patches for all supported distributions are being prepared and should start being available next week.

The first vulnerability, CVE-2020-27170, affects the way the kernel mitigation against speculative out-of-bounds loads work. Unprivileged code extending a specific Kernel BPF (Berkeley Packet Filtering) functionality had access to pointers and could perform unbound pointer arithmetic, which in turn could be weaponized as an attack vector for kernel memory content exfiltration. The pointer operations could be used because some of the pointers that the BPF exposes were not being limited correctly.

 

The second vulnerability, CVE-2020-27171, uses the same type of BPF program extension on 64bit systems, where again a pointer operation suffers from an off-by-one flaw. Due to the nature of computing devices, the first number is 0, rather than the more natural 1, and a common programming mistake is not accounting for this when performing mathematical operations. This off-by-one flaw would let a pointer be modified in a such a way that it would expose a 4GB block of kernel memory. Timed correctly, this could permit an unprivileged user to have access to protected memory locations.

 

The detailed vulnerability reports mention the existence of a privately disclosed Proof-of-concept for each vulnerability, but a sufficiently motivated attacker could gather sufficient information about the problem from the report to develop his/her own attack code.

Spectre just won't remain dead

 Spectre just won't remain dead

Shortly after exploit code was found in a public repository, two new vulnerabilities (CVE-2020-27170 and CVE-2020-27171) have been found in the Linux Kernel code that protects against it.

 

Both vulnerabilities allow a local user to read kernel memory which could contain sensitive information like encryption keys. Proof-of-concept code has also been made available privately, but it is safe to assume it will eventually reach public outlets.

The code flaw is present on all kernel versions up to 5.12-rc3, the most up-to-date release candidate. All distributions are vulnerable. 

KernelCare patches for all supported distributions are being prepared and should start being available next week.

The first vulnerability, CVE-2020-27170, affects the way the kernel mitigation against speculative out-of-bounds loads work. Unprivileged code extending a specific Kernel BPF (Berkeley Packet Filtering) functionality had access to pointers and could perform unbound pointer arithmetic, which in turn could be weaponized as an attack vector for kernel memory content exfiltration. The pointer operations could be used because some of the pointers that the BPF exposes were not being limited correctly.

 

The second vulnerability, CVE-2020-27171, uses the same type of BPF program extension on 64bit systems, where again a pointer operation suffers from an off-by-one flaw. Due to the nature of computing devices, the first number is 0, rather than the more natural 1, and a common programming mistake is not accounting for this when performing mathematical operations. This off-by-one flaw would let a pointer be modified in a such a way that it would expose a 4GB block of kernel memory. Timed correctly, this could permit an unprivileged user to have access to protected memory locations.

 

The detailed vulnerability reports mention the existence of a privately disclosed Proof-of-concept for each vulnerability, but a sufficiently motivated attacker could gather sufficient information about the problem from the report to develop his/her own attack code.