Software fault isolation with API integrity and multi-principal modules

Mao, Yandong; Chen, Haogang; Zhou, Dong; Wang, Xi; Zeldovich, Nickolai; Kaashoek, M. Frans

doi:10.1145/2043556.2043568

Cited by 76 publications

(49 citation statements)

References 23 publications

(13 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…JavaScript to Java interface vulnerability that allows entrusted JavaScript which via sandbox can allow remote code execution and it causes root access in Android phones [5]. For irregular kernel interface especially in Linux, LXFI can introduce privilege escalation vulnerability [6]. API's have common vulnerability that we have shown in the introduction [7].…”

Section: Literature Reviewmentioning

confidence: 99%

API vulnerabilities: current status and dependencies

Bhuiyan¹,

Begum²,

Rahman³

et al. 2018

IJET

View full text Add to dashboard Cite

Recently API (Application Programming Interface) is becoming more popular for developers. When software is designed, most of the time, developers need to use APIs to manage a specific task. Developers use various kinds of APIs. Some of them are built by themselves and some are used from public APIs. API is a set of functions and procedures that allows another program or application to get access to features or data. Public APIs are open in public networks; developers collect these APIs depending on their specific needs. Developers need to interact with other software, as a result, a developer can conduct specific task without authorization to access the entirety of the software. It definitely reduces our loads at the same time introduces risks. In the end every developer wants to ensure security to his/her application. Commonly used public APIs are not enough secure to provide security to confidential data. We focused on these public APIs that are commonly used by developers. We tested a set of public APIs in our security lab and we have found many vulnerabilities that are highly alarming for developers who are going to use these API. In this paper we have tried to introduce the current status of vulnerable APIs. Moreover, several relationships exist between API vulnerabilities. In this paper we have also discussed the dependencies and relationships between API vulnerabilities.

show abstract

Section: Literature Reviewmentioning

confidence: 99%

API vulnerabilities: current status and dependencies

Bhuiyan¹,

Begum²,

Rahman³

et al. 2018

IJET

View full text Add to dashboard Cite

show abstract

“…Because many memory corruption vulnerabilities are found in third-party kernel drivers due to relatively low code quality, many previous works focused on confining the memory access capabilities of these untrusted code with SFI [16,25,43,63]. A major limitation of SFI, as pointed out by [18], is that the core kernel may also contain many bugs, which cannot be handled by SFI.…”

Section: Related Workmentioning

confidence: 99%

“…Some technologies are capable of preventing non-controldata attacks. For example, software fault isolation (SFI) [16,25,43,63] can be used to isolate small "untrusted" modules from tampering the core kernel components. However, a recent study on Linux kernel vulnerabilities [18] discovered that vulnerabilities in the core components are as common as vulnerabilities in third-party drivers.…”

Section: Introductionmentioning

confidence: 99%

Enforcing Kernel Security Invariants with Data Flow Integrity

Song¹,

Lee²,

Lu³

et al. 2016

Proceedings 2016 Network and Distributed System Security Symposium

View full text Add to dashboard Cite

Abstract-The operation system kernel is the foundation of the whole system and is often the de facto trusted computing base for many higher level security mechanisms. Unfortunately, kernel vulnerabilities are not rare and are continuously being introduced with new kernel features. Once the kernel is compromised, attackers can bypass any access control checks, escalate their privileges, and hide the evidence of attacks. Many protection mechanisms have been proposed and deployed to prevent kernel exploits. However, a majority of these techniques only focus on preventing control-flow hijacking attacks; techniques that can mitigate noncontrol-data attacks either only apply to drivers/modules or impose too much overhead. The goal of our research is to develop a principled defense mechanism against memory-corruption-based privilege escalation attacks. Toward this end, we leverage dataflow integrity to enforce security invariants of the kernel access control system. In order for our protection mechanism to be practical, we develop two new techniques: one for automatically inferring data that are critical to the access control system without manual annotation, and the other for efficient DFI enforcement over the inference results. We have implemented a prototype of our technology for the ARM64 Linux kernel on an Android device. The evaluation results of our prototype implementation show that our technology can mitigate a majority of privilege escalation attacks, while imposing a moderate amount of performance overhead.

show abstract

“…Vx32 [6] uses the segment register in x86 to confine memory access in hardware. Other solutions [3,10,15] provide isolation by confining the untrusted component to a memory region assigned to the component, we call such a memory model as a separated memory model. There are two problems with this model.…”

Section: Related Workmentioning

confidence: 99%

Codejail: Application-Transparent Isolation of Libraries with Tight Program Interactions

Sathyanarayan

Yap

et al. 2012

Computer Security – ESORICS 2012

View full text Add to dashboard Cite

Abstract. Dynamically linked libraries are commonly used in software programs to facilitate code reuse. Once a library is linked into a software program, a bug in the library can lead to compromise of the whole program. Moreover, the library may also contain malicious code. Existing solutions for software component isolation assume simple interactions between a library and the main program, otherwise, they require significant modification of the main program and the library. In this paper, we propose a novel solution, Codejail, which supports a partial isolation of libraries that have tight memory interactions with the main program. Codejail requires no modification to the main program or the library. We demonstrate using a Linux prototype that Codejail can work easily with real-world programs and libraries. The performance is good for a portable implementation with costs commensurate with the degree of tight interaction.

show abstract

Software fault isolation with API integrity and multi-principal modules

Cited by 76 publications

References 23 publications

API vulnerabilities: current status and dependencies

API vulnerabilities: current status and dependencies

Enforcing Kernel Security Invariants with Data Flow Integrity

Codejail: Application-Transparent Isolation of Libraries with Tight Program Interactions

Contact Info

Product

Resources

About