Identifying exploitable code sequences

A system and method for identifying exploitable code sequences. In one implementation, a first processing device identifies an executable portion of a program and a set of registers of a second processing device, and stores a set of addresses in the set of registers. The first processing device allocates a region of memory populated with a set of values, and sets a stack pointer of the second processing device to point to a first location within the region of memory. The first processing device emulates an execution by the second processing device of an instruction at a first address of the executable portion. In response to determining that, after the emulating of the instruction at the first address, an address of a next instruction to execute after the instruction at the first address is in the set of addresses or the set of values, a signal is generated that indicates a potential exploitable code sequence.

TECHNICAL FIELD

The present disclosure is generally related to computer systems, and more particularly, computer security.

BACKGROUND

An exploitable code sequence (ICS) is a sequence of executable computer commands having one or more programming errors (“bugs”) or vulnerabilities that allow malicious behavior, such as gaining control of a computer system, escalating privileges, launching denial-of-service attacks, and so forth.

DETAILED DESCRIPTION

Described herein are methods and systems that enable identification of exploitable code sequences. As noted above in the Background, an exploitable code sequence (ECS) is a sequence of executable computer commands having one or more programming errors (“bugs”) or vulnerabilities that allow malicious behavior, such as gaining control of a computer system, escalating privileges, launching denial-of-service attacks, and so forth. Existing solutions attempt to identify ECSs in an executable program by checking a database of known ECSs for matches with code sequences of the executable program. However, ECS databases may not be complete in the sense that other ECSs may exist that are not in the databases; moreover, when a new ECS is discovered, ECS databases may not be updated in a timely manner.

Aspects of the present disclosure address the above and other deficiencies by providing a technology that enables identification of exploitable code sequences without the use of a database of known exploitable code sequences. Aspects of the present disclosure accomplish this by detecting code sequences of a program that read a register of a processing device that stores some address, and then continue execution (or “jump”) to the address read from the register. Such a code sequence could be exploited by a malicious hacker by storing in the register an address outside the executable program (e.g., a starting address of malicious code that the hacker has stored in another portion of memory outside the footprint of the executable program.) Aspects of the present disclosure detect such code sequences by storing a selected address in a register (e.g., some address outside of the program, some address in a non-executable portion of the program, etc.) and subsequently noting whether, after an emulation of the execution of the program, execution jumps to this selected address. If this occurs, then the code sequence that results in such a jump may be exploitable by a malicious hacker.

In some implementations of the present disclosure, the detection procedure described above is performed for multiple registers. For example, a first selected address may be stored in a first register, a second selected address may be stored in a second register, and so forth, and if execution jumps to any of the selected addresses, the code sequence is reported as potentially exploitable.

Some implementations of the present disclosure perform another check by allocating a region of memory, populating the region with a set of selected values (e.g., values of addresses outside of the program that are different than the addresses selected for storage in registers, values of addresses in a non-executable portion of the program that are different than the addresses selected for storage in registers, etc.), and setting the stack pointer to point to an instruction in the region of memory. If, after emulating an execution of the instruction, execution jumps to an instruction in the set of values, then the code sequence could potentially be exploited by a malicious hacker by placing specific addresses on the execution stack of the executable program, and using the code sequence to transfer control to a function of their choosing.

As described in detail below with respect toFIG. 3, in one implementation a first processing device identifies an executable portion of a program and a set of registers of a second processing device, and stores a set of addresses in the set of registers. The first processing device allocates a region of memory populated with a set of values, and sets a stack pointer of the second processing device to point to a first location within the region of memory. The first processing device emulates an execution by the second processing device of an instruction at a first address of the executable portion. In response to determining that, after the emulating of the instruction at the first address, an address of a next instruction to execute after the instruction at the first address is in the set of addresses or the set of values, a signal is generated that indicates a potential exploitable code sequence. In response to the signal, a developer may do one or more of the following: verify that the code sequence is exploitable; add the code sequence to a database of known exploitable code sequences; or modify the code of the program so that the sequence is no longer exploitable.

Accordingly, aspects of the present disclosure are capable of identifying a “new” exploitable code sequence, in the sense that the exploitable code sequence is not included in a database of known exploitable code sequences. When exploitable code sequences are identified and corrected (e.g., by modifying the code sequence to eliminate its exploitation potential, etc.), the operation of a computer system is improved by making the computer system less susceptible to certain exploits and thereby increase the security of the computer system.

