A JOP GADGET DISCOVERY AND ANALYSIS TOOL.
Date | 22 September 2020 |
Author | Brizendine, Bramwell |
-
INTRODUCTION
Exploits harness software vulnerabilities that have been weaponized to enable the attacker to perform arbitrary actions that may be benign as well as malicious. Code-reuse attacks have become commonplace as a fundamental part of many modern exploits, due to many mitigations that have evolved, including ASLR, DEP, EMET, and CFG. These mitigations are intended to harden software against exploitation. Code-reuse attacks though can enable an attacker to bypass or effectively neutralize various mitigations. The predominant code-reuse attack has been Return-oriented Programming ("ROP"), which evolved out of a more limited return-to-libc [1]. However, other code-reuse attacks exist, such as the seldom used, seldom studied Jump-oriented Programming ("JOP").
Software exploitation has evolved in complexity significantly over the last decade, with numerous mitigations having been developed, each only to be quickly overcome by determined attackers. Mitigations often cannot prevent attacks, but may raise the level of difficulty, requiring new bypasses to be found. Very often in modern exploits, some type of code-reuse attack has been necessary to accomplish this, and this has almost invariably been ROP in a Windows environment.
Code-reuse attacks can be challenging for novice students to understand and to be able to implement successfully. This is particularly true of JOP, as there has been an absence of tools to facilitate discovering the necessary JOP gadgets to perform this type of attack. To try to frame such an attack would require the usage of several tools, some being used in a somewhat roundabout fashion.
There are a variety of well-developed tools that attempt to automate the analysis of software to discover ROP gadgets, such as Mona and ROPgadget, allowing for these gadgets to be used to construct ROP chains. Some of these tools provide additional features of use to exploit developers, such as providing pre-set ROP chains and helping exclude bad characters from results. For JOP, there is nothing comparable. Without the presence of appropriate tools, a manual process for gadget discovery must be undertaken, and a user must manually evaluate found gadgets to determine if they are useful. Undertaking such a manual approach could conceivably take many hours or even days and yet still not be fruitful. One prominent researcher spent weeks to find a couple dozen gadgets that met certain classification criteria for Turing-complete features. This was work done by manually looking at disassembly from a Solaris libc file, and it was using the far simpler ROP. Without proper tools, a manual undertaking seeking JOP could be a highly time-consuming effort [2].
To address these issues, this work proposes a framework which could be used to automatically discover JOP dispatcher gadgets, discover JOP functional gadgets, exclude impractical JOP gadgets, classify JOP gadgets by operations performed, and provide for user to customize the types of gadgets sought. The artifact produced by this research will be the Jump-oriented Programming Reversing Open Cyber Knowledge Expert Tool, the JOP ROCKET. This is a novel framework for JOP that can help facilitate binary analysis for exploit development and code-reuse attacks.
This research proposes an instantiation of an interactive tool to facilitate the discovery of JOP gadgets and to more easily allow JOP exploits to be constructed. This tool would be of benefit to the educational community by providing a tool that can help students to be able to utilize JOP in exploits. It will greatly simplify efforts of students of reverse engineering and software exploitation to be able to utilize this type of code-reuse attack. Without such a tool, likely the level of difficulty and time-consuming, tedious nature of the work would make the prospect of performing JOP virtually infeasible for students and indeed most practitioners.
JOP is also far more limited than ROP, under the most ideal of circumstances. This is due to a much reduced attack surface on average. Although it is more challenging to use, JOP remains a valid and viable attack paradigm, one which can be powerful. Some tools, such as ROPgadget and Mona provide extremely limited functionality, but to such a limited extent as to be of only very marginal value [3, 4]. That is to be expected, as these are ROP tools, and they are highly effective in their problem domain; both provide an abundance of functionality and tools to help make the construction of ROP gadget chains uncomplicated and simple. That ease and functionality provided by those tools, is lacking within the province of JOP. As a far more complicated form of code-reuse attacks, the argument could be made that it more strongly needs some of that automation.
The problem is there is a lack of tools to automate and facilitate building JOP exploits, as the current workflow makes it a manual, tedious, time-consuming process [5, 6, 7, 8, 9, 10]. A versatile, powerful framework that can account for the complexity of JOP would provide a solution to this research problem.
-
LITERATURE REVIEW
One direct way to achieve enhanced cyber security is through protections at a binary or system level, to prevent a malicious action from taking place in the first place. Inevitably, the continued development of numerous attacks utilizing memory corruption bugs have led to the development of various protections and mitigations over the years [11]. Broadly, these efforts have been designed to curtail or stymie such attacks. The situation evolved to what could be described as an escalating arms race, with both defenders and attackers, continuously innovating and improving techniques, alternatively to overcome protections or to thwart defenses. These mitigations include stack cookies, Data Execution Prevention ("DEP"), Address Space Layout Randomization ("ASLR"), Enhanced Mitigation Experience Toolkit ("EMET"), and Control Flow Guard ("CFG"), to name a few of the most well-known ones that are most prevalent today.
-
DATA EXECUTION PREVENTION
Microsoft attempted to provide mitigation against shellcode attacks with Data Execution Prevention ("DEP"). This was in response to vulnerabilities that had arisen out of buffer overflows. This dealt with memory pages, and it prevented code that was readable and writeable from also being executable [12]. With DEP in place, attempting to execute memory protected by DEP will result in an access violation and program termination. As a mitigation, DEP's utility is limited, as various ways have been devised to bypass it, most commonly involving ROP and function calls to VirtualAlloc or VirtualProtcct. Once DEP has been bypassed, then it is possible to have a region of memory that is both readable and writable as well as executable, meaning an attacker could write and execute shell-code at the same location.
-
ASLR
Address Space Layout Randomization ("ASLR") was designed to provide a challenge against ROP. ASLR randomizes the regions of memory, including the heap, parts of the stack, as well as module base addresses. ASLR makes it unknowable where certain items will be in memory. Prior to ASLR, these memory addresses would typically be predictable, based on different factors, such as operating system, software version number, etc. However, there have been a couple problems associated with ASLR. Memory disclosures can allow for it to be overcome; once a memory disclosure is found, offsets can then be calculated to figure out addresses of desired functions or gadgets, thereby negating the effect of ASLR. The second problem was low entropy in terms of randomization for ASLR. This meant memory addresses were not predictable, but they could be brute-forced, though this has since been remediated by introducing high entropy ASLR with x64 Windows 8 and up.
-
CONTROL FLOW INTEGRITY
Control flow integrity ("CFI") could be used as a final solution to code-reuse attacks, although a perfect implementation of CFI has yet to be developed. An imperfect implementation of CFI can certainly be vulnerable to exploitation. CFI refers to how an operating system may implement the natural control flow graph for a program for which it was intended. The principle behind CFI is to determine an application's control flow graph before program execution, allowing the control flow graph to be used to require that control flow adheres to paths defined in the control flow graph. CFI can be either looser or stricter, i.e. fine-grained or coarse-grained. Failure to follow said paths as set forth in the control flow graph generally results...
-
To continue reading
Request your trialCOPYRIGHT GALE, Cengage Learning. All rights reserved.