Auditors Misconception of the Exposures Related to PPT Entries
By: Mitchell H. Levine, CISA
Audit Serve, Inc.
Within the last few years, emphasis has been placed on the review of the MVS operating system to ensure that its system components are not installed in a manner in which it would bypass security validation performed by the external security system. Traditionally, the main focus of the operating system has been to ensure that update access to APF (i.e., Authorized Program Facility) libraries were restricted. APF libraries are used to store system code which require special access, to store and retrieve data from protected areas on the system, and to execute system privileged instructions.
A load module (i.e., program) is APF authorized if it links-edited with the AC(1) code and is loaded from an APF library. If the program being executed calls other programs, these other programs will also be APF authorized without requiring it to be link -edited with AC(1) as long as are loaded from an APF authorized library. MVS creates a control block for the job step (i.e., the program) and sets the JSCBAUTH bit in the JSCB (i.e.,Job step control block) to 1 which makes the caller APF authorized. If the program is also coded to issue the MODESET SVC in order to put the program into supervisor state, then MVS checks its SVCTABLE to determine if the MODESET SVC is set to require the program to be APF authorized in order to issue the MODESET SVC. IBM p rovides the MODESET SVC with the setting to require the program executing it to be APF authorized which can be changed by your installation using the SVCUPDATE facility. If the program requires APF authorization, the programs JSCBAUTH bit is checked to determine if it isset to 1. If it is, or if MODESET doesnt require the program to be APF authorized, the callers PSW is loaded and the storage key bit is set to 0 and the supervisor state bit is enabled. The user can now access any common storage area th at is usually reserved for the operating system.
It should be noted that APF authorization in itself cannot bypass security. Storage key 0 must be obtained in order obtain the capabilities to maliciously bypass security. The methods that can be used to bypass security include:
- When a user is in storage key 0, a users TSO ID and password can be disclosed. The TSO ID and password is stored in a TSB control block within the common storage area. The TSB address is contained in the ASCB control block which is a fixed place in memory after each IPL.
- When a user is in supervisor state a channel program can be written to read and update data on volumes without having to go through the standard OPEN which would call the external security system for security validation.
- When a user is in storage key 0, the SAF vector table can be altered to disable SAF which would globally turn off security
As one can see, having access to APF libraries would require a technical person to construct a program to bypass security. However, using a program whose name is specified in the Program Properties Table (PPT) would allow a person to execute a program th at would automatically bypass all security validation. The program entry would need to have the BYPASS parameter specified which turns off the ACB bit that enables programs specified in its table to bypass security as long as the program resides in an AP F authorized library. Therefore, no additional code, which would require detailed knowledge of MVS internals, is required to be developed to bypass security.
Auditors have a misconception of the exposure pertaining to PPT. One of the typical audit control points is to ensure that all PPT entries reference a program that exists. IBM supplies a default table with entries that are precoded for all of the subsystems and products provided by MVS. These entries include, JES2 and JES3. However, since installations only run one of these subsystems, one of these entries are not used and therefore will not reference a specific program. The auditors viewed this unreferenced module as an exposure since a person can code their own module with the same name and bypass security. However, one can take an existing entry that is referencing a program in an APF authorized library and place it in a different APF authorized library, which would also bypass security. The control concern is the users that have update access to APF authorized libraries, not the unreferenced PPT entries.
This article was written more than one year ago. Events may have changed since this article was written.
For a free proposal to perform an audit of your organization or provide SOX support & testing services, contact Mitchell Levine of Audit Serve at (203) 972-3567 or via e-mail at Levinemh@auditserve.com.
Copyright 2006, Audit Serve, Inc. All rights reserved. Reproduction, which includes links from other Web sites, is prohibited except by permission in writing.