Many countermeasures exist that attempt to protect against buffer overflow attacks on applications written in C and C++. The most widely deployed countermeasures rely on artificially introducing randomness in the memory image of the application. StackGuard and similar systems, for instance, will insert a random value before the return address on the stack, and Address Space Layout Randomization (ASLR) will make the location of stack and/or heap less predictable for an attacker.A critical assumption in these probabilistic countermeasures is that attackers cannot read the contents of memory. In this paper we show that this assumption is not always justified. We identify a new class of vulnerabilities -buffer overreads -that occur in practice and that can be exploited to read parts of the memory contents of a process running a vulnerable application. We describe in detail how to exploit an application protected by both ASLR and stack canaries, if the application contains both a buffer overread and a buffer overflow vulnerability.We also provide a detailed discussion of how this vulnerability affects other, less widely deployed probabilistic countermeasures such as memory obfuscation and instruction set randomization.

Use-after-free vulnerabilities have become an important class of security problems due to the existence of mitigations that protect against other types of vulnerabilities. The effects of their exploitation can be just as devastating as exploiting a buffer overflow, potentially resulting in full code execution within the vulnerable program. Few protections exist against these types of vulnerabilities and they are particularly hard to discover through manual code inspection. In this paper we present FreeSentry: a mitigation that protects against use-after-free vulnerabilities by inserting dynamic runtime checks that invalidate pointers when the associated memory is released. If such an invalidated pointer is accessed, the program will subsequently crash, preventing an attacker from exploiting the vulnerability. When checking dynamically allocated memory, our approach has a moderate performance overhead on the SPEC CPU benchmarks: running with a geometric mean performance impact of around 25%. It has no overhead when deployed on widely used server side daemons such as OpenSSH or the Apache HTTP daemon. FreeSentry also discovered a previously unknown use-after-free vulnerability in one of the programs in SPEC CPU2000 benchmarks: perlbmk. This vulnerability seems to have been missed by other mitigations. Permission to freely reproduce all or part of this paper for noncommercial purposes is granted provided that copies bear this notice and the full citation on the first page. Reproduction for commercial purposes is strictly prohibited without the prior written consent of the Internet Society, the first-named author (for reproduction of an entire paper only), and the author's employer if the paper was prepared within the scope of employment.

Abstract. The class of Cross-site Scripting (XSS) vulnerabilities is the most prevalent security problem in the field of Web applications. One of the main attack vectors used in connection with XSS is session hijacking via session identifier theft. While session hijacking is a client-side attack, the actual vulnerability resides on the server-side and, thus, has to be handled by the website's operator. In consequence, if the operator fails to address XSS, the application's users are defenseless against session hijacking attacks. In this paper we present SessionShield, a lightweight client-side protection mechanism against session hijacking that allows users to protect themselves even if a vulnerable website's operator neglects to mitigate existing XSS problems. SessionShield is based on the observation that session identifier values are not used by legitimate clientside scripts and, thus, need not to be available to the scripting languages running in the browser. Our system requires no training period and imposes negligible overhead to the browser, therefore, making it ideal for desktop and mobile systems.

The lack of memory-safety in C/C++ often leads to vulnerabilities. Code injection attacks exploit these to gain control over the execution-flow of applications. These attacks have played a key role in many major security incidents. Consequently, a huge body of research on countermeasures exists. We provide a comprehensive and structured survey of vulnerabilities and countermeasures that operate at runtime. These countermeasures make different trade-offs in terms of performance, effectivity, compatibility, etc. This makes it hard to evaluate and compare countermeasures in a given context. We define a classification and evaluation framework, on the basis of which countermeasures can be assessed.

In this paper we present an efficient countermeasure against stack smashing attacks. Our countermeasure does not rely on secret values (such as canaries) and protects against attacks that are not addressed by state-of-the-art countermeasures. Our technique splits the standard stack into multiple stacks. The allocation of data types to one of the stacks is based on the chances that a specific data element is either a target of attacks and/or an attack vector. We have implemented our solution in a C-compiler for Linux. The evaluation shows that the overhead of using our countermeasure is negligible.