gaurav s. kc, angelos d. keromytis columbia university e-nexsh: os fortification protecting software...

Gaurav S. Kc, Angelos D. KeromytisGaurav S. Kc, Angelos D. Keromytis

Columbia UniversityColumbia University

e-NeXSh: OS e-NeXSh: OS FortificationFortification

Protecting Software from Protecting Software from Internet MalwareInternet Malware

07 NOV, 2005. ACSAC 2Gaurav S. Kc / Columbia University

Internet MalwareInternet Malware Internet worms and Internet-cracking Internet worms and Internet-cracking

toolstools Override program control to execute Override program control to execute

malcodemalcode Internet WormsInternet Worms

Morris '88, Code Red II '01, Nimda Morris '88, Code Red II '01, Nimda '01, Slapper '02, Blaster '03, MS-SQL '01, Slapper '02, Blaster '03, MS-SQL Slammer '03, Sasser '04Slammer '03, Sasser '04

Automatic propagationAutomatic propagation Internet CrackersInternet Crackers

““j00 j00 got got h4x0r3dh4x0r3d!!”!!” After breaking in, malware will:After breaking in, malware will:

Create backdoors, install rootkits Create backdoors, install rootkits (conceal malcode existence), join a (conceal malcode existence), join a bot-net, generate spambot-net, generate spam

e-NeXSh can thwart such malwaree-NeXSh can thwart such malware

Bane of the InternetBane of the Internet


OutlineOutline

Software Run-Time Environments Software Run-Time Environments (x86/Linux)(x86/Linux) Bugs, and Breaches: Anatomy of AttacksBugs, and Breaches: Anatomy of Attacks

e-NeXSh: OS Fortificatione-NeXSh: OS Fortification Related WorkRelated Work ConclusionsConclusions


Process Run-Process Run-TimeTime

Linux: Multi-processor OSLinux: Multi-processor OS Resource manager and schedulerResource manager and scheduler

Inter-process communication (IPC)Inter-process communication (IPC) Access: network, persistent storage Access: network, persistent storage

devicesdevices Process scheduling and context-Process scheduling and context-

switchingswitching

ProcessProcess: abstraction of: abstraction ofprogram in executionprogram in execution 4GB of virtual memory4GB of virtual memory Code + data segmentsCode + data segments .stack.stack segment segment

Activation recordsActivation records


void function(char *s, float y, int x) { int a; int b; char buffer[SIZE]; int c; strcpy(buffer, s); return;}

function parametersreturn addressold frame pointerautomatic variables

int xfloat ychar *s

ret. addr: 0x0abcdef0old fp: 0x4fedcba8

int aint b

char buffer[SIZE]int c

PC

FPSP

Process Run-TimeProcess Run-Time

Activation recordsActivation records

Activation Frame Header

return_address, old_frame_pointer

Activation Frame Header

return_address, old_frame_pointer


0xbfffffff

foo:

bar:

program stack frames

main:

bar() { ... int $0x80 ; trap instr. ...}

foo() { bar(); }main() { foo(); }

program.c

socki_lookup

kernel

0xffffffff KERNEL MEMORY

USERSPACE MEMORY

sock_create:

sock_alloc:

system_call() { call *0x0(,%eax,4); }sys_socket() { sock_create(); }sock_create() { sock_alloc(); }sock_alloc() { socki_lookup(); }socki_lookup() { ... }

system-call stack frames

system_call:

sys_socket:

Invoking System CallsInvoking System Calls

Machine instruction in .text section

Applications accessApplications accesskernel resourceskernel resources


0xbfffffff

foo:

bar:


main:

bar() { socket(...);}

foo() { bar(); }main() { foo(); }

program.c

socket: libc stack frames

socket() { ... int $0x80 ; trap instr. ...}

libc.so

socki_lookup

kernel


USERSPACE MEMORY

sock_create:

sock_alloc:

system_call() { call *0x0(,%eax,4); }sys_socket() { sock_create(); }sock_create() { sock_alloc(); }sock_alloc() { socki_lookup(); }socki_lookup() { ... }


system_call:

sys_socket:

System Calls via LIBCSystem Calls via LIBC

