Evolutionary Security

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) cant call it index any more,
  its now 0xDEADBEEF.
• Now instead of jump analysis, its memory
  analysis can only be performed at runtime,
  unless youre 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 its 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! Youve heard it before.
• Read/write/use checking never do anything with
  data unless youve 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 youre 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
  its 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 dont write code this way