chatr_pa.1 (2010 09)

c
chatr_pa(1)
PA-RISC Systems Only
chatr_pa(1)
mapped files using a shared mapping (
MAP_SHARED).
In order to use this new feature, the maxdsiz kernel configurable variable will need to be increased
appropriately; see maxdsiz (5). Also, the system will have to enable enough swap space to support
processes with large private address spaces.
Compatibility issues
Processes that enable a private 3rd quadrant (
q3p processes) will reduce the amount of address space
available for shared objects by 1GB. Also,
q3p processes will not be able to share objects that were
created by another, non-
q3p process, even in the 4th quadrant, unless those objects were created by the
non-q3p process using the IPC_GLOBAL flag (System V shared memory) or
MAP_GLOBALflag (mmap). If
recompiling is not an option, it will be necessary to make all processes that share objects with the
q3p
process into q3p processes (chatr +q3p enable
a.out).
Processes that enable a private 4th quadrant (
q4p processes) will have no address space available for
shared objects. This means that the process will not be able to use System V shared memory, shared
mapped files, etc. Shared libraries will still work, although the kernel will map them as private. Note
that a
q4p process implies that the 3rd quadrant is private also. In other words, the kernel will not exe-
cute a process that only enables a private 4th quadrant.
Because the system call gateway page has to remain at address 0xC0000000 for binary compatibility rea-
sons, the data segment cannot be extended past the beginning of the 4th quadrant. Therefore, the
brk()
and sbrk() system calls will only allow the data segment to be expanded up to that address.
To take advantage of private address space in the 4th quadrant, memory will need to be allocated using
the
mmap() system call with the MAP_PRIVATE option. The system call malloc() has been modified
to do this automatically. No re-link will be necessary to take advantage of the new
malloc() for a pro-
gram that uses a shared version of the C library. A program that was linked with a non-shared library
version of the C library, however, will need to be re-linked.
These changes have no compatibility impacts if the feature is not enabled.
This feature can only be enabled for 32-bit programs running on the 64-bit version of HP-UX. The 32-bit
version of HP-UX will silently ignore the request for a private 3rd or 4th quadrant.
Restricting Execute Permission on Stacks
A frequent or common method of breaking into systems is by maliciously overflowing buffers on a
program’s stack, such as passing unusually long, carefully chosen command line arguments to a
privileged program that does not expect them. Malicious unprivileged users can use this technique to
trick a privileged program into starting a superuser shell for them, or to perform similar unauthorized
actions.
One simple yet highly effective way to reduce the risk from this type of attack is to remove the execute
permission from a program’s stack pages. This improves system security without sacrificing performance
and has no negative effects on the vast majority of legitimate applications. The changes described in this
section only affect the very small number of programs that try to execute (or are tricked into executing)
instructions located on the program’s stack(s).
If the stack protection feature described in this section is enabled for a program and that program
attempts to execute code from its stack(s), the HP-UX kernel will terminate the program with a
SIGKILL
signal, display a message referring to this manual page section, and log an error message to the system
message log (use dmesg to view the error message). The message logged by the kernel is:
WARNING: UID # may have attempted a buffer overflow attack. PID #
(program_name) has been terminated. See the ’+es enable’ option of
chatr(1).
If you see one of these messages, check with the program’s owner to determine whether this program is
legitimately executing code from its stack. If it is, you can use one or both of the methods described below
to make the program functional again. If the program is not legitimately executing code from its stack,
you should suspect malicious activity and take appropriate action.
HP-UX provides two options to permit legitimate execution from a program’s stack(s). Combinations of
these two options help make site-specific tradeoffs between security and compatibility.
The first method is the use of the
+es option of chatr and affects individual programs. It is typically
used to specify that a particular binary must be able to execute from its stack, regardless of the system
default setting. This allows a restrictive system default while not preventing legitimate programs from
executing code on their stack(s). Ideally this option should be set (if needed) by the program’s provider, to
HP-UX 11i Version 3: September 2010 − 5 − Hewlett-Packard Company 5