One bit (on the mainframe) to rule them all

One bit (on the mainframe) to rule them all

Speakers: Jake Labelle, Security Researcher, Broadcom

Conference: DistrictCon

YouTube: https://www.youtube.com/watch?v=vy01_moXhv8

Overview

In this insightful talk from DistrictCon, Jake Labelle, a Security Researcher at Broadcom, delves into the intricate world of mainframe security, specifically focusing on the z/OS operating system. Labelle, leveraging his background as both an external consultant and an internal vulnerability researcher, exposes a fundamental architectural vulnerability that allowed for local privilege escalation to full system compromise. The core of the presentation revolves around how a single authorization bit, when combined with a long-standing programming pattern in critical IBM modules, could be weaponized to grant an attacker unfettered control over a mainframe system.

The significance of this research cannot be overstated. z/OS underpins the operations of virtually every major bank, insurance provider, and airline, making it a cornerstone of global critical infrastructure. A typical mainframe system can host thousands of local users, and as Labelle starkly illustrates, a successful local privilege escalation exploit on such a system is tantamount to achieving complete control over an organization's most sensitive data and operations. This talk serves as a crucial reminder that even in highly regulated and seemingly impenetrable environments, foundational vulnerabilities can persist for decades, awaiting discovery and exploitation.

Background

▶ Watch: Introduction to z/OS and its critical role (0:00)

Understanding the unique landscape of z/OS is crucial to appreciating the gravity of the presented exploit. Unlike modern x86-based systems, z/OS runs on z Architecture, a highly complex CISC (Complex Instruction Set Computer) design. Labelle humorously notes the challenge of reverse engineering, citing the 1,150-page "Principles of Operation" book that details every instruction, such as how a simple C strcpy function compiles down to a single VST move string assembly instruction.

The operational paradigm of z/OS is centered around the concept that "everything is a job." From user logins to system processes, all actions are submitted as JCL (Job Control Language) to an internal reader. These jobs execute asynchronously, with outputs written to a spool for later retrieval – a process that historically involved physical printouts being FedExed to developers for bug analysis, dubbed "dump reading." Each job runs within its own address space, theoretically isolating memory between processes. However, z/OS deviates from typical private memory models by introducing a distinction between private memory (editable by the program) and shared memory (addressable by every address space, akin to a kernel address space).

To prevent arbitrary access to this shared memory, z/OS employs a granular security mechanism: storage keys. Every 4KB page of memory is assigned a storage key (0-15), and each running program has a PSW (Program Status Word) that includes its own key. A program can only write to memory pages that share its key. The most critical key is key zero; a program operating in key zero can read and write to any memory location on the system, regardless of its page key. Consequently, the ultimate objective of any privilege escalation exploit on a mainframe is to achieve execution in key zero.

Key Findings

▶ Watch: Achieving 'key zero' via APF authorization (8:00)

The central discovery presented by Jake Labelle revolves around a specific mechanism for gaining key zero access: APF authorization. Programs can be designated as APF-authorized if they reside in an APF-authorized library (e.g., TCP/IP.TCPIP) and are linked with a special authorization code, AC1. When a program meets these criteria, a crucial internal bit, the JSCB auth bit, is set in its private memory. The presence of this bit then enables the program to execute a special privileged instruction: the mode set command (System Call Vector, SVC 107). This command allows the program to change its own PSW key, including elevating it to the all-powerful key zero.

The critical vulnerability arises from a long-standing, seemingly innocuous programming pattern found in core IBM modules. Labelle identified that a particular program, MVP main (also aliased as IESGANRMT), which is part of the standard SYS1.LINKLIB (an always APF-authorized system library), could be instructed to call any other program specified in its PARM (parameter) field within the JCL. Crucially, when MVP main called this secondary program, the JSCB auth bit remained set. This meant that an attacker could leverage an existing, APF-authorized MVP main execution to call their own arbitrary code, which would then inherit the APF-authorized state and thus be able to execute mode set to gain key zero.

The specific "gadget" discovered was the IESGANRMT module. This module, when called via MVP main with a specially crafted PARM string, would not only execute a specified program but also process the contents of register one (R1) in a way that allowed an attacker to dictate a branch target address. By placing their malicious code at a known offset within the PARM string and directing IESGANRMT to branch there, the attacker could achieve arbitrary code execution in an APF-authorized context, leading directly to key zero and full system control. Labelle highlights that this vulnerable pattern had existed on z/OS mainframes for "at least 20 odd years" before its public disclosure.

