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%.

Full Text
Published version (Free)

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call