gaurav s. kc, angelos d. keromytis columbia university e-nexsh: os fortification protecting software...
Post on 20-Dec-2015
213 views
TRANSCRIPT
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
07 NOV, 2005. ACSAC 3Gaurav S. Kc / Columbia University
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
07 NOV, 2005. ACSAC 4Gaurav S. Kc / Columbia University
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
07 NOV, 2005. ACSAC 5Gaurav S. Kc / Columbia University
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
07 NOV, 2005. ACSAC 6Gaurav S. Kc / Columbia University
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
07 NOV, 2005. ACSAC 7Gaurav S. Kc / Columbia University
0xbfffffff
foo:
bar:
program stack frames
main:
bar() { socket(...);}
foo() { bar(); }main() { foo(); }
program.c
socket: libc stack frames
socket() { ... int $0x80 ; trap instr. ...}
libc.so
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:
System Calls via LIBCSystem Calls via LIBC
Machine instruction in LIBC .text section
07 NOV, 2005. ACSAC 8Gaurav S. Kc / Columbia University
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
07 NOV, 2005. ACSAC 9Gaurav S. Kc / Columbia University
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
07 NOV, 2005. ACSAC 10Gaurav S. Kc / Columbia University
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!
07 NOV, 2005. ACSAC 11Gaurav S. Kc / Columbia University
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
07 NOV, 2005. ACSAC 12Gaurav S. Kc / Columbia University
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
07 NOV, 2005. ACSAC 13Gaurav S. Kc / Columbia University
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
07 NOV, 2005. ACSAC 14Gaurav S. Kc / Columbia University
0xbfffffff
foo:
bar:
program stack frames
main:
bar() { socket(...);}
foo() { bar(); }main() { foo(); }
program.c
0xffffffff KERNEL MEMORY
USERSPACE MEMORY
sock_create:
kernelsystem_call() { // validate “return address” call *0x0(,%eax,4);}sys_socket() { sock_create(); }sock_create() { sock_alloc(); }
system-call stack frames
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
07 NOV, 2005. ACSAC 15Gaurav S. Kc / Columbia University
e-NeXSh: Validating the e-NeXSh: Validating the Call StackCall Stack
07 NOV, 2005. ACSAC 16Gaurav S. Kc / Columbia University
0xbfffffff
foo:......call socket
program stack frames
main:
bar() { socket(...);}
foo() { bar(); }main() { foo(); }
program.c
0xffffffff KERNEL MEMORY
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
07 NOV, 2005. ACSAC 17Gaurav S. Kc / Columbia University
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
07 NOV, 2005. ACSAC 18Gaurav S. Kc / Columbia University
0xbfffffff
program stack frames
main:
bar() { socket(...);}
foo() { bar(); }main() { foo(); }
program.c
kernel
0xffffffff KERNEL MEMORY
USERSPACE MEMORY
system_call() { // validate “return address” call *0x0(,%eax,4);}sys_socket() { sock_create(); }sock_create() { sock_alloc(); }
system-call stack frames
system_call:
e-NeXSh against Injected e-NeXSh against Injected CodeCode
foo:......int $0x80
INVALID return address
07 NOV, 2005. ACSAC 19Gaurav S. Kc / Columbia University
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
07 NOV, 2005. ACSAC 20Gaurav S. Kc / Columbia University
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
07 NOV, 2005. ACSAC 21Gaurav S. Kc / Columbia University
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
07 NOV, 2005. ACSAC 22Gaurav S. Kc / Columbia University
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
07 NOV, 2005. ACSAC 23Gaurav S. Kc / Columbia University
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
07 NOV, 2005. ACSAC 24Gaurav S. Kc / Columbia University
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
07 NOV, 2005. ACSAC 25Gaurav S. Kc / Columbia University
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)
07 NOV, 2005. ACSAC 26Gaurav S. Kc / Columbia University
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
07 NOV, 2005. ACSAC 27Gaurav S. Kc / Columbia University
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
07 NOV, 2005. ACSAC 28Gaurav S. Kc / Columbia University
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