Technical Deep Dive

▶ Watch: The MVP main vulnerability and initial exploit attempt (10:00)

The exploit chain hinges on understanding how APF authorization is maintained across program calls and how a specific IBM module can be coerced into executing arbitrary code.

1. APF Authorization and the JSCB Auth Bit:

• A program becomes APF-authorized if its executable resides in an APF-authorized data set (a library). Common system libraries like SYS1.LINKLIB are always APF-authorized.
• Additionally, the program module itself must be linked with the authorization code AC1.
• When an APF-authorized, AC1-linked program is executed as a job step program (e.g., EXEC PGM=MVPMAIN), the system sets the JSCB auth bit in its process control block.
• This bit is the gatekeeper. If the JSCB auth bit is set, the program is permitted to issue privileged instructions, most notably SVC 107, the mode set command.
• The mode set command allows the program to alter its own PSW key. By setting the key to 0, the program gains unrestricted access to all system memory.

1. The Vulnerable Pattern: MVP main and PARM:

• The MVP main program, present on every z/OS system (often aliased as IESGANRMT), is designed to accept a PARM parameter in its JCL.
• This PARM parameter is interpreted by MVP main as a string that can specify another program to be called. For example, PGM=MVPMAIN,PARM='MYPROG' would instruct MVP main to call MYPROG.
• Crucially, when MVP main calls MYPROG, the JSCB auth bit (and thus the APF authorization) is inherited by MYPROG. This is where the security boundary breaks down. If MVP main is APF-authorized, any program it calls via PARM effectively becomes APF-authorized for the duration of its execution.

1. The IESGANRMT Gadget:

• While MVP main provides the initial APF-authorized call vector, the IESGANRMT module offers a specific, exploitable behavior. IESGANRMT is an alias for MVP main and resides in SYS1.LINKLIB.
• When IESGANRMT is called, it processes its input, including the PARM string. The critical behavior is how it handles register one (R1).
• IESGANRMT expects the PARM to contain a program name, followed by data that it loads into R1. After some internal processing, IESGANRMT will branch to an address derived from the value in R1 with a small offset (e.g., 00009600 as mentioned in the talk).
• This allows an attacker to control the execution flow. By crafting the PARM string to include the IESGANRMT module name itself (or an alias), followed by the address of the attacker's shellcode, the IESGANRMT program will eventually branch to the attacker's code.

1. Crafting the Exploit Payload:

• The attacker's goal is to execute SVC 107 (mode set) to switch to key zero.
• The payload consists of a small piece of z Architecture assembly code. For instance, the speaker demonstrates:
• 4110003C: Load Address (LA) R1, 3C (moves a value into R1, potentially preparing for the SVC call).
• 0A6B: The SVC 107 instruction (mode set).
• This payload is embedded within the PARM string, typically after the IESGANRMT program name and at the specific offset that IESGANRMT will branch to (e.g., 00009600).
• Due to the z Architecture being big-endian, the byte order of addresses and values within the payload needs to be correctly arranged.

Once the IESGANRMT module branches to this crafted code, the SVC 107 instruction executes. The program's PSW key is changed to 0, and its state is elevated to supervisor state, granting it complete control over the entire system, including the ability to manipulate any memory, access sensitive data, or modify system configurations.

Demo / Proof of Concept

▶ Watch: Successful key zero exploit and its system-wide impact (18:00)

Jake Labelle's demonstration clearly illustrated the exploit process, contrasting a failed attempt with the successful privilege escalation.

Initially, Labelle attempted to call a custom-written program containing the SVC 107 (mode set) instruction via MVP main. This program was compiled and placed in a non-APF authorized library (Jake.nor.loadlib). When executed, the system correctly identified that the program was "not executing with an authorization code of AC1" and terminated, demonstrating that simply calling any program via MVP main is not enough; the called program still needs the JSCB auth bit to be set, which only happens if the initial program (in this case, MVP main) is APF authorized and the called program inherits that context.

The successful proof of concept then demonstrated the full exploit chain:

