What is the IBM z/OS Authorized Code Scanner (zACS)?The IBM z/OS Authorized Code Scanner is an optional priced feature designed to help users protect the integrity of their z/OS system. The scanner targets program call and supervisor call routines which may be run by unauthorized callers, and alerts users to potential integrity vulnerabilities within these routines. Here is a quick rundown of the importance of zACS and how you can get started using it today.
What is System Integrity? System integrity is the inability of any program not authorized by a mechanism under the installation’s control to circumvent or disable store or fetch protections, access a resource protected by a Security Server/Manager, or obtain control in an authorized state. An authorized state refers to having a supervisor state, a protection key less than eight, or Authorized Program Facility (APF) authorization.
What are Program Call and Supervisor Call Routines? Program Call (PC) and Supervisor Call (SVC) routines have the architectural capability, depending on how they are defined, to allow an unauthorized program to invoke them, yet execute in an authorized state. PCs and SVCs provide a variety of critical services to z/OS. Some are created and maintained by IBM or IBM business partners as part of core z/OS subsystems and middleware products, while others are created by vendor applications for z/OS. Some are implemented by system programmers to provide specialized in-house functionality for a client’s enterprise.
What is the Risk? If a PC or SVC is improperly implemented there is a possibility of a fetch violation, where the routine inadvertently allows the caller to view some portion of memory that it shouldn’t be able to (CVSS score: 6.5), or a store violation, where the PC or SVC routine inadvertently allows the caller to update some portion of memory that it shouldn’t be able to (CVSS score: 8.8). This would mean there is the potential for an unauthorized caller to update system control blocks, perhaps even control blocks associated with the security of the system. Given this risk, there is a need to discover potential vulnerabilities that might exist, regardless of who implemented that code, and to remediate them, before they might be exploited.
How do I Mitigate the Risk? The IBM z/OS Authorized Code Scanner provides the ability to test PCs and SVCs for integrity violations on a given dev/test z/OS instance, of V2R4 and above. zACS is designed to detect situations in which an unauthorized caller could be incorrectly granted an authorized state by detecting potential vulnerabilities within PCs and SVCs, and to generate a detailed report to assist the user in debugging any potential vulnerabilities found.
What should I be aware of before using zACS? By design, zACS generates many ABENDs and suppresses many dumps. Due to its volatile nature, it is meant to be run in development and test environments only. Both the input and output data sets contain sensitive data, as the input determines the scope of the scan and the output may describe potential vulnerabilities found on z/OS, and their respective locations. Therefore, these data sets, along with the REXX execs that help generate the tests, must be properly protected by an external security manager product such as RACF. As with any scanning tool, there may be programmer errors that cannot yet be detected and conversely the tool may produce some false positives. Fundamentally, zACS provides a new, foundational cybersecurity analysis via patented algorithms that dynamically scan PC and SVC code on z/OS, supporting the growing movement of DevSecOps.
How to Run zACS: The tool consists of a started task, a set of REXX execs, and associated data sets. The started task runs authorized while the tests generated by the REXX execs do not.
Step 1: Initialize the started task.
Step 2: Run the batch jobs that generate the PC & SVC tables. It’s important to run these each time for accuracy. PCs in particular can be easily added, deleted, and added back dynamically, with a different PC number possible each time.
Step 3: Run the REXX either directly or through the ISPF panel. This will generate the test cases for all those PCs & SVCs to run in batch. These tests are context-free; they have no inside knowledge of a particular API’s parameter list format and yet there’s no manual tailoring needed. In many cases they’re able to test multiple levels of indirection on those parameters.
Note: There are filtering options for both inclusion & exclusion.
- If you’ve run the tool before and want to rerun to capture a dump, you can include only specific PCs or SVCs to save time.
- If you’ve run the tool before and confirmed that one of the hits is a false positive, you may opt to save the diagnostic information & exclude that from the subsequent runs.
Step 4: Wait for the completion of all the batch jobs, and then you can examine the output
How to Interpret the Output: Example output:
*Note this vulnerability was intentionally created for demonstration purposes
When a potential vulnerability is detected, you will be provided with various data for diagnosis in the output data set that can be forwarded to the owner of the code to be diagnosed. The data provided will depend on the type of error hit. It may include:
- The ABEND code and reason associated with the hit
- The Program Status Word (PSW) at the time of error
- The machine code of the failing instruction and its assembler translation.
- The possible CVSS score
- The target or source address causing the exception
- The breaking event address
- A sample slip to use on rerun to capture a dump
- General use register contents before and after the error
- Access register contents
If a potential storage overlay is detected, a snippet of the storage before and after the error will also be displayed with its associated information. The module name and offset associated with the hit can be used to locate potential vulnerability in code. Activities with this scanner can be considered an extension of your existing service process. The 3-character prefix of the module name tells you who owns the code so that you know whom to contact with the diagnostics. Further output examples, as well as code examples of common vulnerabilities and their fixes can be found in the IBM z/OS Authorized Code Scanner Guide.
In Conclusion The challenge of finding programming errors in code integrity is that the code base largely functions normally in general forms of testing. PC and SVC routines frequently implement a critical boundary between unauthorized users and authorized code. Any z/OS instance can contains dozens, at times hundreds of these routines. They are built into applications, middleware, and the operating system itself. They are created by IBM, the z/OS vendor community, and by clients' in-house application developers. The z/OS Authorized Code Scanner provides the ability to scan these routines and provides diagnostic information for any potential vulnerabilities found. For more information, refer to the IBM z/OS Authorized Code Scanner Guide found at
www.ibm.biz/zacskc2020 .