Address space layout randomization

Address space layout randomization (ASLR) is a technique that is used to increase the difficulty of performing a buffer overflow attack that requires the attacker to know the location of an executable in memory. A buffer overflow vulnerability is a flaw in software written in a memory-unsafe programming language, such as C. Such a flaw is characterized by a failure of an application to validate the size of user input data that is written to memory. An application can remedy this flaw by checking the length of the user input data and throwing an exception or issuing an error message if the actual length does not match the expected length.

z/OS® provides options to enable ASLR for 24-bit and 31-bit low private storage as well as for 64-bit private storage. When enabled, the feature affects all storage allocations in the specified storage ranges (not just executables). Common storage, 24- and 31-bit high private storage (including LSQA), high virtual shared, the high virtual local system area and the 2G-64G area are unaffected.

Enabling ASLR

By default, ASLR is disabled. To enable ASLR, either IPL the system using a DIAGxx member that specifies the ASLR option or issue the SET DIAG=xx command after IPL. If you enable ASLR after IPL, only those jobs that are subsequently started and that are not exempt from ASLR will have ASLR enabled. The ASLR enablement options provide a way to restrict ASLR to subsets of address spaces where it is less likely to cause a storage constraint issue. For details about the options, see the description of the ASLR parameter in DIAGxx parmlib member in z/OS MVS Initialization and Tuning Reference.

Impact of ASLR on virtual storage

The decision to enable ASLR represents a tradeoff between enhanced security and a reduction in the amounts of available 24-bit, 31-bit, and 64-bit private storage. When enabled for 24- and 31-bit virtual storage, the size of available private storage will be reduced by up to 63 pages and 255 pages, respectively. A job’s requested region size must still be satisfied from within the reduced private area in order for the job to be started. Jobs whose region size cannot be satisfied will result in an ABEND 822. If a job’s requested region size is satisfied, it is still possible that the reduced size of private storage prevents the job from completing, resulting in an ABEND 878.

One way to determine whether jobs would not be able to run under the constrained size of 24- or 31-bit private storage that would occur with ASLR enabled is to specify a larger value for the CSA parameter in parmlib. Increasing the sizes of both 24- and 31-bit CSA by 1M effectively reduces the sizes of 24- and 31-bit private storage by 1M, which is greater than the maximum reduction that would occur under ASLR.

Excluding individual address spaces from ASLR

When ASLR is enabled, you can use SAF authorization to exempt selected address spaces from ASLR. To do this, permit SAF READ authority to the IARRSM.EXEMPT.ASLR.jobname resource in the FACILITY class to fully exempt the job or to the IARRSM.EXEMPT.ASLR24.jobname resource to exempt the job from only 24-bit ASLR. The following example shows the set of commands to fully exempt a job from ASLR:

RDEFINE FACILITY IARRSM.EXEMPT.ASLR.jobname UACC(READ)
SETROPTS CLASSACT(FACILITY)
SETROPTS RACLIST(FACILITY) REFRESH

Certain system address spaces, such as MASTER, which initialize early during the IPL process are not randomized. High virtual storage may not be randomized in address spaces with initialization exits that obtain high virtual storage. Job steps that obtain high virtual storage and assign it to a task not within the program task tree of that job step limit the ability of the system to set up randomization for the next job step if the obtained storage persists across job steps.