Configuring PaX with Grsecurity
We’ve already briefly discussed PaX, but now it’s time to actually describe it in detail. PaX provides the following security enhancements:
- Non-executable memory: Sections that do not contain actual program code are marked as non-executable to prevent jumping to arbitrary location in memory and executing the code from there. Therefore, PaX ensures that program data is kept in a non-executable memory region from which we cannot execute code.
- ASLR: PaX provides support for randomizing the address space of the program to prevent sections from being loaded to the same base address upon program/system restart.
- Miscellaneous memory protection: PaX also provides other protections that are described in [5].
- # emerge sys-kernel/hardened-sources
We must choose “Customize Configuration,” which will present PaX-related settings to us, as shown below.
The PaX menu has the following options available (note that the description provided with each of the options presented below is taken from kernel’s Help menu, which you can also see on the picture above).
-
Enable various PaX features
-
PaX control
- Support soft mode: Allows running PaX in soft mode, which doesn’t enforce PaX features by default; PaX is enabled only on explicitly marked executables.
- Use ELF program header marking: Enables adding PaX-specific header to ELF executable, which enables us to enable/disable PaX features on executable basis by using paxctl.
- Use filesystem extended attributes marking: Similar option to the “Use ELF program header marking” except that per executable PaX features are controlled with setfattr, where the control flags are read from the user.pax.flags extended file attribute. Note that the filesystem used must support these extended attributes, so we should only use this option with supported filesystems.
- MAC system integration [none, direct, hook]: Option for controlling
per executable PaX features through mandatory access control (MAC)
system.
-
Non-executable page
- Enforce non-executable pages: Memory pages are marked as non-executable, which prevents an attacker from loading a shellcode into memory and executing it; typical memory sections that need to be marked as non-executable are stack and heap, which need to be marked as non-executable if we want to prevent various kinds of attacks like stack or heap buffer overflows. If this option is disabled, then the memory block returned by malloc function will be readable as well as executable, which shouldn’t be the case; the memory region returned by malloc should not be executable. There are some programs that rely on memory returned by malloc to be executable, like WINE, but we should learn to live without those programs (at least on hardened machine).
- Paging based non-executable pages: Paging feature of the CPU that uses hardware non-executable bit support.
- Emulate trampolines: Some programs use trampolines to execute instructions from non-executable memory pages. If we enable the non-executable pages, programs won’t be able to use the trampolines anymore. Therefore, to still allow specific programs to use trampolines, we should enable this feature to emulate the trampolines but still have the protection provided by non-executable pages.
-
Restrict mprotect(): this option prevents programs from changing the non-executable memory pages into executable, changing read-only memory pages into writable, creating executable pages from anonymous memory, and making relro data pages writable again. We can also use chpax or paxctl to control this feature on a per executable basis.
- Use legacy/compat protection demoting: When an application tries to allocate RWX memory, the kernel denies access by returning the proper error code to the application.
- Allow ELF text relocations: The libraries that use position-independent code do not need to relocate their code, which the attacker can use to attack the system; this is why we shouldn’t enable this option.
-
Enforce non-executable kernel pages: when we use this option, injecting code into kernel memory is harder, because the kernel enforces non-executable bit on kernel pages; this is a kernel-mode equivalent of PAGEEXEC and MPROTECT.
- Return Address Instrumentation Method [bts, or]: Specify the method
used to dereference pointers. The “bts” option is compatible with
binary-only modules, but has a higher runtime overhead, while the “or”
is incompatible with binary-only modules, but has lower runtime
overhead.
- Return Address Instrumentation Method [bts, or]: Specify the method
used to dereference pointers. The “bts” option is compatible with
binary-only modules, but has a higher runtime overhead, while the “or”
is incompatible with binary-only modules, but has lower runtime
overhead.
-
Address Space Layout Randomization
- Address Space Layout Randomization: By enabling this option, we can randomize the following memory areas when the program is loaded: task’s kernel and user stack, base address of executable and base address for mmap() function calls that creates a new mapping in the process’s virtual address space.
- Randomize kernel stack base: Randomizes the kernel stack of every task running in the kernel.
- Randomize user stack base: Randomizes the user stack of every task running in the user-space.
- Randomize mmap() base: Randomizes the base address for the mmap()
function calls, which causes all dynamically loaded libraries to be
loaded at random addresses, making it harder to guess the right address.
-
-
Miscellaneous Hardening Features
- Sanitize kernel stack: When enabled, this option deletes the kernel stack before returning from a system call, which reduces the information a kernel stack leak can reveal. If you decide to enable this option, keep in mind that the slowdown of the system will be about 1%.
- Forcibly initialize local variables copied to userland: When enabled, this option zero-initializes some local variables that are copied to user space to prevent information leakage from the kernel. This option is similar to the previous option, but doesn’t slow down the system as much.
- Prevent invalid userland pointer dereference: When enabled, this option prevents dereferencing userland pointers where kernel pointers are expected, which can be useful in preventing exploitation due to the kernel bugs. Whenever a program calls into the kernel to do some action, the kernel needs to take the userland pointer and read data from it. Malicious software can exploit that to perform some actions in the kernel that should not be allowed; when this option is enabled, the kernel doesn’t directly use the userland pointer.
- Prevent various kernel object reference counter overflows: When enabled, this option prevents overflowing various kinds of object reference counters due to their abuse. Reference counters are used for counting objects, but an attacker can misuse them by incrementing them so much that they will reach the maximum number and wrap around, which might set the counter to zero or to a negative number. This can result in unexpected actions such as freeing the memory that’s still being used.
- Automatically constify eligible structures: When enabled, this option will automatically mark a class that contains only function pointers as being constant, which prevents overwriting this piece of memory (because it’s marked as const). This prevents the attacks that try to overwrite function pointers to point to shellcode, which is executed when that function gets called.
- Harden heap object copies between kernel and userland: When enabled, the kernel will enforce the size of heap objects when they are copied between user and kernel land.
- Prevent various integer overflows in function size parameters: When enabled, the kernel will recompute expressions passed as function arguments with double precision and, if an overflow occurs, the event is logged and the process killed.
- Generate some entropy during boot: when enabled, the kernel will extract some entropy from program state, which causes a minor slowdown of the system boot process.
- Deny reading/writing to /dev/kmem, /dev/mem, and /dev/port: When enabled, we won’t be able to use the /dev/kmem, /dev/mem, /dev/port, and /dev/cpu/*/msr, which means that an attacker won’t be able to insert malicious code into the running kernel; the attacker won’t even be able to open those devices if this option is enabled. But, he might still be able to modify the running kernel by using privileged I/O through ioperm/iopl.
- Disable privileged I/O: When enabled, the ioperm/iopl calls will be disabled and will return an error, which will prevent an attacker from changing the running kernel by using those operations. If you use X server with your hardened kernel, this option should be disabled, otherwise the X server will fail to start with “xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted)” failure message.
- Disable unprivileged PERF_EVENTS usage by default: When enabled, the /proc/sys/kernel/perf_event_paranoid can be set to 3 through sysctl, which will prevent unprivileged use of PERF_EVENTS syscalls.
- Insert random gaps between thread stacks: When enabled, a random gap will be put between thread stacks, which reduces the reliability of overwriting another thread’s stack.
- Harden ASLR against information leaks and entropy reduction: When enabled, the /proc/<pid>/maps and /proc/<pid>/stat will contain no information about the memory addresses used by the process <pid>. Additionally, the suid/sgid binary programs will have the argv/env strings limited to 512KB and stack limited to 8MB to prevent abuse. We need to enable this to harden the ASLR security a little bit more, so it can’t be easily bypassed.
- Deter exploit bruteforcing: Often programs start a new thread or fork a new child in order to accept a new connection. This allows an attacker to bruteforce the unknown part of the shellcode in order to gain code execution; this is possible because the target process is not killed, only the thread/child is killed. This option slows down bruteforcing attempts by delaying the parent process by 30 seconds on every fork when a child is killed by PaX or crashed due to an illegal instruction. When that happens, the administrator will have to manually restart the daemon to make it behave normally again.
- Harden module auto-loading: When enabled, the module auto-loading will be limited to privileged users. This prevents loading vulnerable modules into the kernel by unprivileged users. We can also disable the auto-loading of modules altogether but, depending on the use, we might not want to do that; therefore this option is perfect for limiting access to auto-loading features.
- Hide kernel symbols: When enabled, the information on loaded modules and displaying kernel symbols will be restricted to privileged users. This prevents unprivileged users from getting their hands on kernel information, such as variables, functions, and symbols.
- Active kernel exploit response: When enabled, if a PaX alert is triggered because of suspicious activity in the kernel, the kernel will actively respond to the thread not only by terminating the process that caused the alert, but also by blocking the user that started the process to prevent further exploitation. If the user is root, then the kernel will panic the system; if it’s a normal user, the alert will be logged, all user processes will be terminated and new processes (by the same user) will be permitted to start only after system restart.
No comments:
Post a Comment