Revisiting Address Space Randomization - Information Security and Cryptology-ICISC 2010 - page 219

deeper question: is address space randomization weak in randomizing GOT only
and therefore becomes effective once the mitigation techniques are in place, or is
it true that randomizing some of the code and data objects (e.g., base and order
of library functions) is simply ineffective when return-oriented programming is
used in an attack?
Before we try to answer this question, we first revisit our attack presented
in Section 3 and Section 4 and see if exploiting GOT is the only way for the
attack to succeed. The answer is definitely not. We try to derandomize the
address of libc functions simply because the library has a larger code base which
could be analyzed oine and usually contains more useful gadgets for return-
oriented programming. However, in many cases, all an attack wants is simply
to be able to make a system call (with values of the attacker's choice on a
few registers), which might be possible with only gadgets from the vulnerable
program itself without making use of the library. We perform an analysis on
some commonly used application programs by using the Galileo algorithm [14]
and our improvements on it (see Section 4.2) to search for gadgets that allow an
attack to make a system call. Results (see Table 5) show that some programs,
such as the vulnerable version of Ghostscript [1], could be attacked by only
gadgets from the program.
In an attack using return-oriented programming with gadgets in the program
binary only, even fewer gadgets could be required. For example, to execute the
execve()

)
and then execute the system call instruction. Only these two categories of in-
structions (and the corresponding gadgets) are needed. Table 5 shows the number
of gadgets found for a few application programs.

system call, we only need to write four registers ( , , ,

eax ebx ecx edx

Table 5. Number of gadgets found in some large programs

Programs Register writing syscall (int80 or call *%gfs:0x10)

gs-8.61 (11 MB) 34 130

mencoder-4.3.2 (8.7 MB)

47 5

emacs-23 (11 MB)

143 15

qemu-0.11.1 (2.1 MB) 23 10

qmake 2.01a (3.8 MB)

27 4

This shows that GOT is actually not the most important weaknesses in ad-
dress space randomization in view of attacks using return-oriented programming.
Rather, because address space randomization was proposed well before return-
oriented programming was introduced, it was not designed to defend against
return-oriented programming and therefore it is not surprising that the random-
ization of some of the code and data objects is simply not effective to defend
against return-oriented programming. We argue that the randomization of base
and order of library functions and the location and order of entries in PLT
and GOT are typical examples. Mitigation techniques like encrypting GOT does
not actually make address space randomization secure against return-oriented
programming.