1. Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization
Nathaniel Enos

2. Introduction Address Space Layout Randomization(ASLR)
Data Execution Prevention(DEP)
In early days, because of a lack of proper bound checking, the stack(return address) was easy to redirect to arbitrary code(shellcode) which was known as smashing the stack.
To migrate these attacks, canary value was introduced preceding the return value, compilers added verification routine
If modified, exit program
However, alternative control-flow constructs were used to bypass, such as structured exception handlers
In response, No-Execute(NX) bit was introduced
Allowed any page of memory to be marked as non-executable
DEP used the NX to terminate application if control flow was redirected to injected code

3. Introduction In response, attackers used code reuse attacks
Uses code already in memory (return-to-libc attacks)
These attacks were more recently extended to ret attacks using gadgets called return-oriented programming
All these attacks above rely on gadgets being located at known memory locations
Code Randomization!?
Code randomization hinders code reuse
Data randomization impedes the redirection of control-flow (hard to guess where to insert code)
Memory Disclosure…
Discloses a single address of the application in memory leading to every location in a single library (code reuse attack)
Violates fundamental assumptions of ASLR
Will Fine-grained ASLR even work?

4. Purpose
Prove that fine-grained ASLR implementations might not be any more effective then traditional ASLR.
Note: Entire code sequence is entirely within a single script
Also to shed light on the fact that this proposed and worked on defense, could be well short-sighted.

5. Need to Know 2 important concepts to understand: Code Reuse Attacks
Randomization for Exploit Mitigation

6. Code Reuse Attacks
Adversary writes a so-called ROP(return object programming) payload into application memory space(includes pointers and data for attack)
Exploit a vulnerability of the target program to hijack intended execution-flow
Once the overwritten function pointer is used by app, execution flow is redirected
By controlling Stack Pivot, the attacker can change stack pointer leading to beginning of payload

7. Code Reuse Attacks
5) By incrementation of the %esp (used in assembler code of functions) the first STORE gadget is pointed to by Return Address 1
Steps 5-7 are the same, increment %esp and Return Addresses point to respective addresses.
The combination of different gadgets allows an adversary to induce arbitrary program behavior

8. Randomization for Exploit Mitigation
Most current ASLR schemes randomize the base address of segments, such as stack, heap, libraries, and the executable itself.
However, today's ASLR realization suffer from two main problems:
Due to 32-bit systems entropy being to low, they are bypasses by brute-force attacks
Vulnerable to Memory Disclosure Attacks
Adversary gains knowledge of single runtime address and uses it to re-enable code reuse
Since current ASLR are randomized per-module level, a single address within a module reveals the location of every piece of code within that module

9. Assumptions Non-Executable Memory JIT Mitigations (OOS)
NX bit is applied to stack and heap
can not inject code
Same for executables and system libraries
can't over write existing code
JIT Mitigations (OOS)
randomized JIT pages
constant variable modifications
random NOP insertion
Export Address Table Access Filtering (OOS)
code outside module’s code segment can not access shared library’s export table
Base Address Randomization
assume base is randomized
Fine-Grained ASLR
is enforced in memory
permutes the order of functions
Basic blocks
swaps registers and replaces instructions
randomizes location of instructions
new randomization upon each run of app

10. Hypothesis
Multiple memory disclosures are an effective means to bypass fine-grained exploit mitigation techniques
Basic Concept of Attack:
Adversary making a new exploit only conform their memory disclosure to this interface and provide an initial code pointer and let the framework take over
Framework automatically harvest additional code pages, find API functions and gadgets, and “just-in-time” compile the attacker’s program and execute

11. Exploit Framework - Mapping Code Page Memory
By knowing a single valid code pointer, reveals the entire 4 KB page of memory.
Provide the single memory disclosure to the interface named DiscloseByte
One approach is to use this to implement DisclosedPage
Use static code to id direct and indirect call and jmp control-flow within page
New code pages are gathered from instructions in initial page
Direct code can yield an immediate hint to another code location
Indirect can yield often point to another module
use Import Address Table to disclose the address values

12. Harvest Code Pages
Using this algo, new code pages are discovered, static code analysis can be applied to process and store additional unique pages.
Iteration only continues till enough information is acquired to build a payload.

13. API Function Discovery
Exploits will inevitably need to interact with an OS’s APIs. This is vitally important, explaining the nature of this discovery. Using API calls is the preferred method of using system calls, as fast (syscall) change frequently per each revision of an OS.
3) Due to the page harvesting that occurred in step 2, these pages often contain API functions are they are frequently used in application code and libraries. By using these API functions the run-time addresses are easily obtained.
--Signatures are then created based on opcode sequences for call sites of the API functions, then match those signatures to call sites in the pages at run- time
Once a call site has been identified, we use DisclosePointer to reveal the API function pointer in the IAT and maintain the unique set of functions identified.

14. Gadget Discovery
4) By adapting the Galileo algorithm (OOS) to iterate over the collected pages, an instruction prefix tree can be populated.
The table contains instructions that are looked for. If matched, it’s added to unique set only if the initial instruction’s OUTREG is not nullified and the instructions do not have adverse side-effects such as accessing memory from an undefined register
Thus, creating a library at run-time of building blocks.

15. Just-In-Time Compilation
5 & 6) Compile exploited code
Challenge: Enough building blocks for exploit’s code? Each application can yield different gadgets. Thus a dynamic compilation is required to get as many types of gadgets as possible. Compiler is similar to normal, except is processed in exploit’s code. Due to being able to access gadgets, pointers are able to be created that point to API calls (kernel), which allows a large payload to be compiled.

16. Implementation ~3000 lines of C++ code
Use of libdasm library as a 3rd-party disassembler
Due to nature of code, a single JavaScript file(after compilation), it can be included into any HTML or Document-formatted supporting JavaScript

17. Proof of Concept Tested on IE 8 on a Windows 7 machine
The vulnerability is used to automatically load the calc application upon browsing a HTML file.

18. Evaluation
Success hinged on the ability to dynamically harvest memory pages consisting of executable code.
Tests were done offline as it allows for testing of initial code pages that would not be normally found in a POC. Using memory snapshots they were able to create a custom library which allowed the use of the Windows Debugging Library.
The snapshots were able to collect all metadata indicating if a page is marked as executable code, and auxiliary information on which pages belong to the application or a shared library.
Each box represents thousands of runs of HarvestCodePage of different applications.
IE indicated that over half of the starting points, 300 pages were harvested.
The top 25th percentile for FireFox and Adobe Acrobat Pro harvest over 1000 pages.

19. Evaluation
Using auxiliary info from the memory snapshots they were able to map the coverage of a single average-case run on IE. 307 pages total
They were able to find all the gadgets required for the POC, they also demonstrated that regardless of the initial code page, enough gadgets were found to build a payload.

20. Evaluation On API Function Discovery On Runtime Performance:
During code page discovery, it was commonly found that 10 or more of each function was found
On Runtime Performance:

21. Conclusion
“After much deliberation among the authors about ethical responsibilities, in the end, we believe that shedding light on fundamental weaknesses in current ways of thinking about exploit mitigation outweighs the potential downside of helping the next generation of hackers. If history serves any lesson it is that attackers will adapt and so must we in order to stay one step ahead. It is our hope that this work will inspire those more clever than ourselves to design more comprehensive defenses. “