Gideon: A High Performance HW Interface for Guaranteed Detection of Executed Injected Malicious Code (Internal Project 2013)
Malicious code injection comes in many forms: One of the most popular ones is an adversary who exploits buffer overflow vulnerability in a function call to inject malicious code and overwrite the stack return address to point at the injected malicious code. Another example is where code injection takes place while application code switches context to a compromised OS allowing an adversary to modify the binary of the application code. Several defense strategies have been proposed: e.g. using a randomized memory layout such that an attacker does not know which address points at the malicious code, using read-only instruction memory and no-executable data memory, comparing a hash of the instruction memory with an expected hash, using a small formally verified OS that provides application isolation, using an intrusion detection system that attempts to detect malicious network traffic that is used to compromise servers, sand-boxing to detect malicious execution behavior, etc. None of these techniques are full proof: adversaries have been able to find their way around these defense mechanisms. We must conclude that adversaries are able to modify program control flow.
This leads us to the question whether it is possible to at least design Gideon (acronym for Guaranteed Intrusion Detection Engine): a (high performance) security layer/wrap around application code binary, possibly together with a trusted HW module, which (1) gives an explicit guarantee around the false positive rate (normal control flow behavior is detected as being malicious) and (2) outputs the set of attack points of which (provably) at least one must be used to launch a successful remote attack which maliciously modifies the program control flow. Our objective is to balance the false positive rate with the number of possible attack points.
Oct. 1, 2013 – Oct. 1, 2015
Year 1 (Due Oct. 1, 2014): Analyze and simulate the performance of a single core processor extended with Gideon for detecting malicious program control flow behavior (in particular, malicious code execution).
Emulate Gideon in a real setting. E.g., we want to demonstrate how Gideon detects execution of adversarial scripts injected by an attacker exploiting web browser vulnerabilities or Acrobat reader vulnerabilities.
Year 2 (Due Oct. 1, 2015): Extend Gideon to do instruction verification per function call (not only at the end of a program execution). This will require precomputed digests per function call that need to be stored and accessed using an authentication tree. Once extended, analyze and simulate its performance. Research how to perform function calls in isolation such that if extended Gideon detects malicious behavior, the computation can be rolled back to the start of the function call.
Investigate into what extend Gideon can be combined with current state-of-the-art secure processor technology. This should result in an enhanced processor that not only verifies whether computation was malicious but also does not leak any privacy if the computation indeed turns out to have been malicious. A Gideon-enhanced secure processor would be the first to perform verified program execution under encryption
Prof. M. Dijk. Associate Professor, ECE Department, UCONN
Prof. O. Khan. Assistant Professor, ECE Department, UCONN
Masab Ahmad, PhD Student, ECE Department, UCONN
- A Survey of Memory Safety Mechanisms for Secure Processors
- A Software-Based Merkle Tree Memory Integrity Verification Scheme