FIG. 1depicts an illustrative computer system100, in accordance with one or more aspects of the present disclosure. As shown inFIG. 1, the computer system100includes a computing machine110, and a code repository170. The computing machine110and the code repository170may communicate via Ethernet, TCP/IP, Fibre Channel, USB, etc.

Code repository170is a persistent storage that is capable of storing executable programs. In some embodiments, code repository170might be a network-attached file server, while in other embodiments project repository170might be some other type of persistent storage such as an object-oriented database, a relational database, and so forth, that may be hosted by computing machine110.

Computing machine110may be a rackmount server, a router computer, a personal computer, a laptop computer, a tablet computer, or any combination of the above. Computing machine110includes a processor140and a memory device150. “Memory device” herein refers to a volatile or non-volatile memory device, such as Random Access Memory (RAM), Read-Only Memory (ROM), Electrically Erasable Programmable ROM (EEPROM), or any other device capable of storing data.

“Processor” herein refers to a device capable of executing instructions encoding arithmetic, logical, or I/O operations. In one example, a processor may follow Von Neumann architectural model and may include an arithmetic logic unit (ALU), a control unit, and a plurality of registers. In a further aspect, a processor may be a single core processor which is typically capable of executing one instruction at a time (or process a single pipeline of instructions), or a multi-core processor which may simultaneously execute multiple instructions. In another aspect, a processor may be implemented as a single integrated circuit, two or more integrated circuits, or may be a component of a multi-chip module (e.g., in which individual microprocessor dies are included in a single integrated circuit package and hence share a single socket). A processor may also be referred to as a central processing unit (CPU).

Computing machine110includes an operating system (OS)130that manages the hardware resources of the server machine and provides functions such as interprocess communication, scheduling, virtual memory management, and so forth. In one aspect, computing machine110also includes a debugging tool120that enables a user to step through program instructions; execute the instructions; and emulate execution of the instructions, rather than direct execution of the instructions by processor140.

In one aspect, computing machine110also includes a non-database-based (non-DB) exploitable code sequence (ECS) identification tool component125that enables identification of exploitable code sequences without the use of a database of known exploitable code sequences. Non-DB ECS identification tool125may perform one or more functions of methods200,300,400, and500(e.g., storing a set of addresses in a set of registers, determining whether a next instruction to execute is at an address in the set of addresses, etc.), as described in detail below with respect toFIGS. 2 through 5.

FIG. 2depicts a flow diagram of one example of a method200for identifying exploitable code sequences, in accordance with one or more aspects of the present disclosure. The method is performed by processing logic that comprises hardware (circuitry, dedicated logic, etc.), and that may also comprise computer programs (such as is run on a general purpose computer system or a dedicated machine). In one implementation, method200is performed by processing device140of computing machine110, and one or more blocks of the method may be performed by non-DB ECS identification tool125. It should be noted that in some implementations blocks depicted inFIG. 2may be performed simultaneously or in a different order than that depicted. It should further noted that, for space reasons, some blocks inFIG. 2may comprise a plurality of sub-blocks (e.g., multiple tasks, etc.), and the sub-blocks may be performed simultaneously or in a different order than that depicted

At block201, a set R of one or more registers of a processing device is identified, and a set E of one or more executable portions of a program (as opposed to data portions of the program, for example) is identified. In one example, the set R of register(s) does not include either the program counter or the stack pointer of the processing device, because addresses outside the executable program cannot be stored in these registers by the executable program, which is in user space, rather than in a kernel. In contrast, such addresses can be stored in other registers by executable programs in user space.

In some examples, the processing device executing the method200(e.g., processing device140, etc.) might be different than the processing device comprising the set R of register(s), while in some other examples the two processing devices may be the same. In the former case, the processing device comprising the set R of register(s) might be of a different type than the processing device executing method200(e.g., one processing device might be an Intel x86 processor and the other might be an ARM-based processor, etc.).

