The Devil is in the Constants: Bypassing Defenses in Browser JIT Engines

Athanasakis, Michalis; Αθανασόπουλος, Ηλίας; Polychronakis, Michalis; Portokalidis, Georgios; Ioannidis, Sotiris

doi:10.14722/ndss.2015.23209

Cited by 29 publications

(32 citation statements)

References 26 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Given that modern systems are protected by DEP, attackers cannot overwrite read-only code to forge virtual functions with correct signatures. Thus this layer of defense is practical and useful in the real world, because (1) most applications do not have writable code, and (2) forging signatures in writable code is hard due to defenses like ASLR and JIT spraying [31] mitigations. We strongly recommend deploying this defense in practice.…”

Section: Introductionmentioning

confidence: 99%

VTrust: Regaining Trust on Virtual Calls

Zhang¹,

Song²,

Carr³

et al. 2016

Proceedings 2016 Network and Distributed System Security Symposium

View full text Add to dashboard Cite

Abstract-Virtual function calls are one of the most popular control-flow hijack attack targets. Compilers use a virtual function pointer table, called a VTable, to dynamically dispatch virtual function calls. These VTables are read-only, but pointers to them are not. VTable pointers reside in objects that are writable, allowing attackers to overwrite them. As a result, attackers can divert the control-flow of virtual function calls and launch VTable hijacking attacks. Researchers have proposed several solutions to protect virtual calls. However, they either incur high performance overhead or fail to defeat some VTable hijacking attacks.In this paper, we propose a lightweight defense solution, VTrust, to protect all virtual function calls from VTable hijacking attacks. It consists of two independent layers of defenses: virtual function type enforcement and VTable pointer sanitization. Combined with modern compilers' default configuration, i.e., placing VTables in read-only memory, VTrust can defeat all VTable hijacking attacks and supports modularity, allowing us to harden applications module by module. We have implemented a prototype on the LLVM compiler framework. Our experiments show that this solution only introduces a low performance overhead, and it defeats real world VTable hijacking attacks.

show abstract

Section: Introductionmentioning

confidence: 99%

VTrust: Regaining Trust on Virtual Calls

Zhang¹,

Song²,

Carr³

et al. 2016

Proceedings 2016 Network and Distributed System Security Symposium

View full text Add to dashboard Cite

show abstract

“…The source code contains five constants. These constants are the gadgets required for calling mprotect [17]. The JITed contains these constants, and hence these constants can be exposed by an attacker.…”

Section: Examplementioning

confidence: 99%

“…For n = 16, the probability is 7.7 × 10 −19 . We chose two attacks presented in [17] for evaluating the security provided by libmask. One JavaScript attack is shown in Figure 6.…”

Section: E Security Evaluationmentioning

confidence: 99%

“…The Chakra JS engine used in Internet Explorer as its JIT engine employs several defenses like NOP insertion and XOR based Constant Blinding. [17] has shown that even if JIT uses the above approach as defense an attacker can still successfully attack the system by generating some specific gadgets.…”

Section: Related Workmentioning

confidence: 99%

“…The constants is XORed back again when the original constant needs to be used. Athanasakis et al in [17] has shown that XOR constant blinding technique can be bypassed. Their technique contains constants, which are less than 4 bytes and hence, are emitted as such in the JIT code.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

libmask: Protecting browser JIT engines from the devil in the constants

Abhinav

Mishra

Baudry

2016

2016 14th Annual Conference on Privacy, Security and Trust (PST)

View full text Add to dashboard Cite

Abstract-JavaScript (JS) engines are virtual machines that execute JavaScript code. These engines find frequent application in web browsers like Google Chrome, Mozilla Firefox, Microsoft Internet Explorer and Apple Safari. Since, the purpose of a JS engine is to produce executable code, it cannot be run in a non-executable environment, and is susceptible to attacks like Just-in-Time (JIT) Spraying, which embed return-oriented programming (ROP) gadgets in arithmetic or logical instructions as immediate offsets. This paper introduces libmask, a JIT compiler extension to prevent the JIT-spraying attacks as an effective alternative to XOR based constant blinding. libmask transforms constants into global variables and marks the memory area for these global variables as read only. Hence, any constant is referred to by a memory address making exploitation of arithmetic and logical instructions more difficult. Further, these memory addresses are randomized to further harden the security. The scheme has been implemented and evaluated as a librddy extension to Google V8 scripting engine with optimizations that contain performance overhead and make libmask a feasible approach. We demonstrate that libmask masks all the constants in JITed code, and effectively raise the bar for JIT-spray and JIT-ROP attacks. The average overhead incurred upon memory is less than 300 kilobytes, while in most benchmarks the memory overhead is less than 10 KB. The average performance overhead observed with optimizations measures is 5.31%. Further, this new approach shows a modest performance improvement over currently deployed constant blinding technique in Google V8.

show abstract

A security feature framework for programming languages to minimize application layer vulnerabilities

Khwaja

Murtaza

Ahmed

2019

Security and Privacy

View full text Add to dashboard Cite

Pervasiveness of Internet‐based applications and computing devices has increased cybersecurity threats for wide range of users. Studies have shown that application security flaws have their roots in programming languages used for application development. Some vulnerabilities are due to programmer's negligence and others are due to the vulnerabilities present in the programming languages and their libraries. Developers may not be aware of the existing flaws in the programming languages and do not have time to take necessary measures as they develop applications. To cope with the challenge, this article proposes a security feature framework for programming languages to understand various exploitations and possible mitigations in programming languages. This security feature framework can be used to evaluate existing programming languages for potential vulnerabilities, level of security support, and the language features needed to mitigate these vulnerabilities. Moreover, language designers may use this framework as a guide to ensure that the language being designed has necessary and sufficient security feature set. The proposed security feature framework is then applied to several popular programming languages to evaluate the level of security feature coverage and gaps in these languages along with some recommendations on how to address these gaps.

show abstract

The Devil is in the Constants: Bypassing Defenses in Browser JIT Engines

Cited by 29 publications

References 26 publications

VTrust: Regaining Trust on Virtual Calls

VTrust: Regaining Trust on Virtual Calls

libmask: Protecting browser JIT engines from the devil in the constants

A security feature framework for programming languages to minimize application layer vulnerabilities

Contact Info

Product

Resources

About