[custom-header-login]
In support of the objectives for the LPIC-3 Linux Security certification and exam 303-200 we now take a look at another mechanism to fight buffer overflow attacks and this is Exec-Shield.
Each objective is available to view online. However if you prefer to have all the content in one place and study from an eBook then the objective ‘LPIC 3 Linux Security 326.1 Host Hardening’ is now available to download for just £0.99.
Exec-Shield and NX Protection
Along with ASLR ,exec-shield is designed to limit against
• stack
• buffer or
• function pointer overflows
In simple terms, manipulating data in memory for malicious intent. Having been introduced by Red Hat in 2003 as of RHEL 7 and its derivatives it can no longer be managed via sysctl and is enabled by default without the option of disabling the feature. There is no longer a key in the procfs to manage exec-shield. This is similar in later versions of Ubuntu. On older systems the key used to manage exec-shield was kernel.exec-shield with a value of 1 to enable it and 0 to disable it. To view the exec-shield support is enabled on a newer system we can query the CPU for NX support (No-Execute Bit):
$ grep -Fw nx /proc/cpuinfo
flags : fpu vme ... nx mmxext ...
We can see the NX flag showing in the results, highlighted in red, indicating that the CPU supports NX and Exec-Shield. If it does not show then it may be disabled in your system’s BIOS.
Knowing that the system supports NX and exec-shield is one thing, ensuring it is running via the Kernel is another. We will use the command dmesg to verify it did load and is active. The dmesg command reads messages from the protected Kernel ring buffer and we should be able to see NX protection being activated as the Kernel loads:
$ dmesg | grep -Fw NX [ 0.000000] NX (Execute Disable) protection: active
Incidentally, the -F option in grep is to search for fixed-text and -w searches for complete word matches. In this case, –w ensures we do not match NX located as parts of other words, such as, LNXPWRBN