Abstract
Due to the address space layout randomization (ASLR), code reuse attacks (CRAs) require memory probes to get available gadgets. Code reading is the basic way to obtain code information. In theory, setting the code to be unreadable can prevent code reading. However, the pages are loaded dynamically, and the existing methods cannot set all code as unreadable at one time. They can only control code permissions page-by-page via time-consuming page tracking. Moreover, since some special users need to read code, turning off the read permission will affect their execution. To solve these problems, this paper proposes a method AntiRead. It rebuilds the buddy system for memory allocation. The new buddy system places code pages in a specific memory pool to manage their read permissions. In the presence of AntiRead, what is obtained by adversaries through code reading is either randomized code or non-executable code. Experiments and analysis show that AntiRead can prevent the code that has been read from being used as gadgets without affecting the normal code reading. In addition, the CPU overhead introduced by AntiRead is 1.8%.
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Disclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.