Low-Level Software Security by Example

Erlingsson, Úlfar; Younan, Yves; Piessens, Frank

doi:10.1007/978-3-642-04117-4_30

Cited by 27 publications

(27 citation statements)

References 18 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…This is well-known and many papers give examples; we refer the reader to Erlingsson et al [14] for an overview. Here is one simple example of a program in C for which the principle of source-based reasoning fails.…”

Section: The Interactive Attacker Modelmentioning

confidence: 90%

“…A wide variety of techniques has been developed to execute unsafe languages more defensively [14,34,35]. Roughly speaking, these techniques can be grouped into two categories.…”

Section: More Defensive Execution Of Unsafe Languagesmentioning

confidence: 99%

“…This is obviously the case for attacks that exploit memory errors in programs written in unsafe languages such as C and C++. Understanding low-level attacks such as stack smashing attacks, direct code injection attacks, jump-to-libc attacks or return-oriented programming requires one to understand many details of the compiler, operating system or processor architecture [14].…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Recent Developments in Low-Level Software Security

Agten

Nikiforakis

Strackx

et al. 2012

Information Security Theory and Practice. Security, Privacy and Trust in Computing Systems and Ambient Intelligent Ecosystems

Self Cite

View full text Add to dashboard Cite

Abstract. An important objective for low-level software security research is to develop techniques that make it harder to launch attacks that exploit implementation details of the system under attack. Baltopoulos and Gordon have summarized this as the principle of source-based reasoning for security: security properties of a software system should follow from review of the source code and its source-level semantics, and should not depend on details of the compiler or execution platform.Whether the principle holds -or to what degree -for a particular system depends on the attacker model. If an attacker can only provide input to the program under attack, then the principle holds for any safe programming language. However, for more powerful attackers that can load new native machine code into the system, the principle of sourcebased reasoning typically breaks down completely.In this paper we discuss state-of-the-art approaches for securing code written in C-like languages for both attacker models discussed above, and we highlight some very recent developments in low-level software security that hold the promise to restore source-based reasoning even against attackers that can provide arbitrary machine code to be run in the same process as the program under attack.

show abstract

Section: The Interactive Attacker Modelmentioning

confidence: 90%

“…A wide variety of techniques has been developed to execute unsafe languages more defensively [14,34,35]. Roughly speaking, these techniques can be grouped into two categories.…”

Section: More Defensive Execution Of Unsafe Languagesmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Recent Developments in Low-Level Software Security

Agten

Nikiforakis

Strackx

et al. 2012

Information Security Theory and Practice. Security, Privacy and Trust in Computing Systems and Ambient Intelligent Ecosystems

Self Cite

View full text Add to dashboard Cite

show abstract

“…We mention the more advanced techniques because some of these can be used to circumvent some countermeasures. A more thorough technical examination of the vulnerabilities and exploitation techniques (as well as a technical examination of some countermeasures) can be found in [Younan 2003;2008;Erlingsson et al 2010]. …”

Section: Implementation Vulnerabilities and Exploitation Techniquesmentioning

confidence: 99%

Runtime countermeasures for code injection attacks against C and C++ programs

2012

Self Cite

View full text Add to dashboard Cite

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.

show abstract

“…In this section we will briefly discuss the most important types of countermeasures. A more extensive discussion can be found in [38,13,37]. [18,32,4,16,20,25,27] is a better solution to buffer overflows, however when implemented for C, it has a severe impact on performance and may cause existing code to become incompatible with bounds checked code.…”

Section: Related Workmentioning

confidence: 99%

ValueGuard: Protection of Native Applications against Data-Only Buffer Overflows

Acker

Nikiforakis

Philippaerts

et al. 2010

Information Systems Security

Self Cite

View full text Add to dashboard Cite

Abstract. Code injection attacks that target the control-data of an application have been prevalent amongst exploit writers for over 20 years. Today however, these attacks are getting increasingly harder for attackers to successfully exploit due to numerous countermeasures that are deployed by modern operating systems. We believe that this fact will drive exploit writers away from classic control-data attacks and towards data-only attacks. In data-only attacks, the attacker changes key data structures that are used by the program's logic and thus forces the control flow into existing parts of the program that would be otherwise unreachable, e.g. overflowing into a boolean variable that states whether the current user is an administrator or not and setting it to "true" thereby gaining access to the administrative functions of the program. In this paper we present ValueGuard, a canary-based defense mechanism to protect applications against data-only buffer overflow attacks. ValueGuard inserts canary values in front of all variables and verifies their integrity whenever these variables are used. In this way, if a buffer overflow has occurred that changed the contents of a variable, ValueGuard will detect it since the variable's canary will have also been changed. The countermeasure itself can be used either as a testing tool for applications before their final deployment or it can be applied selectively to legacy or high-risk parts of programs that we want to protect at run-time, without incurring extra time-penalties to the rest of the applications.

show abstract

Low-Level Software Security by Example

Cited by 27 publications

References 18 publications

Recent Developments in Low-Level Software Security

Recent Developments in Low-Level Software Security

Runtime countermeasures for code injection attacks against C and C++ programs

ValueGuard: Protection of Native Applications against Data-Only Buffer Overflows

Contact Info

Product

Resources

About