HP-UX Reference (11i v2 07/12) - 1 User Commands A-M (vol 1)

c
chatr_pa(1)
PA-RISC Systems Only
chatr_pa(1)
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_GLOBAL flag (mmap). If recom-
piling 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 execute 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 program
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 pro-
gram 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 per-
mission 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 sec-
tion 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 leg-
itimately 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
140 Hewlett-Packard Company − 5 − HP-UX 11i Version 2: December 2007 Update