At block202, variable P is set to an executable portion in set E, variable n is set to the number of instructions in portion P; and variable j is initialized to 1. Variable P iterates through the executable portions in set E. For example, if set E has three executable portions, then the ECS identification tasks described below are performed for one of the executable portions in set E, then a second one of the executable portions in set E, and then the third executable portion in set E. The way that this occurs is as follows: as described above, variable P is set to an executable portion in set E; then after the ECS identification tasks described below are performed for executable portion P, executable portion P is removed from the set E of executable portions (block216below), and variable P is set to one of the remaining executable portions in set E, if set E is non-empty (block217below). If set E is empty, then all of the identified executable portions have been processed.

At block203, a set A of addresses is stored in registers R, as previously described atFIG. 1. For example, a first address of set A might be stored in a first register of set R, a second address of set A might be stored in a second register of set R, etc.). As described below, method200checks whether execution of the program proceeds (“jumps”) to an address stored in registers R, in which case the pertinent code of the program may be vulnerable to hijacking or other types of malicious behavior.

At block204, a region of memory is allocated and populated with a set of values B, and the stack pointer of the processing device is set to point to a location within the region. In one example, the particular location is selected to be approximately halfway within the region of memory, as a heuristic. As described below, method200checks whether execution of the program jumps to an address in set B, in which case the pertinent code of the program may again be vulnerable to hijacking or other types of malicious behavior.

At block205, a variable q is set to the address of the jthinstruction in portion P, and a counter c is initialized to 1. At block206, the instruction at address q is either executed directly, or its execution is emulated (e.g., by debugging tool120, etc.).

At block207, a variable z is set to the address of the next instruction to execute. Block208checks whether z equals to an address in either set A or set B. If so, the execution of method200proceeds to block209, otherwise execution continues at block209.

At block209, the potential ECS discovered at blocks207and208is reported and analyzed. In one implementation, the potential ECS is reported via a signal (e.g., a message, etc.), and the signal may specify one or more of the following:the sequence of instructions in the program associated with the potential ECS;a starting address of the potential ECS;a particular instruction within the potential ECS that sets the value of a register in set R; ora particular instruction within the potential ECS that changes the value of a register in set R.

Block210checks whether variable z (which was set at block207) is outside the address ranges of all the executable portions E. If not, which indicates that a vulnerability has not been found in the current code sequence, execution proceeds to block211, otherwise execution continues at block214.

At block211, counter c is incremented by 1. Block212checks whether counter c, which represents the number of instructions of portion P, is less than a threshold. In one implementation, the threshold represents a “cutoff” at which time the method infers that portion P contains an infinite loop, and consequently stops testing portion P, for otherwise the current code sequence will be checked for vulnerabilities forever. If counter c is less than the threshold, execution proceeds to block213, otherwise execution continues at block214.

Block213sets variable q to variable z, so that the next execution of the loop continues at the next instruction in the sequence. (Recall that z is the address of the next instruction to execute. Also note that the next instruction to execute is not always the immediately-following instruction, so the method uses these variables q and z to advance through instructions of the code sequence, rather than using an index that is incremented at each iteration.) Execution then continues back at block206.

Block214advances variable j, where the advancing may depend on the architecture of the processing device; for example, for some processing devices variable j may be incremented by 1, while for some other processing devices (e.g., RISC processors, etc.), variable j may be incremented by a larger integer. (Note that in this case an index is used because the method checks for an exploitable code sequence beginning at the first instruction, then checks for an exploitable code sequence beginning at the second instruction, and so forth. Also note that a code sequence beginning at the second instruction is not just the code sequence beginning at the first instruction, without the first instruction. Rather, these code sequences can differ in other ways due to test-and-branches, the states of variables, jumps, and so forth.)

Block215checks whether j<=n. If so, execution continues back at block203, otherwise execution proceeds to block216.

At block216, portion P is removed from set E, because it has already been processed, and at block217, execution branches based on whether set E is non-empty after the removal of P. As described above at block202, if E is non-empty, then there are still one or more executable portions to be processed, and execution continues back at block202to process the next executable portion. Otherwise, there are no more executable portions to process, and method200terminates.

FIG. 3depicts a flow diagram of another example of a method300for identifying exploitable code sequences, in accordance with one or more aspects of the present disclosure. The method is performed by processing logic that comprises hardware (circuitry, dedicated logic, etc.), and that may also comprise computer programs (such as is run on a general purpose computer system or a dedicated machine). In one implementation, method300is performed by processing device140of computing machine110, and one or more blocks of the method may be performed by non-DB ECS identification tool125. It should be noted that in some implementations blocks depicted inFIG. 3may be performed simultaneously or in a different order than that depicted.

