Bytecode Corruption Attacks Are Real—And How to Defend Against Them

Park, Taemin; Lettner, Julian; Na, Yeoul; Volckaert, Stijn; Franz, Michael

doi:10.1007/978-3-319-93411-2_15

Cited by 4 publications

(4 citation statements)

References 17 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…These script interpreters prevent internally the usage of specific sensitive functions from being executed. However, Park et al [28] presented an attack with a restricted attacker model that is able to rewrite bytecode of functions to execute these sensitive functions and therefore bypassing the restriction. By applying our approach for an application-specific script interpreter, these restricted functionalities are completely removed from the interpreter and hence such an attack cannot use them.…”

Section: Discussionmentioning

confidence: 99%

“…Normally, unwanted functionalities are disabled in configuration files. However, since the code that provides these functionalities is still available in the script interpreter, an attacker might be able to bypass the restrictions and escape the interpreter's internal sandbox [28]. When compiling the script interpreter in an application-specific way, the code for the unneeded functionalities are completely removed, which prevents an attacker from using them entirely.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Towards Automated Application-Specific Software Stacks

Davidsson

Pawlowski

Holz

2019

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Software complexity has increased over the years. One common way to tackle this complexity during development is to encapsulate features into a shared library. This allows developers to reuse already implemented features instead of reimplementing them over and over again. However, not all features provided by a shared library are actually used by an application. As a result, an application using shared libraries loads unused code into memory, which an attacker can use to perform code-reuse and similar types of attacks. The same holds for applications written in a scripting language such as PHP or Ruby: The interpreter typically offers much more functionality than is actually required by the application and hence provides a larger overall attack surface.In this paper, we tackle this problem and propose a first step towards automated application-specific software stacks. We present a compiler extension capable of removing unneeded code from shared libraries and-with the help of domain knowledgealso capable of removing unused functionalities from an interpreter's code base during the compilation process. Our evaluation against a diverse set of real-world applications, among others Nginx, Lighttpd, and the PHP interpreter, removes on average 71.3% of the code in musl-libc, a popular libc implementation. The evaluation on web applications show that a tailored PHP interpreter can mitigate entire vulnerability classes, as is the case for OpenConf. We demonstrate the applicability of our debloating approach by creating an application-specific software stack for a Wordpress web application: we tailor the libc library to the Nginx web server and PHP interpreter, whereas the PHP interpreter is tailored to the Wordpress web application. In this real-world scenario, the code of the libc is decreased by 65.1% in total, thereby reducing the available code for code-reuse attacks.

show abstract

Section: Discussionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Towards Automated Application-Specific Software Stacks

Davidsson

Pawlowski

Holz

2019

Lecture Notes in Computer Science

View full text Add to dashboard Cite

show abstract

“…As another example, Frassetto et al describe how a memory corruption vulnerability can be used to modify the byte code of an interpreted program such that subsequent JIT compilation results in the creation of the malicious payload [15]. As these examples suggest, vulnerabilities arising from dynamic code generation pose a significant security challenge [33,40]. To deal with such situations, it would be helpful to be able to start from some appropriate point in the dynamically generated code-e.g., an instruction that crashes as a result of the bug, or is part of the exploit code-and trace dependencies back, into and through the JIT compiler's code, to help identify the bug that caused incorrect code to be generated or the byte code to be corrupted.…”

Section: Introductionmentioning

confidence: 99%

Representing and reasoning about dynamic code

Bartels

Stephens²,

Debray

2020

Proceedings of the 35th IEEE/ACM International Conference on Automated Software Engineering

View full text Add to dashboard Cite

Dynamic code, i.e., code that is created or modified at runtime, is ubiquitous in today's world. The behavior of dynamic code can depend on the logic of the dynamic code generator in subtle and non-obvious ways, with significant security implications, e.g., JIT compiler bugs can lead to exploitable vulnerabilities in the resulting JIT-compiled code. Existing approaches to program analysis do not provide adequate support for reasoning about such behavioral relationships. This paper takes a first step in addressing this problem by describing a program representation and a new notion of dependency that allows us to reason about dependency and information flow relationships between the dynamic code generator and the generated dynamic code. Experimental results show that analyses based on these concepts are able to capture properties of dynamic code that cannot be identified using traditional program analyses.

show abstract

“…execute arbitrary system calls, all while bypassing code-reuse defenses such as CFI [14,20,22,26,27,38].…”

mentioning

confidence: 99%

CoDaRR: Continuous Data Space Randomization against Data-Only Attacks

Rajasekaran

Crane²,

Gens

et al. 2020

Proceedings of the 15th ACM Asia Conference on Computer and Communications Security

Self Cite

View full text Add to dashboard Cite

The widespread deployment of exploit mitigations such as CFI and shadow stacks are making code-reuse attacks increasingly difficult. This has forced adversaries to consider data-only attacks against which the venerable ASLR remains the primary deployed defense. Data-Space Randomization (DSR) techniques raise the bar against data-only attacks by making it harder for adversaries to inject malicious data flows into vulnerable applications. DSR works by masking memory load and store instructions. Masks are chosen (i) to not interfere with intended data flows and (ii) such that masking likely interferes with unintended flows introduced by malicious program inputs. In this paper, we show two new attacks that bypass all existing static DSR approaches; one that directly discloses memory and another using speculative execution. We then present CoDaRR, the first dynamic DSR scheme resilient to disclosure attacks. CoDaRR continuously rerandomizes the masks used in loads and stores, and re-masks all memory objects to remain transparent w.r.t. program execution. Our evaluation confirms that CoDaRR successfully thwarts these attacks with limited run-time overhead in standard benchmarks as well as real-world applications.

show abstract

Bytecode Corruption Attacks Are Real—And How to Defend Against Them

Cited by 4 publications

References 17 publications

Towards Automated Application-Specific Software Stacks

Towards Automated Application-Specific Software Stacks

Representing and reasoning about dynamic code

CoDaRR: Continuous Data Space Randomization against Data-Only Attacks

Contact Info

Product

Resources

About