Operating System Protection Through Program Evolution By Dr. F. B. Cohen (© 1992) Program Evolution As a Technique For Defending Against Automated Attacks On Operating Systems Presented By Ben Ihle
1. Outline 2. Introduction 3. Why We Need This 4. How it is done 5. Implementation 6. What And When To Evolve 7. Summary 8. Questions
2. Introduction • System attacks usually dynamic – e. g. password cracking. • System defense usually static (w. r. t. attacks) • The best solution involves computational advantage – it takes more time for the defender to defend, than it does for the attacker to attack. • Perhaps use polymorphism for defending automated attacks, since it is highly dynamic…
3. Why We Need This • Almost all successful attacks involve reverse engineering, then encoding the loophole into an automated program. • Polymorphism is difficult to trace, even for programs. (e. g. virus heuristic scans…) • We must know what price (spatial & temporal) we are willing to pay – ie. how much slower we can allow the programs to run, and the amount of space they use.
4 a. How It Is Done • Instruction Equivalence – E. g. xor ax, ax mov ax, 0 – Encodings: (n/k)e (1 in k swappable instructions, n instructions, e possible replacement codes) • Sequence Equivalence – E. g. x+=5; x+=10; x-=5; – Very flexible – an infinite number of possible encodings.
4 b. How It Is Done • Jump Insertion – Insert random jumps (and move code) • Garbage Insertion – Insert random ‘noise’ into code – E. g. invalid system calls, unused for loops, variables, etc. • Program Intermixing – E. g. sub 1(i, j) and sub 2(j, k) sub(i, j, k) – We mix two procedures, and inside the new procedure, check the input to see which sequence to execute. – Encodings: (2^n) (given 2 programs of length n)
4 c. How It Is Done • Anti-Debugging – Fool debuggers, so that manual program tracing must be used. (Very tedious) – One simple method used is: What the (foreign) debugger sees: 0100 75 01 0102 7 E CD 0104 13 90 00 74 JNZ 0103 ; cond. jump to 103 if nz JLE 00 D 1 ADC DX, [BX+SI+7400] What the CPU sees (since ‘nz’ flag set to true in reality…): 0100 0103 0105 0106 75 01 CD 13 90 00 74 08 JNZ 0103 INT 13 NOP. . . ; cond. Jump to 103 if nz ; system call ; No OPeration
5. Implementation • It is difficult to determine what we can evolve not just any sequence can be reordered, since: – Entry points need to be maintained – Anti-Debug code needs to be intact – Instruction boundaries need to be known • One way is to tag code manually, and track with a special compiler and / or code templates. – Works at a high level, but what about the machine code? We can’t easily tag machine code…
6. What And When To Evolve • Which techniques do we use, and when? • Evolution At the factory – Computationally expensive evolutions, eg. high level changes (e. g. intermix, garbage) since we can build. – Allows product tracking. – Slows down manufacture – can’t just duplicate each disk. (Can manufacture in batches however) • Evolution Upon Installation – Evolve at a lower level, though some high level is possible…(e. g. sequence equivalence, jump insertion) • Evolution At Runtime – Needs to be fast, cheap (e. g. instruction equivalence)
7 a. Summary • No fully working model, though the author implemented a general lisp based evolver, which used a tag based approach. – Used high level evolution methods – Took less than a minute for one evolution and compilation of a simple 1000 line program. • We could also incorporate encryption of the code, and provide decryption at run-time.
7 b. Summary • More mathematical analysis is needed to properly establish the necessary conditions for each type of evolution. • More analysis of the idea is needed, especially if we want to determine the best times to evolve, and the methods that are most effective.
8. Questions • Will anti-debugging always reduce simple attacks which just search for necessary code (e. g. system calls)? • Which concerns do we not have with the alpha achitecture?
8. Answers Will anti-debugging always reduce simple attacks which just search for necessary code (e. g. system calls)? No, since we could just do a search through the raw code for system calls. Which concerns do we not have with the alpha achitecture? Maintaining instruction boundaries, and debug code… in the presented form, it wont work, since alpha instructions a word length.
Скачать презентацию Operating System Protection Through Program Evolution By Dr
d90996ee0adcfb77fd9d2a423e189736.ppt