1. The JCL was crafted to execute MVP main (PGM=MVPMAIN).
2. The STEPLIB (step library) was set to SYS1.LINKLIB, ensuring MVP main (and its alias IESGANRMT) was loaded from an APF-authorized data set.
3. The PARM parameter was meticulously constructed. It specified IESGANRMT as the program to be called internally, followed by a sequence of bytes. Crucially, at a specific offset (e.g., 00009600), the attacker's shellcode was embedded. This shellcode contained the 4110003C (Load Address R1) and 0A6B (SVC 107 for mode set) instructions.
4. The demonstration included WTO (Write To Operator) messages before and after the SVC 107 call to visually confirm the execution flow. The first WTO would appear, then the mode set would occur, followed by the second WTO, indicating successful privilege escalation.
5. Upon execution, the system's PSW at time of error output was examined. This critical output clearly showed a 0 in the key field, confirming the program was operating in key zero, and a C in the state field, indicating supervisor state. This validated that the arbitrary code (the mode set instruction) had been executed successfully, and the program had gained the highest level of privilege on the mainframe.

This demonstration effectively showcased how a combination of inherited authorization and a specific module's behavior could be exploited to bypass z/OS's fundamental security model, turning a local user into a superuser with complete system control.

Defensive Implications

▶ Watch: Q&A: Resources for further mainframe security exploration (20:00)

The findings presented by Jake Labelle carry significant defensive implications for organizations relying on z/OS mainframes. The vulnerability highlights a critical flaw in the assumption that APF authorization boundaries are always robust, especially when legacy code patterns are involved.

1. Binary Authorization State: Mainframes typically operate with a very stark authorization model: programs are either in "problem state" (severely restricted) or in "supervisor state" with key zero (unrestricted). There is little middle ground. This means a successful local privilege escalation immediately grants full system control, making such vulnerabilities extremely high-impact.
2. Review of APF-Authorized Programs: Organizations must conduct thorough audits of all APF-authorized programs, especially those that accept arbitrary input via PARM parameters or similar mechanisms. Any program that can call or load code based on user-supplied input, while maintaining its APF authorization, represents a potential gadget for privilege escalation.
3. Patching and Updates: The MVP main/IESGANRMT vulnerability, having existed for over two decades, underscores the importance of applying vendor-supplied patches promptly. While this specific vulnerability may now be patched, the underlying pattern of inherited authorization and exploitable module behavior could still exist in other, custom, or less-scrutinized authorized software.
4. Strict Input Validation: Programs that operate in an APF-authorized state and accept external input (e.g., via JCL PARM) must implement stringent input validation. They should sanitize or strictly control the content of these parameters to prevent the injection of malicious program names or shellcode.
5. Minimizing APF Authorization: The principle of least privilege should be applied rigorously. Only absolutely essential programs should be granted APF authorization. Reducing the attack surface by minimizing the number of authorized programs, and ensuring they are as tightly controlled as possible, can mitigate the impact of such vulnerabilities.
6. Continuous Security Research: The discovery of this decades-old vulnerability emphasizes the need for ongoing, dedicated security research into mainframe environments. The unique architecture and long operational history of these systems mean that hidden flaws can persist, requiring specialized expertise to uncover.

Key Takeaways

• Mainframe Security Foundation: z/OS security heavily relies on storage keys and APF authorization to enforce memory and privilege separation.
• The Power of a Bit: A single JSCB auth bit, when set due to APF authorization, grants a program the ability to execute the powerful mode set command (SVC 107), allowing it to elevate its privileges to key zero.
• Legacy Code Vulnerabilities: A programming pattern in core IBM modules like MVP main (aliased as IESGANRMT), which allows calling arbitrary programs specified in the PARM parameter while maintaining APF authorization, created a critical privilege escalation vector.
• Full System Compromise: Local privilege escalation on z/OS systems is equivalent to a full system compromise due to the binary nature of mainframe authorization (problem state vs. key zero/supervisor state).
• Exploitable Gadget: The IESGANRMT module in SYS1.LINKLIB served as a key "gadget," enabling attackers to inject and execute arbitrary assembly code by manipulating register one (R1) via a crafted PARM string.
• Enduring Threat: This vulnerability pattern persisted for "at least 20 odd years," highlighting the unique challenges and the long lifespan of critical vulnerabilities in mainframe environments.

About the Speaker(s)

Jake Labelle is a Security Researcher at Broadcom, where he focuses on internal vulnerability research for the company's various mainframe products. Prior to his current role, Labelle gained extensive experience as an external consultant, working with and testing the security of numerous client mainframes. His expertise extends to the deep technical intricacies of z/OS and z Architecture. He is also known for co-creating a DEF CON CTF challenge focused on 1970s IBM mainframe software, which was publicly available on GitHub, showcasing his commitment to community engagement and education in mainframe security.