Patent Application
20240378290
The field of the disclosure is security testing, or, more specifically, methods, apparatus, and products for detecting a security bypass through binary code analysis.
The development of the EDVAC computer system of 1948 is often cited as the beginning of the computer era. Since that time, computer systems have evolved into extremely complicated devices. Today's computers are much more sophisticated than early systems such as the EDVAC. Computer systems typically include a combination of hardware and software components, application programs, operating systems, processors, buses, memory, input/output devices, and so on. As advances in semiconductor processing and computer architecture push the performance of the computer higher and higher, more sophisticated computer software has evolved to take advantage of the higher performance of the hardware, resulting in computer systems today that are much more powerful than just a few years ago.
A secure computing platform presents a complex environment with many authorized interfaces and a large amount of authorized code. Authorized code or programs may be provided as part of the operating system or as part of specific products. Some authorized code may be provided by software vendors or created by customers. For security, platforms may use a fixed control block architecture where status information is maintained in system control blocks that can only be modified by authorized programs. Application programming interfaces (APIs) may be provided for changing these settings through the use of security services; however, programs with sufficient privilege levels can simply bypass the intended interfaces and set the bits directly, thus preventing the security products or services from fully controlling the settings for the system. While security bypasses of this nature may be made with good intentions, they compromise the system integrity of the system due to unintended consequences.
Methods, apparatuses, and products for detecting a security bypass through binary code analysis according to various embodiments are disclosed. detecting a security bypass through binary code analysis can include: identifying one or more authorized programs in a computing system, identifying one or more binary files of an authorized program; determining, based on a static code analysis of the one or more binary files, that the authorized program includes a potential security bypass, wherein the potential security bypass includes a modification of a system control block; and generating, in response to determining that the authorized program includes a potential security bypass, a security report.
The foregoing and other objects, features and advantages of the disclosure will be apparent from the following more particular descriptions of exemplary embodiments of the disclosure as illustrated in the accompanying drawings wherein like reference numbers generally represent like parts of exemplary embodiments of the disclosure.
Operating systems, such as the z/OS operating system, contain large amounts of authorized code, which is able to switch to or run in system key and modify system key control blocks. Some of this code is provided as part of the operating system or as part of specific products, while some is provided by software vendors or created by customers. The z/OS operating system includes a fixed control block architecture where status information is maintained in system control blocks that can only be modified by authorized programs. Certain interfaces are provided for changing these settings through the use of security services, however programs with sufficient privilege levels can simply bypass the intended interfaces and set the bits directly, preventing the security products or services for fully controlling the settings for the system. While security bypasses of this nature are usually made with good intentions, they compromise the system integrity of the system due to unintended consequences. In some cases, a security bit could be flipped on while a supervisor call or program call is executing under an unauthorized task, allowing a timer exit that interrupts that task to run with escalated privileges. In other cases, an unexpected error could cause the authorized program that flips the bit to leave it on, allowing any other work running from that point on in the address space to run with elevated privileges. In any case, bypassing the intended security interfaces for assigning privileges creates additional risks.
Two system control blocks of particular interest include that the accessor environment element (ACEE) control block and the job step control block (JSCB) in the z/OS operating system. While some features provided by access control facilities can detect security bypasses for the ACEE control block, they can only detect them if the code is driven while checking is active, after the bypass has occurred, and only analyzes the ACEE (i.e., not the JSCB or other potentially security relevant control blocks within z/OS). Another technique is to scan for two specific instructions, a LOAD followed by an OR IMMEDIATE instruction with specific offsets in supervisor call (SVC) routines. However, such a technique does not scan program call or AC(1) routines, and does not establish these instructions are really referencing control blocks of interest. Such a technique could also be easily fooled by making a minor modification to the program to escape detection, whereas a more robust solution could take that into account with code disassembly and analysis for more reliable results.
Embodiments in accordance with the present disclosure provide a security tool that scans all of this code, first locating the load modules of interest using established methods and then scanning, disassembling, parsing, and analyzing the resulting load modules in order to find instances of security relevant control block settings being manipulated directly instead of using established security interfaces that can be controlled by an installation. A static code analysis is employed to detect specific actions implemented by the analyzed code and a platform-specific security analysis is employed to identify security risks and bypasses presented by those actions.
A platform-specific security analysis is facilitated by understanding the system internals to detect when code is manipulating the security settings that allows for bypasses. Embodiments in accordance with the present disclosure identify platform-specific security bypasses using knowledge of platform control block structures, base pointers, and offsets to determine if specific bits are being set or cleared by the binary code and determine whether such manipulation creates a security risk. Embodiments in accordance with the present disclosure identify security risks by detecting privilege escalation risks related to platform security settings that affect user authority levels.
When such a security bypass is detected, for example an ACEE or JSCB modification, the line of code, load module, and library making the modification may be flagged as the source of a security bypass, and a report may be provided with the list of all security bypasses so appropriate action can be taken such as removing authorization from unsafe libraries or even deleting or uninstalling any products that are creating risks for the system.
Exemplary apparatus and systems for detecting a security bypass through binary code analysis in accordance with the present disclosure are described with reference to the accompanying drawings, beginning with
Stored in RAM 120 is an operating system 122. Operating systems useful in computers configured for detecting a security bypass through binary code analysis according to embodiments of the present disclosure include z/OS™, UNIX™, Linux™, Microsoft Windows™, AIX™, and others as will occur to those of skill in the art. The operating system 122 in the example of
Also stored in RAM is a security analysis tool 126 configured for detecting a security bypass through binary code analysis according to embodiments of the present disclosure. The security analysis tool 126 is a computer program configured to identify potential security risks, security bypasses, and privilege escalation in the authorized program 124. In some examples, the security analysis tool 126 is embodied in a set of computer program instructions that, when executed by the processor 110, cause the computing system 100 to carry out the automated steps of: identifying one or more authorized programs in a computing system, identifying one or more binary files of an authorized program; determining, based on a static code analysis of the one or more binary files, that the authorized program includes a potential security bypass, wherein the potential security bypass includes a modification of a system control block; and generating, in response to determining that the authorized program includes a potential security bypass, a security report. The authorized program may be, for example, an AC(1) program, a supervisor call (SVC) routine, or a program call (PC) routine, or a program in the Program Properties Table (PPT). The system control block may include security settings for a user, job, or environment, where the security setting includes a privilege and/or an authorization. The system control block may be, for example, an accessor environment element (ACEE) and a job step control block (JSCB). A security interface may be provided for changing the one or more security settings, where the modification of the system control block bypasses the security interface. In some examples, the static code analysis includes identifying a system control block architecture of an operating system; and determining, based on the system control block architecture, whether one or more processor instructions modifies a particular system control block field. The system control block architecture may include a control block chain defined by pointers and offsets.
The computing system 100 of
The example computing system 100 of
The exemplary computing system 100 of
For further explanation,
An authorized program 208 can run with an elevated privilege to access virtually any resource. For example, an authorized program can put itself into supervisor state or a system key, it can modify system control blocks, it can execute privileged instructions (while in supervisor state), and it can turn off logging. Thus, such authorization must be given out sparingly and monitored carefully. In the z/OS operating system, the system considers a program authorized if the program has one or more of the following characteristics: runs in supervisor state (bit 15 of the program status word (PSW) is zero); runs with PSW key 0-7 (bits 8-11 of the PSW are in the range 0-7); runs under an APF-authorized job step task. In some examples, an authorized program is linked to an access control code. In z/OS, for example, an authorized program may be linked with SETCODE AC(1). A program linked to AC(1) can use the MODESET service to switch to a supervisor state and system key. This is in contrast to a program that is not AC(1) which cannot make use of the MODESET service to switch to a supervisor state and system key. While in supervisor state, a program can execute restricted machine instructions. In storage protection (or system) key 0, a program can access all main storage of the computer. This means that it is possible for authorized programs to circumvent all standard z/OS security mechanisms and gain access to secured data.
The operating system 202 also includes authorized programs and services, including supervisor calls (SVCs) program calls (PCs), and exit routines. Many system functions, such as SVC or PC routines, are sensitive. Access to these functions must be restricted to only authorized programs to avoid compromising the security and integrity of the system.
An authorized program facility (APF) 210 is used to allow an installation to identify system or user programs that can use sensitive system functions. To maintain system security and integrity, a program must be authorized by the APF before it can access restricted functions, such as supervisor calls (SVC) or SVC paths. The APF helps to avoid integrity exposures as the installation identifies which libraries contain special functions or programs. These libraries are then called APF authorized libraries 212.
An installation can use the APF to identify system or user programs that can use sensitive system functions. For example, the APF allows an installation to restrict the use of sensitive SVC routines to APF-authorized programs and allow the system to fetch modules in an authorized job step task only from authorized libraries.
In the z/OS operating system, for example, APF-authorized programs must reside in one of the following authorized libraries: SYS1.LINKLIB; SYS1.SVCLIB, SYS1.LPALIB; authorized libraries specified by an installation, such as a library protected by an access control facility 214 (e.g., RACF in the z/OS operating system). Authorized libraries are defined in an APF list, or in the link pack area. Any module in the link pack area will be treated by the system as though it came from an APF-authorized library. An installation should ensure that it has properly protected libraries that contribute modules to the link pack area to avoid system security and integrity exposures, just as it would protect any APF-authorized library. The APF can also prevent authorized programs from using a load module that is not in an APF-authorized library.
For further explanation,
The computing system also includes at least one authorized program 314. An authorized program 314 may be linked to AC(1). For example, when the operating system 310 starts a new job step, the first program specified (the job-step program) must be linked to AC(1) and come from an authorized library for the step to run authorized. That program and subsequent programs in that step can execute programs from authorized libraries that do not have job-step authority. These programs, too, can run authorized. Thus, if the authorized program 314 can be run or manipulated to write in system key, this presents a serious security vulnerability. To identify such vulnerabilities, the computing system 300 also includes a security analysis tool 301 configured to detecting a security bypass through binary code analysis.
The method of
The method of
The method of
The security analysis tool 301 then determines whether any disassembled instruction or sequence of instructions potentially modifies a system control block security setting directly, i.e., without calling an appropriate security interface to modify the system control block. For example, the security analysis tool 301 can determine whether any instruction or sequence of instructions touches system control block storage for system control blocks of interest, regardless of whether the instruction is one that would traditionally be used to modify a system control block. The security analysis tool 301 can further determine whether any instruction or sequence of instructions modifies specific control block bits that may be used to bypass security facilities. In some examples, the system control blocks of interest include the ACEE control block and the JSCB control block. In the ACEE control block, security settings of interest can include the ACEEPRIV, ACEESPEC, and ACEEOPER fields. In the JSCB control block, security settings of interest can include the JSCBAUTH and JSCBPASS fields. When any of the disassembled instructions potentially modifies a field in a system control block that is usable to escalate privilege, the security analysis tool 301 identifies the instruction(s) as a potential security bypass improper privilege escalation, or other security risk.
Static code analysis only requires the binary code itself to be disassembled and evaluated and is therefore more flexible than dynamic testing, which can be dependent on environmental factors, variable workloads, or random input values. For example, some executable code might not even exist in a test environment unless it was a perfect replica of the production environment being evaluated. Further, watching for program checks or store and fetch violations could miss a whole class of security bypasses that do not cause program checks and seem to be working well until the code is disassembled. Still further, a target program can be written in different ways to modify data. Detecting specific actions being taken to bypass security though static code analysis allows for security risks to be detected that would have otherwise been missed.
The method of
For further explanation,
The static code analysis further includes determining 404, based on the system control block architecture, whether one or more processor instructions modifies a particular system control block field. In some examples, the security analysis tool 301 determines 404 whether one or more processor instructions modifies a control block field by identifying whether a sequence of instructions establishes the location of a system control block field of interest (e.g., the ACEE or JSCB) based on those instruction referencing pointers and offsets in the control block chain. The security analysis tool 301 the determines whether any instructions modify storage in the system control block with an emphasis on security fields such as ACEEPRIV, ACEESPEC, ACEEOPER, JSCBAUTH and JSCBPASS, as well as any other modification that could pose a risk. Determining that such a modification is attempted by the code would be based on knowing the locations of the anchors for the control block chains leading to the control blocks of interest as well as the offsets for the pointers leading to those control blocks and the offsets of significant bits or settings within those control blocks as well. As these anchor pointer locations and related offsets are fixed by the architecture of the operating system, identifying instructions that target these addresses and locations are candidates for potential security bypasses. However, the assembler code could be constructed to reference them in different ways, especially if attempted to evade detection. In one approach, the security analysis tool 301 focuses initially on the anchor pointer and offsets, regardless of the instructions being used to fetch data from those offsets and then finally to treat any instruction capable of modifying storage as a risk if it touches this storage, even if it is not a traditional instruction used to modify a control block like OR IMMEDIATE, such as a COMPARE and SWAP or a TRANSLATE instruction instead. In some implementations, the security analysis tool security analysis tool 301 may consider any instruction that can modify an ACEE or JSCB as a security risk.
In some cases, the inclusion of a security bypass may have good intentions. For example, security bypasses may be included to facilitate installation or configuration testing and then accidentally left in the final code, or may simply be the result of improper practices for system security. However, some security bypasses may be malicious and thus be configured to evade detection. Thus, in some examples, the security analysis tool 301 further scans the code for alternative means to reference the locations of security settings. For example, the security analysis tool 301 may detect that the instructions add X and subtract Y in order to arrive an address used to modify bits for a security setting.
Thus, a platform-specific security analysis is facilitated by understanding the system internals to detect when code is manipulating the security settings that allows for bypasses. The security analysis tool 301 identifies platform-specific security bypasses using knowledge of platform's control block structures, base pointers, and offsets to determine if specific bits are being set or cleared by the binary code and determine whether such manipulation creates a security risk. The security analysis tool 301 identifies security risks by detecting privilege escalation risks related to platform security settings that affect user authority levels.
Static code analysis in accordance with the present disclosure is performed without regard to the context of the binary code, thus there is no need to map code flows that can lead to false positives from incorrect maps. Further, the static code analysis can be performed against any executable code without the need for an environment for dynamic testing. The analysis can be performed independent of the system or state of the system where the code might eventually be executed. It can also be done on demand if modifications to authorized libraries are noticed.
Static code analysis in accordance with the present disclosure includes disassembling code not just to count occurrences of specific instructions or find text strings, but to analyze the control block structures and offsets being referenced by the instructions to determine if security relevant settings are being modified by the instructions. While counting junk or no-op instructions could have value for detecting code that has been modified or overwritten, it does not help to detect code that was written originally in a way that bypasses security and introduces risk.
In view of the explanations set forth above, readers will recognize a number of advantages of detecting a security bypass through binary code analysis according to embodiments of the present disclosure including:
Exemplary embodiments of the present disclosure are described largely in the context of a fully functional computer system for optimizing network load in multicast communications. Readers of skill in the art will recognize, however, that the present disclosure also may be embodied in a computer program product disposed upon computer readable storage media for use with any suitable data processing system. Such computer readable storage media may be any storage medium for machine-readable information, including magnetic media, optical media, or other suitable media. Examples of such media include magnetic disks in hard drives or diskettes, compact disks for optical drives, magnetic tape, and others as will occur to those of skill in the art. Persons skilled in the art will immediately recognize that any computer system having suitable programming means will be capable of executing the steps of the method of the disclosure as embodied in a computer program product. Persons skilled in the art will recognize also that, although some of the exemplary embodiments described in this specification are oriented to software installed and executing on computer hardware, nevertheless, alternative embodiments implemented as firmware or as hardware are well within the scope of the present disclosure.
The present invention may be a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.
The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.
Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.
Computer readable program instructions for carrying out operations of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present invention.
Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.
These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.
The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.
The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.
It will be understood from the foregoing description that modifications and changes may be made in various embodiments of the present disclosure without departing from its true spirit. The descriptions in this specification are for purposes of illustration only and are not to be construed in a limiting sense. The scope of the present disclosure is limited only by the language of the following claims.
