![Institutional Repository [SANDBOX]](images/dias.logo.png "Institutional Repository [SANDBOX]"){kind=logo}
Institutional Repository [SANDBOX]
Technical University of Crete
Technical University of Crete
EN
|
EL
| URI: | http://purl.tuc.gr/dl/dias/357C26C1-A2C9-4EE4-8192-7ABDF315600C | ||
| Year | 2020 | ||
| Type of Item | Peer-Reviewed Journal Publication | ||
| License |
|
||
| Bibliographic Citation | G. Christou, G. Vasiliadis, V. Papaefstathiou, A. Papadogiannakis, and S. Ioannidis, “On architectural support for instruction set randomization,” ACM Trans. Archit. Code Optim., vol. 17, no. 4, pp. 1–26, Dec. 2020. doi: 10.1145/3419841 https://doi.org/10.1145/3419841 | ||
| Appears in Collections |
Instruction Set Randomization (ISR) is able to protect against remote code injection attacks by randomizing the instruction set of each process. Thereby, even if an attacker succeeds to inject code, it will fail to execute on the randomized processor. The majority of existing ISR implementations is based on emulators and binary instrumentation tools that unfortunately: (i) incur significant runtime performance overheads, (ii) limit the ease of deployment, (iii) cannot protect the underlying operating system kernel, and (iv) are vulnerable to evasion attempts that bypass the ISR protection itself.To address these issues, we present the design and implementation of ASIST, an architecture with both hardware and operating system support for ISR. ASIST uses our extended SPARC processor that is mapped onto a FPGA board and runs our modified Linux kernel to support the new features. In particular, before executing a new user-level process, the operating system loads its randomization key into a newly defined register, and the modified processor decodes the process’s instructions with this key. Besides that, ASIST uses a separate randomization key for the operating system to protect the base system against attacks that exploit kernel vulnerabilities to run arbitrary code with elevated privileges. Our evaluation shows that ASIST can transparently protect both user-land applications and the operating system kernel from code injection and code reuse attacks, with about 1.5% runtime overhead when using simple encryption schemes, such as XOR and Transposition; more secure ciphers, such as AES, even though they are much more complicated for mapping them to hardware, they are still within acceptable margins,with approximately 10% runtime overhead, when efficiently leveraging the spatial locality of code through modern instruction cache configurations.
Copyright © DIAS 2013
