Exploiting and Protecting Dynamic Code Generation.

Chengyu Song,Chao Zhang,Tielei Wang,Wenke Lee,David Melski
DOI: https://doi.org/10.14722/ndss.2015.23233
2015-01-01
Abstract:—Many mechanisms have been proposed and de-ployed to prevent exploits against software vulnerabilities. Amongthem, W X is one of the most effective and efficient. W Xprevents memory pages from being simultaneously writableand executable, rendering the decades old shellcode injectiontechnique infeasible.In this paper, we demonstrate that the traditional shellcodeinjection attack can be revived through a code cache injectiontechnique. Specifically, dynamic code generation, a techniquewidely used in just-in-time (JIT) compilation and dynamic binarytranslation (DBT), generates and modifies code on the fly in orderto promote performance or security. The dynamically generatedcode fragments are stored in a code cache, which is writableand executable either at the same time or alternately, resultingin an opportunity for exploitation. This threat is especiallyrealistic when the generated code is multi-threaded, becauseswitching between writable and executable leaves a time windowfor exploitation. To illustrate this threat, we have crafted a proof-of-concept exploit against modern browsers that support WebWorkers.To mitigate this code cache injection threat, we propose anew dynamic code generation architecture. This new architecturerelocates the dynamic code generator to a separate process,in which the code cache is writable. In the original processwhere the generated code executes, the code cache remains read-only. The code cache is synchronized across the writing processand the execution process through shared memory. Interactionbetween the code generator and the generated code is handledtransparently through remote procedure calls (RPC). We haveported the Google V8 JavaScript engine and the Strata DBTto this new architecture. Our implementation experience showedthat the engineering effort for porting to this new architectureis minimal. Evaluation of our prototype implementation showedthat this new architecture can defeat the code cache injectionattack with small performance overhead.
What problem does this paper attempt to address?