At block301, an executable portion of a program (e.g., a program stored in repository170, etc.) and a set of registers of a processing device are identified. In one example, the set of registers does not include either the program counter or the stack pointer of the processing device.

At block302, a set of addresses is stored in the set of registers (e.g., a first address in the set of addresses is stored in a first register of the set of registers, a second address in the set of addresses is stored in a second register of the set of registers, etc.). As described below, method300checks whether execution of the program jumps to an address stored in the set of registers, in which case the pertinent code of the program may be vulnerable to hijacking or other types of malicious behavior.

At block303, a region of memory is allocated and populated with a set of values, and the stack pointer of the processing device is set to point to a first location within the region. In one example, the first location is approximately halfway within the region of memory. As described below, method300checks whether execution of the program jumps to an address in the set of values stored in the region of memory, in which case the pertinent code of the program may again be vulnerable to hijacking or other types of malicious behavior.

At block304, execution of an instruction at a first address of the executable portion is emulated (e.g., by debugging tool120, etc.). Block305checks whether the address of the next instruction to execute is in the set of addresses or the set of values. If so, the execution of method200proceeds to block310, otherwise execution proceeds to block306.

At block306, the set of addresses is stored in the set of registers (this is done again because the contents of the registers may have changed by the instruction at the first address). At block307, the allocated region of memory is populated with the set of values (again this is done in case the contents of the region has changed by the instruction at the first address), and the stack pointer is set to point to a second location within the region. In some examples, the second location within the region might be different than the first location within the region, while in some other examples the two locations might be the same.

At block308, execution of an instruction at a second address of the execution portion is emulated. Block309checks whether the address of the next instruction to execute is in the set of addresses or the set of values. If so, the execution of method300proceeds to block310, otherwise execution of the method terminates.

At block310, a signal is generated indicating a potential ECS. In one implementation, the signal may specify one or more of the following:the sequence of instructions in the program associated with the potential ECS;a starting address of the potential ECS;a particular instruction within the potential ECS that sets the value of a register in the set of registers; ora particular instruction within the potential ECS that changes the value of a register in the set of registers.

FIG. 4depicts a flow diagram of another example of a method400for identifying exploitable code sequences, in accordance with one or more aspects of the present disclosure. The method is performed by processing logic that comprises hardware (circuitry, dedicated logic, etc.), and that may also comprise computer programs (such as is run on a general purpose computer system or a dedicated machine). In one implementation, method400is performed by processing device140of computing machine110, and one or more blocks of the method may be performed by non-DB ECS identification tool125. It should be noted that in some implementations blocks depicted inFIG. 4may be performed simultaneously or in a different order than that depicted.

At block401, an executable portion of a program (e.g., a program stored in repository170, etc.) and a set of registers of a processing device are identified. In one example, the set of registers does not include either the program counter or the stack pointer of the processing device.

At block402, a set of addresses is stored in the set of registers (e.g., a first address in the set of addresses is stored in a first register of the set of registers, a second address in the set of addresses is stored in a second register of the set of registers, etc.). As described below, method300checks whether execution of the program jumps to an address stored in the set of registers, in which case the pertinent code of the program may be vulnerable to hijacking or other types of malicious behavior.

At block403, a region of memory is allocated and populated with a set of values, and the stack pointer of the processing device is set to point to a first location within the region. In one example, the first location is approximately halfway within the region of memory. As described below, method400checks whether execution of the program jumps to an address in the set of values stored in the region of memory, in which case the pertinent code of the program may again be vulnerable to hijacking or other types of malicious behavior.

At block404, execution of an instruction in the executable portion is emulated (e.g., by debugging tool120, etc.). Block405checks whether the address of the next instruction to execute is in the set of addresses or the set of values. If so, execution proceeds to block406, otherwise the execution of method400terminates.

At block406, a signal is generated indicating a potential ECS. In one implementation, the signal may specify one or more of the following:the sequence of instructions in the program associated with the potential ECS;a starting address of the potential ECS;a particular instruction within the potential ECS that sets the value of a register in the set of registers; ora particular instruction within the potential ECS that changes the value of a register in the set of registers.

