Run-Time Randomization to Mitigate Tampering

1. Run-Time Randomization to Mitigate Tampering Bertrand Anckaert, Koen De Bosschere Ghent University MariuszJakubowski, RamarathnamVenkatesan Microsoft Research Second International Workshop on Security, Nara (Japan) October 29th 2007

2. 0101110 00111001010 00101011001000110001110110010111011011001011101010110100010110111111110001010110110011111001010111001110010111 1 11111111111111110 Software is a popular target of tampering

3. Tampering is similar to debugging Tampering Debugging Find and reduce undesired behavior: defects Find and reduce Undesired behavior restrictions Transform behavior of the implementation to behavior intended by provider Transform behavior intended by provider to behavior desired by user

4. The debug cycle versusthe tamper cycle Tampering Debugging known source code unknown binary code

5. Outline • Introduction • Slowing down the Locate-Edit-Test cycle • Locate phase • Alter phase • Test phase • Tools of the trade • Chaff input • Variable program state - Fake input dependencies • Diversity system

6. Repeatability facilitates localization Wanted User input: 11010111001 Buggy program Configuration file: 11010111001 For example: threads

7. Variable chaff input complicates localization User input: 11010111001 Buggy program Variable chaff input: 11010111001 11010111001 11010111001 Configuration file: 11010111001

8. Modularity facilitates modifications Local view of the program suffices Changes do not affect unrelated sections Inter-dependent code complicates modification Exploited by others in previous work: • Code guards • Oblivious hashing

9. Good coverage facilitates testing Impossible to test for • every input • every environment • every combination of applications Testing can only show the presence of undesired behavior, not the absence

10. Many different scenarios complicate tampering Different internal behavior for • Different dates • Different inputs • Different hardware

11. Outline • Introduction • Slowing down the Locate-Edit-Test cycle • Locate phase • Alter phase • Test phase • Tools of the trade • Chaff input • Variable program state - Fake input dependencies • Diversity system

12. Chaff input can come frommany sources • Scheduling of threads • User input • relative speed of keystrokes • mouse movement • System calls • time • load of machine • # cache misses • External service

13. Internal program state and inputare already variable Using profiling spot tuples (p,s) for which • s is constant for a given inputbut variable over different inputs • s is variable for a given input P(s) p c c D(c,i) c D(c,j)

14. Diversity system Diversifier

15. It is easy to generate a large number of versions 1 2 … n 1 0 1 0 1 0 0 1 1 n independent choices between 2 options => 2n possibilities 1 2 … n

16. We have built a diversity system from 14 non-trivial transformations Function factoring Epilogue factoring Basic block factoring Self-modifying code 1-byte modifiers 4-byte modifiers Folding Control flow flattening Jump redirection Opaque predicating Function inlining Basic block inlining Two-way opaque predicating Control flow obfuscation Unfolding Instruction selection Instruction scheduling Code layout Code generation

17. These transformations have a large combined range Range (2n)

18. Run-Time Randomization to Mitigate Tampering Bertrand Anckaert, Koen De Bosschere Ghent University MariuszJakubowski, RamarathnamVenkatesan Microsoft Research Second International Workshop on Security, Nara (Japan) October 29th 2007