What Are the Categories of Mainframe Vulnerabilities?
November 21, 2018
Here at KRI, we’re focused on helping businesses take control of their mainframe security. A large part of that means developing and improving our vulnerability detection technology. It’s also important that we continue the conversation about mainframe vulnerabilities, especially system integrity vulnerabilities, because they are notoriously unheeded.
Mainframe system integrity vulnerabilities come in all different shapes and sizes, and they can have vastly different implications for the overall security of your systems. Common among them: they can all be triggered or exploited by a non-authorized user, someone who has no special privileges to access the system.
Here, we’ll break down some of the most frequently observed categories of these types of mainframe vulnerabilities, as well as what you need to know about each.
Trap Door (TD)
A Trap Door vulnerability is the most severe vulnerability found in z/OS integrity programs. That’s because trap door vulnerabilities enable a hacker to make changes directly to the environment.
There are two main types of TRAP DOOR Vulnerabilities. The first type occurs when the authorized service calls an address specified by the caller in an authorized state. The second type occurs when an authorized service returns control to the requestor in an authorized state. All TRAP DOOR vulnerabilities (regardless of type) allow the hacker to:
- Directly invoke authorized z/OS services
- Make changes to the operating system
- Make changes to system or application data
- Impersonate another user
- Change user’s z/OS authorization
- Disable logging (SMF)
- Disrupt z/OS operations (crash or failure)
Storage Alteration (SA)
Storage Alteration vulnerabilities are also severe vulnerabilities to z/OS integrity. They are less direct than trap door vulnerabilities. They don’t directly grant hackers total control of the environment. But, they do provide non-authorized users with the ability to alter some or all virtual memory. Altering memory can allow the hacker to:
- Invoke authorized z/OS services
- Make changes to the operating system
- Make changes to system or application data
- Impersonate another user
- Change user’s z/OS authorization
- Disable logging (SMF)
- Disrupt z/OS operation (crash or failure)
Trap Door and Storage Alteration vulnerabilities have similar capabilities, but the exploitation requirements are different. Storage Alteration vulnerabilities can require a bit more work in the exploit design phase.
System Instability (SI)
System instability vulnerabilities can cause z/OS service issues, the most severe being a system crash. These issues occur when authorized programs are not invoked properly as designed, and the program isn’t able to protect itself. An address space crashes or starts behaving erratically, or the entire system crashes.
Storage Reference (SR)
Storage reference vulnerabilities enable unauthorized users to exfiltrate sensitive data from fetch protected storage. Some aspects of the SPECTORE MELTDOWN vulnerability would be classified as STORAGE REFERENCE. Fetch protected storage is where PASSWORDS and other types of sensitive data (such as encryption keys in clear text or sensitive messages) would be kept.
User Key Common Storage
Recently KRI started tracking the usage of User Key Common Storage. IBM is discontinuing support for this type of virtual storage after z/OS release 2.3. As a result, programs that allocate this storage may no longer function properly. Businesses need to locate any use of User Key Common Storage.
What are the sub-categories?
Each vulnerability type may have subcategories. The subcategories indicate a difference in the environment at the time the exploitable instruction is executed. Examples of differences include PSW KEY, PSW State, Cross memory environment, and various z/OS authorities represented by APF (JSCBAUTH) and BYPASS PASSWORD PROTECTION (PPT NOPASS).
Example
A TDd (TRAP DOOR TYPE d) refers to a sub-category within the vulnerability type. For the most part, there is no difference in capability between any of the TRAP DOOR vulnerabilities, regardless of the value of d. D represents the state of the environment when the vulnerable instruction is executed. For example, the difference between a TD1 and TD2 is the PSW KEY. For TD1, the PSW key is 0. For TD2, the PSW key is 1-7. This means the exploiter would have to change the PSW KEY to 0 prior to trying to update key 0 storage for a TD2 vulnerability. No change would be required for a TD1.
Other vulnerability types also have subcategories. We’ll talk about those differences in a future blog.
At KRI, we began tracking system integrity vulnerabilities in 2009. Through the years, we’ve developed vulnerability scanning software that helps businesses quickly identify threats, so they can proactively take steps to better protect themselves from back doors provided in ISV software that is installed on their systems.