FIG. 5depicts a flow diagram of another example of a method500for identifying exploitable code sequences, in accordance with one or more aspects of the present disclosure. The method is performed by processing logic that comprises hardware (circuitry, dedicated logic, etc.), and that may also comprise computer programs (such as is run on a general purpose computer system or a dedicated machine). In one implementation, method500is performed by processing device140of computing machine110, and one or more blocks of the method may be performed by non-DB ECS identification tool125. It should be noted that in some implementations blocks depicted inFIG. 5may be performed simultaneously or in a different order than that depicted.

At block501, an executable portion of a program (e.g., a program stored in repository170, etc.) and first and second registers of a processing device are identified. In one example, the first and second registers are neither the program counter nor the stack pointer of the processing device.

At block502, a first address is stored in a first register and a second address is stored in a second register. As described below, method500checks whether execution of the program jumps to the first address or the second address, in which case the pertinent code of the program may be vulnerable to hijacking or other types of malicious behavior.

At block503, execution of an instruction in the executable portion is emulated (e.g., by debugging tool120, etc.).

Block504checks whether the address of the next instruction to execute is the first address or the second address. If so, execution proceeds to block505, otherwise the execution of method500terminates.

At block505, a signal is generated indicating a potential ECS. In one implementation, the signal may specify one or more of the following:the sequence of instructions in the program associated with the potential ECS;a starting address of the potential ECS;a particular instruction within the potential ECS that sets the value of the first register or the second register; ora particular instruction within the potential ECS that changes the value of the first register or the second register.

FIG. 6depicts a block diagram of an illustrative computer system600operating in accordance with one or more aspects of the present disclosure. In various illustrative examples, computer system600may correspond to a computing device within system architecture100ofFIG. 1. Computer system600comprises a memory and a processing device that may include components to enable identification of potential ECSs. In one example, the processing device may include an identification module610, a register storage module620, a memory allocation module630, a program counter setting module640, an emulation module650, and a signal generation module660.′

In one implementation, identification module610identifies an executable portion of a program and a set of registers of a processing device. Register storage module620stores a set of addresses in the set of registers. Memory allocation module630allocates a region of the memory populated with a set of values. Stack pointer setting module640sets a stack pointer of the second processing device to point to a first location within the region of memory. Emulation module650emulates an execution by the processing device of an instruction in the executable portion. Signal generation module660determines that, after the emulation, an address of a next instruction to execute is in the set of addresses or the set of values, and in response generates a signal that indicates a potential exploitable code sequence.

FIG. 7depicts a block diagram of another illustrative computer system700operating in accordance with one or more aspects of the present disclosure. In various illustrative examples, computer system700may correspond to a computing device within system architecture100ofFIG. 1. The computer system may be included within a data center that supports virtualization. Virtualization within a data center results in a physical system being virtualized using virtual machines to consolidate the data center infrastructure and increase operational efficiencies. A virtual machine (VM) may be a program-based emulation of computer hardware. For example, the VM may operate based on computer architecture and functions of computer hardware resources associated with hard disks or other such memory. The VM may emulate a physical computing environment, but requests for a hard disk or memory may be managed by a virtualization layer of a host machine to translate these requests to the underlying physical computing hardware resources. This type of virtualization results in multiple VMs sharing physical resources.

In a further aspect, the computer system700may include a processing device702, a volatile memory704(e.g., random access memory (RAM)), a non-volatile memory706(e.g., read-only memory (ROM) or electrically-erasable programmable ROM (EEPROM)), and a data storage device716, which may communicate with each other via a bus708.

Computer system700may further include a network interface device722. Computer system700also may include a video display unit710(e.g., an LCD), an alphanumeric input device712(e.g., a keyboard), a cursor control device714(e.g., a mouse), and a signal generation device720.

Data storage device716may include a non-transitory computer-readable storage medium724on which may store instructions726encoding any one or more of the methods or functions described herein, including instructions for implementing methods200,300,400, and/or500ofFIGS. 2 through 5.

Instructions726may also reside, completely or partially, within volatile memory704and/or within processing device702during execution thereof by computer system700, hence, volatile memory704and processing device702may also constitute machine-readable storage media.