This paper proposes a methodology to develop countermeasures against code injection attacks, and validates the methodology by working out a specific countermeasure. This methodology is based on modeling the execution environment of a program. Such a model is then used to build countermeasures. The paper justifies the need for a more structured approach to protect programs against code injection attacks: we examine advanced techniques for injecting code into C and C++ programs and we discuss state-of-the -art (often ad hoc) approaches that typically protect singular memory locations. We validate our methodology by building countermeasures that prevent attacks by protecting a broad variety of memory locations that may be used by attackers to perform code injections. The paper evaluates our approach and discusses ongoing and future work.

Abstract not found

Most memory allocators ignore security issues. Instead they focus on maximizing performance and limiting fragmentation and waste. While these are very important issues for a memory alloca- tor, in the days of worms that use code injection attacks to cause significant economical damage, security can not be ignored. This paper evaluates a representative set of commonly used memory al- locators for C and C++ with respect to their resilience against code injection attacks. We present a significant improvement for memory allocators in order to increase robustness against code injection at- tacks. We evaluate this new approach in terms of performance and memory usage and show that the associated overhead is negligible.

Multiprocessor SoCs are increasingly deployed in embedded systems with little or no security features built in. Code Injection attacks are one of the most commonly encountered security threats. Most solutions to this problem in the single processor domain are purely software based and have high overheads. A few hardware solutions have been provided for the single processor case, which significantly reduce overheads. In this paper, for the first time, we propose a methodology addressing code injection attacks in a multiprocessor domain. A dedicated security (monitor) processor is used to oversee the application at runtime. Each processor communicates with the monitor processor through a FIFO queue, and is continuously checked. Static analysis of program map and timing profile are used to obtain program information at compile time, which is utilized by the monitor processor at runtime. This information is encrypted using a secure key and stored in the monitor processor. A copy of this secure key is built into the processor’s hardware and is used for decryption by the monitor processor. Each basic block of the program is also instrumented with security information that uniquely identifies itself at runtime. The information from static analysis thus allows the monitor processor to supervise the proceedings on each processor at runtime. Our approach uses a combination of hardware and software techniques to keep overheads to a minimum. We implemented our methodology on a commercial extensible processor (Xtensa LX). Our approach successfully detects the execution of injected code when tested on a JPEG multiprocessor benchmark. The results show a small increase of 6.6 % in application processors ’ runtime (clock cycle count) and 35.2 % in code size for the JPEG encoder benchmark.

Abstract. Computers are often subject to external attacks that aim to control software behavior. Typically, such attacks arrive as data over a regular communication channel and, once resident in program memory, trigger pre-existing, low-level software vulnerabilities. By exploiting such flaws, these low-level attacks can subvert the execution of the software and gain control over its behavior. The combined effects of these attacks make them one of the most pressing challenges in computer security. As a result, in recent years, many mechanisms have been proposed for defending against these attacks. This chapter aims to provide insight in low-level software attack and defense techniques by discussing 4 examples of attacks that are representative of the major types of attacks on C and C++ software, and 4 examples of defenses selected because of their effectiveness, wide applicability and low enforcement overhead. Attacks and defenses are described in enough detail to be understood even by readers without a background in software security, and with-out a natural inclination for crafting malicious attacks. Throughout, the attacks and defenses are placed in perspective by showing how they are both facilitated by the gap between the semantics of the high-level language of the software under attack, and the low-level semantics of machine code and the hardware on which the software executes. 1