1. Evolutionary Security CS 610: Advanced Security Gabriel Daleson

2. Economic Perspective Time space, and secrets are scarce Complexity of assembly code is (roughly) of quadratic order, so… Attackers have an economy of scale defenders do not

3. “The Ultimate Attack” Important first step: kidnap sysadmin (and anyone else who might try to stop you, particularly those with root access) and keep locked up in cellar. At this point, target computer is just a finite state machine. Finite state machines can be analyzed and modified at will. (Physical access)

4. “The Ultimate Defense” “You only have to outrun the halfling” idea Make the attack too hard. Note economic perspective! Security through obscurity

5. Automating it The bad guys write viruses – automatic attackers… so defenders write automatic obfuscators. This is evolutionary defense.

6. Geometric Concerns The set of all I/O-preserving transformations on a single program is a group. composing two I/O-preserving transformations gives you an I/O- preserving transformation (do one, then the other) doing nothing preserves I/O

7. Geometric Concerns (cont.) Removing an I/O-preserving transformation preserves I/O Composition of I/O-preserving transformations is associative So, generators?

8. Generating Transformations – 1. Instruction Reordering Given a sequence of instructions, shuffle them. Works well on linear programs. Requires analysis of everything that jumps to reordered program (COME FROM) For real-world programs, *lots* of analysis required to maintain functionality.

9. Generating Transformations – 2. Variable Substitution Instead of using a nice clean symbol table, move variables around in memory. Attackers (and you) can’t call it index any more, it’s now 0xDEADBEEF. Now instead of jump analysis, it’s memory analysis – can only be performed at runtime, unless you’re a big fan of heap corruption.

10. Generating Transformations – 3. Jump Insertion/Deletion Easy – throw in lots of spurious GOTO/jmp instructions. Finally, an attack we can do without analysis! …but your computer will end up slower than an abacus. (Jumps take a long time!) We already do delete jumps – it’s called optimization

11. Generating Transformations – 4. Call Insertion/Deletion Just like jump insertion/deletion, but with function calls Sure, it does help obfuscate …and, in addition to making your computer slow, it now also chews through stack space.

12. Generating Transformations – 5. Garbage Insertion Throw in trash instructions. You can do it, and it only slows your computer down a little. Very possible! Many instruction sets have equivalent instructions or equivalent codings for instructions that can be substituted with no effect on I/O.

13. Generating Transformations – 6. Simulation Write an interpreter for a different coding scheme, and translate your instructions back and forth. Labor intensive – someone has to put the interpreter together. Slow, too. (Java?)

14. Generating Transformations – 7. Build & Execute Instead of making your code interpret, make it write some code itself and compile that. We do this already, in some sense – JIT compiling? Not that slow So where are you going to get the compiler?

15. Generating Transformations – 8. Redundant Instructions Test things multiple times. Good idea! You’ve heard it before. Read/write/use checking – never do anything with data unless you’ve looked at it! Some slowdown, but makes up for it in fixing bugs.

16. Other Generating Transformations Anti-debugger mutations - these will depend on which debugger you’re anti. Program interleaving; just like reordering, but doing it with multiple programs.

17. Algebraic Considerations This is not a minimal set of generators; you put calls together from jumps. Even if it is minimal, is it free? What sort of structure does this group have if it’s not free?

18. “Evolutionary” Sort of a misnomer, in a biological sense. Randomness? Selection? Reproduction?

19. But does it work? At least in the small case given, yes. Hard to get a real world test – gobs of compile and run-time program analysis required

20. Human Aspects “Ultimate Attack” requires sysadmins to do nothing. This is evolutionary, if the defender is doing the evolution… …then again, all security is evolutionary in that paradigm.

21. Problems Is this an economy of scale for the defender? this trades speed (almost all of it) for security The Gödel, Escher, Bach aspect – attack the evolver Humans don’t write code this way