Command Reference Guide

__________________________________________________________________________________________________________________________________________________________________________________________________
__________________________________________________________________________________________________________________________________________________________________________________________________
STANDARD Printed by: Nora Chuang [nchuang] STANDARD
/build/1111/BRICK/man1/!!!intro.1
________________________________________________________________
___ ___
c
chatr(1) chatr(1)
SHMEM_MAGIC :normalSHMEM_MAGIC executable
The linker produces SHARE_MAGIC executables by default.
Using SHMEM_MAGIC
SHMEM_MAGIC is an interim solution until 64-bit addressability is available with a true 64-bit kernel.
SHMEM_MAGIC will not be supported on future HP implementations of 64-bit architectures (beyond
PA2.0). Programs that need larger than 1.75 GB of shared memory on those architectures will have to be
recompiled (as 64-bit executables) for those architectures.
Programs that are compiled as 64-bit executables on any 64-bit HP implementation (including PA 2.0) can-
not be marked as SHMEM_MAGIC nor do they need to be as they will already have access to more than
1.75 GB of shared memory.
The additional 1 GB of shared memory that is available over other types of executables can be availed of
only for system V shared memory and not other forms of shared memory (like memory mapped files).
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
minimize the need for manual intervention by whomever installsthe program.
An alternate method is setting the kernel tunable parameter, executable_stack
, to set a system-wide
default for whether stacks are executable. Setting the
executable_stack
parameter to 1 (one) with
sam (see sam(1M)) tells the HP-UX kernel to allow programs to execute on the program stack(s). Use this
setting if compatibility with older releases is more important than security. Setting the
executable_stack parameter to 0 (zero), the recommended setting, is appropriate if security is more
important than compatibility. This setting significantly improves system security with minimal, if any,
negative effects on legitimate applications.
Combinations of these settings may be appropriate for many applications. For example, after setting
executable_stack to 0, you may find that one or two critical applicationsno longer work because they
have a legitimate need to execute from their stack(s). Programs such as simulators or interpreters that use
self-modifying code are examples you might encounter. To obtain the security benefits of a restrictive sys-
tem default while still letting these specific applications run correctly, set executable_stack
to 0, and
run
chatr +es enable on the specific binaries that need to execute code from their stack(s). These
binaries can be easily identified when they are executed, because they will print error messages referring to
Section 1−−76 − 4 − HP-UX Release 11i: December 2000
___
___