After we have wrapped up our conclusions and shortly provided some ideas for practical application, in the following we shortly introduce some future work and research directions for each of the research direction that we have presented throughout this thesis.
Kernel Code Integrity Future work related to kernel code integrity validation is mostly implementation work. Our current prototype implementation of our kernel integrity framework is based on the Linux kernel. Currently for each supported kernel version some modifications are necessary. In order to extend the applicability of our system a kernel version agnostic abstraction layer needs to be implemented. This layer should contain abstract information about the different self-patching mechanisms that need to be validated and information about the corresponding in memory representation of important data structures. That is different kernel versions rename or change the layout of required kernel objects. In order to support
Conclusion
8.3. Future Work
future kernel versions, an abstract database needs to be created that contains information on where to find specific information within kernel memory.
In addition, since our work on this topic another runtime self-modification mechanism has been included into the main line kernel.
That is, the kernel now supports KPatch1. With this mechanism security patches can be applied during runtime, eliminating the need for a kernel reboot after updates. With KPatch entire functions can be replaced during runtime. If the new version of the function is shorter than the old version, the new function replaces the old function. If the new function requires more space, the new function is placed in another part of executable memory and an unconditional branch to the new function is inserted at the beginning of the old function. Our framework currently does not support the validation of this new feature. Thus support for this feature should be included as part of future work.
Next, the ideas and the prototype implementation created through-out this thesis currently are only thoroughly tested on the Intel ar-chitecture. The prototype could be extended to further architectures such as for example the ARM architecture. With this, its scope could be extended from validating the integrity of servers in a cloud environment, to for example validate the OS code integrity in mobile devices. This seems even more important, as these devices are more commonly used and are thus also a profitable attack target. Finally, the scope of our kernel code integrity prototype was restricted to the Linux platform. Thus it would be interesting to also study the wide spread Windows platform for similar runtime code patching mechanisms.
Code Pointer Integrity During our work on CPE, we implemented a simple algorithm to validate the contents of kernel stacks. As we explained, this algorithm is currently not able to validate the contents of a stack reliably. Thus future work should be dedicated to this topic.
1http://rhelblog.redhat.com/2014/02/26/kpatch/
8. Conclusion and Future Work
A technique should be proposed, that is able to reliably validate the content of a given stack frame in memory. While this problem seems to be easily solvable in theory, it is not trivial, as the stack might contain additional unrelated pointers and old uninitialized contents.
An extension of this work could also give hints on whether the given stack is a legitimate stack that was created during program execution or whether the execution of the sequence of return instructions on the stack results in malicious behavior. We already proposed this problem as, what we think is an important research question (Q5) in the beginning of this thesis. Another topic for future work is the inclusion of symbolic execution. Once a malicious pointer is identified by our approach, more information about the potential gadget could be extracted. With this a further classification of the pointer could be made. For example, concerning information about the different registers or memory addresses that are manipulated by the gadget.
Another interesting topic would be to extend existing research in the area of CFI to also be able to handle how, object orientation is emulated within C program such as the Linux kernel. As already introduced in Chapter 4 existing CFI mechanisms already aim to handle C++ vtable structures. The Linux kernel uses a similar mech-anism to simulate object oriented functionality. It contains dedicated datastructures (*_ops), similar to vtables, that contain pointers to functions that are directly related to a certain datastructure. In contrast to C++ vtables, the C structures to not contain a reference to their corresponding*_opsdata structures. First such a relation should be automatically inferred, for example from the source code, or by analyzing the function signatures of the corresponding func-tions. Then, mechanisms should be developed, to efficiently check the integrity of such data structures in memory.
Application to Userspace Additional future work should be con-ducted in the validation of userspace processes during runtime. One important part is the generation of ground truth for the ifunc relocation mechanism introduced in Section 7.2. This could be