Part3: Kernel protection preventive mechanisms in Linux systems and methods for monitoring them (Kernel address space layout randomization)
Background: As we continue our discovery of Linux kernel protection mechanisms, we should also look at the built-in capability called Kernel Address Space Layout Randomization (KASLR). KASLR’s purpose is straightforward: when you boot your machine, the system allocates space in volatile memory for its operation, and each time it chooses different addresses. This prevents harmful applications from targeting specific memory locations. In reality, if an attacker wants to perform a buffer overflow, Direct Kernel Object Manipulation or similar attack, they need to know the exact or absolute address of memory. KASLR reduces the likelihood of such interactions by changing memory addresses every time the machine is turned on.
Is it really effective mechanisms: It based on usecase let's deep dive into real example . Let's find our current address in memory
sudo grep _text /proc/kallsyms
If we take a closer look, we can see that the address of _text is ffffffffa2a00000, but after rebooting the machine, the address has changed to ffffffffa4600000. This shows that KASLR is working—since the memory address changes each time the system boots, an attacker cannot reliably determine the exact address.
But let's wait and check how can attacker get such information . In one of the method attacker should use CVE which can related to Information leak , but if we shall deep dive into the things we can see that even SUDO is able to catch that information .
The effective method to define current session memory address:
Because information leak CVEs are not very common, we can take another approach—privilege escalation—to obtain the information we need.
Let’s consider the SUDO privilege escalation path combined with the command sudo grep _text /proc/kallsyms. By combining these two components, we are able to retrieve the address required for our malicious file.
Detection Mechanisms: To deactivate KASLR, an attacker would modify the GRUB settings in the /etc/default/grub file by adding the "nokaslr" option to the GRUB_CMDLINE_LINUX_DEFAULT line. For this reason, you should always monitor changes to /etc/default/grub and check the /proc/cmdline output for the presence of the "kaslr" or "nokaslr" parameter.
Prevention mechanisms: Restrict write access to /etc/default/grub, and always close privilege escalation paths for all users through proper patching and system hardening measures.
Conclusion: The noted mechanism works well, but relying solely on it is not sufficient. You should also apply additional hardening measures to further reduce the risk of memory read abuse.