Are you facing Kernel-memory-leaking Intel processor design?
This guide is for you.
This Intel processor design flaw can force Linux and Windows redesign.
A memory leak is an unintentional form of memory consumption whereby the developer fails to free an allocated block of memory when no longer needed. The consequences of such an issue depend on the application itself.
Here at Ibmi Media, as part of our Server Management Services, we regularly help our Customers to perform Intel related queries.
Generally, the bug is present in modern Intel processors produced in the past decade. It allows normal user programs to discern to some extent the layout or contents of protected kernel memory areas.
At best, the vulnerability could leverage by malware and hackers to more easily exploit other security bugs.
However, we can check if a Linux server is vulnerable to Meltdown and Spectre using this script:
$ cd /tmp/
$ wget https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh
$ sudo sh spectre-meltdown-checker.sh
On evaluation for this vulnerability in a vmcp servers, our Support Experts could see that they are vulnerable to the flaw:
(root)> sudo sh spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.18
Checking for vulnerabilities against live running kernel Linux 2.6.32-696.13.2.el6.x86_64 #1 SMP Thu Oct 5 21:22:16 UTC 2017 x86_64
Will use vmlinux image /boot/vmlinuz-2.6.32-696.13.2.el6.x86_64
Will use kconfig /boot/config-2.6.32-696.13.2.el6.x86_64
Will use System.map file /proc/kallsyms
CVE-2017-5753 [bounds check bypass] aka ‘Spectre Variant 1’
* Checking count of LFENCE opcodes in kernel: NO (only 27 opcodes found, should be >= 70)
STATUS: VULNERABLE (heuristic to be improved when official patches become available)
CVE-2017-5715 [branch target injection] aka ‘Spectre Variant 2’
* Mitigation 1
* Hardware (CPU microcode) support for mitigation: YES
* Kernel support for IBRS: NO
* IBRS enabled for Kernel space: NO
* IBRS enabled for User space: NO
* Mitigation 2
* Kernel compiled with retpoline option: NO
* Kernel compiled with a retpoline-aware compiler: NO
STATUS: VULNERABLE (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)
CVE-2017-5754 [rogue data cache load] aka ‘Meltdown’ aka ‘Variant 3’
* Kernel supports Page Table Isolation (PTI): NO
* PTI enabled and active: NO
STATUS: VULNERABLE (PTI is needed to mitigate the vulnerability)
Specifically, the cause is a flaw in the Intel x86-64 hardware. In addition, it appears a microcode update can't address it.
It has to be fixed in software at the OS level. Another possible method is to replace it with a new processor without the design blunder.
We can try to separate the kernel’s memory completely from user processes using Kernel Page Table Isolation, or KPTI.
This article will guide you on how to fix Kernel-memory-leaking. Kernel-memory-leaking Intel processor design occurs due to a flaw in the Intel x86-64 hardware.
The simplest way to detect a memory leak is also the way you're most likely to find one: running out of memory.
That's also the worst way to discover a leak! Before you run out of memory and crash your application, you're likely to notice your system slowing down.
A memory leak can diminish the performance of the computer by reducing the amount of available memory.
Most memory leaks result in general software reliability problems, but if an attacker can intentionally trigger a memory leak, the attacker might be able to launch a denial of service attack (by crashing the program) or take advantage of other unexpected program behavior resulting from a low memory condition.
Memory leaks have two common and sometimes overlapping causes:
1. Error conditions and other exceptional circumstances.
2. Confusion over which part of the program is responsible for freeing the memory.