Machine instruction in LIBC .text section


C: A low-level, systems language with unsafe features No bounds-checking. Not strongly typed.

Arbitrary memory overwrites Common security vulnerabilities

Buffer overflows Format-string vulnerability Integer overflows Double-free vulnerability

Security VulnerabilitiesSecurity Vulnerabilities


Anatomy of a Process-Anatomy of a Process-Subversion AttackSubversion Attack

Analysis of common attack techniquesAnalysis of common attack techniques Phrack magazine, BugTraq, worms in “the wild”Phrack magazine, BugTraq, worms in “the wild”

Stages of a process-subversion attackStages of a process-subversion attack1.1. Trigger Trigger vulnerabilityvulnerability in software in software2.2. Overwrite Overwrite codecode pointerpointer3.3. Execute Execute malcode malcode of the attacker’s choosing, and of the attacker’s choosing, and

invoke system callsinvoke system calls


Component ElementsComponent Elements (C.E.) of an attack(C.E.) of an attack1.1. exploitable vulnerabilityexploitable vulnerability

e.g., buffer overflows, format-string e.g., buffer overflows, format-string vulnerabilitiesvulnerabilities

2.2. overwritable code pointeroverwritable code pointere.g., return address, function pointer e.g., return address, function pointer variablesvariables

3.3. executable malcodeexecutable malcodee.g., machine code injected into data e.g., machine code injected into data memory, existing application or LIBC code memory, existing application or LIBC code

Process-Subversion Process-Subversion Attacks contd.Attacks contd.

Focus of e-NeXSh!


Methods of AttackMethods of Attack

void function(char *s, float y, int x) { int a; int b; char buffer[SIZE]; int c; strcpy(buffer, s); return;}

PC

int xfloat ychar *s

ret. addr: 0x0abcdef0old fp: 0x4fedcba8

int aint b

char buffer[SIZE]int c

Stacksmashing (Code Injection)

Overrun bufferOverwrite return addressInjected code invokes system call

...

...&buffer&buffer&buffer......int $0x80nopnopnop

...

...&buffer&buffer&buffer...call &systempush “/bin/sh”nopnopnop

Stacksmashing (LIBC-Based)

Overrun bufferOverwrite return addressInjected code invokes LIBC function

Buffer-overflow vulnerability


OutlineOutline

Software Run-Time Environments Software Run-Time Environments (x86/Linux)(x86/Linux) Bugs, and Breaches: Anatomy of AttacksBugs, and Breaches: Anatomy of Attacks

e-NeXSh: OS Fortificatione-NeXSh: OS Fortification Related WorkRelated Work ConclusionsConclusions


Monitor LIBC function invocationsMonitor LIBC function invocations If (If (call stackcall stack doesn’t match doesn’t match call graphcall graph))

exit (exit (LIBC-based attackLIBC-based attack););

Monitor system-call invocationsMonitor system-call invocations If (If (system callsystem call invoked from invoked from data memorydata memory))

exit (exit (injected code executioninjected code execution););

Explicit policy definitions required!Explicit policy definitions required! Use program disassembly information and Use program disassembly information and

memory layout.memory layout. Code can still execute on stack/heap, just Code can still execute on stack/heap, just

cannot invoke system calls directly or via cannot invoke system calls directly or via LIBC functionsLIBC functions

e-NeXSh: Monitoring e-NeXSh: Monitoring Processes for Anomalous Processes for Anomalous and Malicious Behaviourand Malicious Behaviour


0xbfffffff

foo:

bar:


main:


foo() { bar(); }main() { foo(); }

program.c


USERSPACE MEMORY

sock_create:

