Process and Library loading

The next step in the userspace code integrity validation process is the actual loading of the executable binary file in order to generate a ground truth for the final validation of the memory contents. If the executable is found in the trusted store, the framework starts to emulate the application loading process.

During this process, in the relocation step, the binaries .got (Global Object Table) and.plt (Program Linker Table) sections are initialized by our framework. These sections typically contain links to all external symbols that are referenced by the library. With this step we (1) aim to be able to validate the contents of all VMAs that are mapped into the process as executable and (2) are able to compare the contents of both the .got and.plt sections within the guest VMs memory against a trusted reference version. The second point is also important, as instead of modifying the read-only mapped code segments directly, malware typically changes these datastructures to be able to access functions within other libraries, that are not originally referenced by the binary. Again, this technique is not new in our thesis, but increases the integrity guarantees provided by our framework. Thus we include this check within our framework.

During the replication of the application loading process, we noticed two limitations, which make it hard to fully validate the integrity of a process that is loaded into memory. Both of these issues are related to the way how relocations are implemented within Linux userspace applications. To reiterate, the idea of relocations is, that a library may reference an external function or symbol, independent of the memory addresses that the different libraries are loaded to. For this, the userspace binary loader inserts a pointer to the referenced

1https://technet.microsoft.com/de-de/library/dn986865(v=vs.85).aspx

7. Dynamic Integrity Validation for Userspace Applications

external symbol into a location in memory that is known by the loaded library during load time. However, a feature exists (lazy binding), which does not require the relocation to happen directly during load time of the library, but symbols may also be resolved on demand during runtime. This is done to optimize the load time of large applications that contain a lot of relocation entries. Lazy loading was the default option for relocations within Linux for a long time. Due to lazy loading, the Global Object Table (.got) may have a different state depending on which external symbols have already been used during program execution. This, however, is just a consistency problem, when checking the integrity of the.got section in memory. However, lazy loading is not supported by or framework. The decision to not support lazy loading is not critical, as lazy loading nowadays only provides minor impact on performance and may easily be disabled in a security aware context. In addition, there was also a new loader feature introduced, which aims to prevent applications to maliciously modify the contents of the.gotsection.

This feature also demands to fully execute the relocation at load time and then maps the corresponding data structure as read-only within the monitored process. This feature is calledrelro. Thus the first limitation is not critical, as further security mechanisms already exist, that solve the problem.

In contrast, the second limitation we encountered during our in-vestigations is more critical. In 2011 gcc introduced a new type of relocation² by implementing support for a new symbol type ex-tension, calledIFUNC³. In effect, this mechanism is similar to the alternative instructions mechanism present in the Linux kernel, which was presented in Section 5.2 of this thesis. It allows the application developer to select a specific implementation of a function during the load time of the binary. The decision may depend on external condi-tions like the current hardware and software state. The difference between theIFUNC mechanism and the kernels alternative

instruc-2Version 4.6, March 2011

3STT_GNU_IFUNC

to Userspace

7.2. Code and State Integrity Validation

tions mechanism is that instead of selecting a specific implementation for the function depending on concrete criteria, the loader executes an external function that is provided by the application developer during the relocation step. Instead of the address to the requested symbol, the relocation entry contains the address of the selection function. During relocation of the corresponding symbol, the loader simply executes the given function, which sole purpose is to select which concrete implementation is selected for the current relocation.

The global object table is then updated with the functions return value.

Our framework is currently not able to reproduce a full list of possible relocation entries and thus is unable to entirely validate the contents of the global object table of an executable in memory in case the binary uses theIFUNC mechanism. This is, as our validation framework currently does not support symbolic execution and we do not want to execute external code within our security framework.

We did not implement this as part of this thesis, as the.gotdata structure is mapped as read only by the loader anyway for all systems that enable the nowadays commonrelrosecurity mechanism. Note, that this problem also applies to other state of the art CFI tools as there is, to the best of our knowledge, no related work that discusses this issue.

To support this feature, our framework would need to be extended to support symbolic execution to automatically extract the address of the intended function from the binary code in a secure way. It, however, should not only be able to extract the address of the function that should be executed in the current environment, but in addition also extract a list of all possible functions together with information about the decision criteria. With this information also a ruleset for each possible implementation could be created, which could be used during the.gotvalidation step within our framework.

7. Dynamic Integrity Validation for Userspace Applications