Biblio

Hardware counters are included in processors to count microarchitecture level events affecting performance. When control flow anomalies caused by attacks such as buffer overflow or return oriented programming (ROP) occur, they leave a microarchitectural footprint. Hardware counters reflect such footprints to flag control flow anomalies. This paper is geared towards buffer overflow and ROP control flow anomaly detection in embedded programs. The targeted program entities are main event loops and task/event handlers. Embedded systems also have enhanced need for variable anomaly detection time in order to meet the system response time requirements. We propose a novel repurposing of Patt-Yeh two level branch predictor data structure for abstracting/hashing HW counter signatures to support such variable anomaly detection times. The proposed anomaly detection mechanism is evaluated on some generic benchmark programs and ArduPilot - a popular autopilot software. Experimental evaluation encompasses both Intel X86 and ARM Cortex M processors. DWT within Cortex M provides sufficiently interesting program level event counts to capture these control flow anomalies. We are able to achieve 97-99%+ accuracy with 1-10 micro-second time overhead per anomaly check.

Historically, attackers have sought to manipulate programs through the corruption of return addresses, function pointers, and other control flow data. However, as protections like ASLR, stack canaries, and no-execute bits have made such attacks more difficult, data-oriented exploits have received increasing attention. Such exploits try to subvert a program by reading or writing non-control data, without introducing any foreign code or violating the program’s legitimate control flow graph. Recently, a data-oriented exploitation technique called memory cartography was introduced, in which an attacker navigates between allocated memory regions using a precompiled map to disclose sensitive program data. The efficacy of memory cartography is dependent on inter-region pointers being located at constant offsets within memory regions; thus, cartographic attacks are difficult to launch against memory regions like heaps and stacks that have nondeterministic layouts. In this paper, we lower the barrier to successful attacks against nondeterministic memory, demonstrating that pointers between regions of memory often possess unique “signatures” that allow attackers to identify them with high accuracy. These signatures are accurate even when the pointers reside in non-deterministic memory areas. In many real-world programs, this allows an attacker that is capable of reading bytes from a single heap to access all of process memory. Our findings underscore the importance of memory isolation via separate address spaces.

Return-oriented programming(ROP) is a prevalent technique that targets return addresses to hijack control flow. To prevent such attack, researchers mainly focus on either Shadow Stack or MAC-based mechanisms(message code authentication). But Shadow Stack suffers from additional memory overhead and information leakage, while MAC-based mechanisms(e.g. Zipper Stack) impose high runtime overhead for MAC calculations.In this paper, we propose Twine Stack, a hybrid and efficient return address protection mechanism with lightweight hardware extension. It utilizes a tiny hardware shadow stack to realize a new multi-chain Zipper Stack. Specifically, each entry in the shadow stack stores a return address and its MAC in each chain, allowing queueing calculation with just one hash module. At meantime, some return address verifications could be done by comparison with the hardware shadow stack, instead of calculation again. We implemented Twine Stack on RISC-V architecture, and evaluated it on FPGA board. Our experiments show that Twine Stack reduces over 95% hash verifications, and imposes merely 1.38% performance overhead with an area overhead of 974 LUTs and 726 flip flops. The result demonstrates that our hybrid scheme mitigates the drawbacks of each separate scheme.

Intel SGX provides a new method to protect software privacy data, but it faces the security risk of side channel attack. In our opinion, SGX side channel attack depend on the implicit mapping between control flow and data flow to infer privacy data indirectly with control flow. For this reason, we propose code reuse to construct dynamic control flow software. In this method, by loading a large number of related gadgets in advance, the software reset the software control data according to the original software semantics at runtime, so that the software control flow can change dynamically heavily. Based on code reuse, we make the software control flow change dynamically, and the mapping between control flow and data flow more complex and difficult to determine, which can increase the difficulty of SGX side channel attack.

Code-reuse attacks pose a threat to embedded devices since they are able to defeat common security defenses such as non-executable stacks. To succeed in his code-reuse attack, the attacker has to gain knowledge of some or all of the instructions of the target firmware/software. In case of a bare-metal firmware that is protected from being dumped out of a device, it is hard to know the running instructions of the target firmware. This consequently makes code-reuse attacks more difficult to achieve. This paper shows how an attacker can gain knowledge of some of these instructions by sniffing the unencrypted incremental updates. These updates exist to reduce the radio reception power for resource-constrained devices. Based on the literature, these updates are checked against authentication and integrity, but they are sometimes sent unencrypted. Therefore, it will be demonstrated how a Return-Oriented Programming (ROP) attack can be accomplished using only the passively sniffed incremental updates. The generated updates of the R3diff and Delta Generator (DG) differencing algorithms will be under assessment. The evaluation reveals that both of them can be exploited by the attacker. It also shows that the DG generated updates leak more information than the R3diff generated updates. To defend against this attack, different countermeasures that consider different power consumption scenarios are proposed, but yet to be evaluated.

Largely known for attack scenarios, code reuse techniques at a closer look reveal properties that are appealing also for program obfuscation. We explore the popular return-oriented programming paradigm under this light, transforming program functions into ROP chains that coexist seamlessly with the surrounding software stack. We show how to build chains that can withstand popular static and dynamic deobfuscation approaches, evaluating the robustness and overheads of the design over common programs. The results suggest a significant amount of computational resources would be required to carry a deobfuscation attack for secret finding and code coverage goals.

Code-reuse techniques have emerged as a way to defeat the control-flow defenses that prevent the injection and execution of new code, as they allow an adversary to hijack the control flow of a victim program without injected code. A well-known code-reuse attack technique is Return-OrientedProgramming (ROP), which considers and links together (relatively short) code snippets, named ROP gadgets, already present in the victim’s memory address space through a controlled use of the stack values of the victim program. Although ROP attacks are known to be Turing-complete, there are still open question such as the quantification of the executional power of an adversary, which is determined by whatever code exists in the memory of a victim program, and whether an adversary can build a ROP chain, made up of ROP gadgets, for any kind of algorithm. To fill these gaps, in this paper we first define a virtual language, dubbed ROPLANG, that defines a set of operations (specifically, arithmetic, assignment, dereference, logical, and branching operations) which are mapped to ROP gadgets. We then use it to evaluate the executional power of an adversary in Windows 7 and Windows 10, in both 32- and 64-bit versions. In addition, we have developed ROP3, a tool that accepts a set of program files and a ROP chain described with our language and returns the code snippets that make up the ROP chain. Our results show that there are enough ROP gadgets to simulate any virtual operation and that branching operations are the less frequent ones. As expected, our results also indicate that the larger a program file is, the more likely to find ROP gadgets within it for every virtual operation.