kernelsystem_call() { // validate “return address” call *0x0(,%eax,4);}sys_socket() { sock_create(); }sock_create() { sock_alloc(); }


system_call:

sys_socket:

e-NeXSh: System Calls e-NeXSh: System Calls via LIBCvia LIBC

socket: e-NeXSh.so

socket() { // validate call stack libc.so :: socket();}

e-NeXSh.so

socket() { int $0x80 ; trap instr.}

libc.so

socket: libc stack frames

socki_lookup

sock_alloc:

Valid return address

Valid call stack


e-NeXSh: Validating the e-NeXSh: Validating the Call StackCall Stack


0xbfffffff

foo:......call socket


main:


foo() { bar(); }main() { foo(); }

program.c


USERSPACE MEMORY

e-NeXSh against LIBC e-NeXSh against LIBC attacksattacks

socket: e-NeXSh.so

socket() { // validate call stack libc.so :: socket();}

e-NeXSh.so

INVALID call stack


e-NeXSh: User-Space e-NeXSh: User-Space ComponentComponent

Interposition of calls to LIBC functionsInterposition of calls to LIBC functions Define Define LD_PRELOADLD_PRELOAD environment variable environment variable

Validate call stacksValidate call stacks Conduct stack walk to determine caller-callee Conduct stack walk to determine caller-callee

pairspairs Validate caller-callee pairs against program codeValidate caller-callee pairs against program code

Derive function boundaries from disassembly Derive function boundaries from disassembly informationinformation

Inspect Inspect .text.text segment to determine segment to determine callcall instructions instructions where caller invokes calleewhere caller invokes callee

If okay, allow through to LIBCIf okay, allow through to LIBC


0xbfffffff


main:


foo() { bar(); }main() { foo(); }

program.c

kernel


USERSPACE MEMORY

system_call() { // validate “return address” call *0x0(,%eax,4);}sys_socket() { sock_create(); }sock_create() { sock_alloc(); }


system_call:

e-NeXSh against Injected e-NeXSh against Injected CodeCode

foo:......int $0x80

INVALID return address


e-NeXSh: Kernel-Mode e-NeXSh: Kernel-Mode ComponentComponent

Interposition of system calls in kernelInterposition of system calls in kernel Extended the system-call handler codeExtended the system-call handler code

Validate call sites of system-call invocationsValidate call sites of system-call invocations Extract “return address” of system call from Extract “return address” of system call from

stackstack Match against process’ virtual memory address Match against process’ virtual memory address

ranges for all ranges for all .text.text segments segments int $0x80int $0x80 instruction must exist in a instruction must exist in a .text.text segment segment

If okay, allow through to system call functionIf okay, allow through to system call function


e-NeXSh: faqe-NeXSh: faq Can the attacker change write-permissions on data Can the attacker change write-permissions on data

pages?pages? No, this can only be done via a system callNo, this can only be done via a system call

Can the attacker spoof the return address for system-call Can the attacker spoof the return address for system-call invocations?invocations? No, the kernel’s system-call handler sets this upNo, the kernel’s system-call handler sets this up

Can the attacker fake a valid stack, and then invoke Can the attacker fake a valid stack, and then invoke LIBC?LIBC? No, we can randomise the offsets for the .stack and .text No, we can randomise the offsets for the .stack and .text

segments, and also randomise the old-FP and return addresses segments, and also randomise the old-FP and return addresses on the stack. This prevents an attacker from creating a seemingly on the stack. This prevents an attacker from creating a seemingly valid, but fake stack.valid, but fake stack.

What are the modifications to Linux?What are the modifications to Linux? Very minimalVery minimal: assembly code (~10LOC) and C code (~50LOC) in : assembly code (~10LOC) and C code (~50LOC) in

the kernel. ~100LOC of C code for LIBC wrappersthe kernel. ~100LOC of C code for LIBC wrappers What are the performance overheads?What are the performance overheads?

See results for See results for ApacheBench benchmarks and UNIX utilitiesApacheBench benchmarks and UNIX utilities


Performance OverheadPerformance Overhead

1.55% average decrease (± 2.14% std. deviation) 1.55% average decrease (± 2.14% std. deviation) in request-handling capacity for Apache-1.3.23-11in request-handling capacity for Apache-1.3.23-11

Apache Macro-benchmarks: ApacheBench

14796.128±244.96

14663.876±142.90

14566.668±197.86

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

10000

11000

12000

13000

14000

15000A

vera

ge

# R

equ

ests

per

sec

on

d

(wit

h s

td.

dev

iati

on

)

Apache Apache with e-NeXSh disabled Apache with e-NeXSh enabled


Performance OverheadPerformance Overhead

e-NeXSh macro-benchmark: UNIX utilitiese-NeXSh macro-benchmark: UNIX utilities Processing Processing glibc-2.2.5glibc-2.2.5

ctags -Rctags -R ; ; tar -ctar -c ; ; gzipgzip ; ; scp user@localhost:scp user@localhost:

Larger standard deviation than (at times, negative) Larger standard deviation than (at times, negative) overheadsoverheads


Limitations. Future WorkLimitations. Future Work

Indirect call instructions in stack Indirect call instructions in stack trace?trace? Harder to validate call stackHarder to validate call stack Need list of valid Need list of valid indirect callers indirect callers for for

functions in call stackfunctions in call stack Static data-flow analysis to determine all Static data-flow analysis to determine all

run-time values for function pointers, C++ run-time values for function pointers, C++ VPTRsVPTRs

Collect training data to determine valid call Collect training data to determine valid call stacks with indirect callsstacks with indirect calls


OutlineOutline

Software Run-Time Environments Software Run-Time Environments (x86/Linux)(x86/Linux) Bugs and Breaches: Anatomy of AttacksBugs and Breaches: Anatomy of Attacks

e-NeXSh: OS Fortificatione-NeXSh: OS Fortification Related WorkRelated Work

System-call interpositionSystem-call interposition Preventing execution of injected codePreventing execution of injected code LIBC address-space obfuscationLIBC address-space obfuscation

ConclusionsConclusions


Related Work:Related Work:System-Call InterpositionSystem-Call Interposition

Host-based Intrusion Detection Host-based Intrusion Detection Systems (IDS)Systems (IDS) Forrest (HotOS-97), Wagner (S&P-01)Forrest (HotOS-97), Wagner (S&P-01) Co-relate observed Co-relate observed sequencessequences of system of system

calls with static FSM-based models to calls with static FSM-based models to detect intrusionsdetect intrusions

Imprecise (false positives) or high Imprecise (false positives) or high overheadsoverheads

Vulnerable to mimicry attacks, Wagner Vulnerable to mimicry attacks, Wagner (CCS-02)(CCS-02)


Related Work:Related Work:Non-Executable Stack/HeapNon-Executable Stack/Heap Instruction-Set RandomisationInstruction-Set Randomisation

Barrantes (CCS-03), Kc (CCS-03)Barrantes (CCS-03), Kc (CCS-03) Randomised machine instruction sets to disable Randomised machine instruction sets to disable

injected codeinjected code High overhead due to software emulation of High overhead due to software emulation of

processorprocessor Non-Executable Stack/HeapNon-Executable Stack/Heap

Openwall, PaX, OpenBSD W^X, Redhat ExecShield, Openwall, PaX, OpenBSD W^X, Redhat ExecShield, Intel NXIntel NX

Disable execution of injected code in data memoryDisable execution of injected code in data memory Complex workarounds required for applications with Complex workarounds required for applications with

a genuine need for an executable stack or heapa genuine need for an executable stack or heap


Obfuscation of LIBC Functions’ Obfuscation of LIBC Functions’ AddressesAddresses Bhatkar (SEC-03), Chew (CMU-TR-02), Bhatkar (SEC-03), Chew (CMU-TR-02),

PaX-ASLRPaX-ASLR Prevent use of LIBC functions in attackPrevent use of LIBC functions in attack Vulnerable to brute-forcing, Shacham Vulnerable to brute-forcing, Shacham

(CCS-04)(CCS-04)

Related Work:Related Work:Address-Space Address-Space RandomisationRandomisation


ConclusionsConclusions

e-NeXSh is a simple, low overhead e-NeXSh is a simple, low overhead OS-fortification technique.OS-fortification technique. Implemented prototype on the Linux Implemented prototype on the Linux

kernelkernel Thwarts malicious invocations of system Thwarts malicious invocations of system

calls, both directly by injected code, and calls, both directly by injected code, and via LIBC functionsvia LIBC functions

gaurav s. kc, angelos d. keromytis columbia university e-nexsh: os fortification protecting software...

Documents