e- -NeXSh: OS Fortification NeXSh: OS Fortification e Protecting - - PowerPoint PPT Presentation

▶
e nexsh os fortification nexsh os fortification e
SMART_READER_LITE
LIVE PREVIEW

e- -NeXSh: OS Fortification NeXSh: OS Fortification e Protecting - - PowerPoint PPT Presentation

Feb 20, 2024 290 likes •583 views

e- -NeXSh: OS Fortification NeXSh: OS Fortification e Protecting Software from Internet Malware Protecting Software from Internet Malware Gaurav S. Kc Kc, , Angelos Angelos D. D. Keromytis Keromytis Gaurav S. Columbia University

slide-1
SLIDE 1

Gaurav S. Gaurav S. Kc Kc, , Angelos Angelos D.

  • D. Keromytis

Keromytis Columbia University Columbia University

e e-

  • NeXSh: OS Fortification

NeXSh: OS Fortification

Protecting Software from Internet Malware Protecting Software from Internet Malware

slide-2
SLIDE 2

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

  • Internet Malware

Internet Malware

  • Internet worms and Internet

Internet worms and Internet-

  • cracking tools

cracking tools

  • Override program control to execute malcode

Override program control to execute malcode

  • Internet Worms

Internet Worms

  • Morris '88, Code Red II '01, Nimda '01,

Morris '88, Code Red II '01, Nimda '01, Slapper '02, Blaster '03, MS Slapper '02, Blaster '03, MS-

  • SQL Slammer '03,

SQL Slammer '03, Sasser '04 Sasser '04

  • Automatic propagation

Automatic propagation

  • Internet Crackers

Internet Crackers

  • “

“j00 j00 got got h4x0r3d h4x0r3d!!” !!”

  • After breaking in, malware will:

After breaking in, malware will:

  • Create backdoors, install

Create backdoors, install rootkits rootkits (conceal (conceal malcode existence), join a malcode existence), join a bot bot-

  • net, generate

net, generate spam spam

  • e

e-

  • NeXSh

NeXSh can thwart such can thwart such malware malware

Bane of the Internet Bane of the Internet

slide-3
SLIDE 3

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

Outline Outline

  • Software Run

Software Run-

  • Time Environments (x86/Linux)

Time Environments (x86/Linux)

  • Bugs, and Breaches: Anatomy of Attacks

Bugs, and Breaches: Anatomy of Attacks

  • e

e-

  • NeXSh

NeXSh: OS Fortification : OS Fortification

  • Related Work

Related Work

  • Conclusions

Conclusions

slide-4
SLIDE 4

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

Process Run Process Run-

  • Time

Time

  • Linux: Multi

Linux: Multi-

  • processor OS

processor OS

  • Resource manager and scheduler

Resource manager and scheduler

  • Inter

Inter-

  • process communication (IPC)

process communication (IPC)

  • Access: network, persistent storage devices

Access: network, persistent storage devices

  • Process scheduling and context

Process scheduling and context-

  • switching

switching

  • Process

Process: abstraction of : abstraction of program in execution program in execution

  • 4GB of virtual memory

4GB of virtual memory

  • Code + data segments

Code + data segments

  • .stack

.stack segment segment

  • Activation records

Activation records

slide-5
SLIDE 5

07 NOV, 2005. ACSAC 5 Gaurav 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; }

PC FP SP

Process Run Process Run-

  • Time

Time

  • Activation records

Activation records

Activation Frame Header return_address, old_frame_pointer Activation Frame Header return_address, old_frame_pointer

slide-6
SLIDE 6

07 NOV, 2005. ACSAC 6 Gaurav 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 Calls Invoking System Calls

Machine instruction in .text section

  • Applications access

Applications access kernel resources kernel resources

slide-7
SLIDE 7

07 NOV, 2005. ACSAC 7 Gaurav 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 LIBC System Calls via LIBC

Machine instruction in LIBC .text section

slide-8
SLIDE 8

07 NOV, 2005. ACSAC 8 Gaurav 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 Vulnerabilities Security Vulnerabilities

slide-9
SLIDE 9

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

Anatomy of a Process Anatomy of a Process-

  • Subversion

Subversion Attack Attack

  • Analysis of common attack techniques

Analysis of common attack techniques

  • Phrack magazine, BugTraq, worms in “the wild”

Phrack magazine, BugTraq, worms in “the wild”

  • Stages of a process

Stages of a process-

  • subversion attack

subversion attack

1. 1.

Trigger Trigger vulnerability vulnerability in software in software

2. 2.

Overwrite Overwrite code code pointer pointer

3. 3.

Execute Execute malcode malcode of the attacker’s choosing, and invoke system calls

  • f the attacker’s choosing, and invoke system calls
slide-10
SLIDE 10

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

  • Component Elements

Component Elements (C.E.) of an attack (C.E.) of an attack

1. 1.

exploitable vulnerability exploitable vulnerability e.g., buffer overflows, format e.g., buffer overflows, format-

  • string vulnerabilities

string vulnerabilities

2. 2.

  • verwritable code pointer
  • verwritable code pointer

e.g., return address, function pointer variables e.g., return address, function pointer variables

3. 3.

executable malcode executable malcode e.g., machine code injected into data memory, e.g., machine code injected into data memory, existing application or LIBC code existing application or LIBC code

Process Process-

  • Subversion Attacks

Subversion Attacks contd. contd.

Focus of e-NeXSh!

slide-11
SLIDE 11

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

Methods of Attack Methods 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 x float y char *s

  • ret. addr:

0x0abcdef0

  • ld fp:

0x4fedcba8 int a int b char buffer[SIZE] int c

Stacksmashing (Code Injection) Overrun buffer Overwrite return address Injected code invokes system call ... ... &buffer &buffer &buffer ... ... int $0x80 nop nop nop ... ... &buffer &buffer &buffer ... call &system push “/bin/sh” nop nop nop Stacksmashing (LIBC-Based) Overrun buffer Overwrite return address Injected code invokes LIBC function

Buffer-overflow vulnerability

slide-12
SLIDE 12

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

Outline Outline

  • Software Run

Software Run-

  • Time Environments (x86/Linux)

Time Environments (x86/Linux)

  • Bugs, and Breaches: Anatomy of Attacks

Bugs, and Breaches: Anatomy of Attacks

  • e

e-

  • NeXSh

NeXSh: OS Fortification : OS Fortification

  • Related Work

Related Work

  • Conclusions

Conclusions

slide-13
SLIDE 13

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

  • Monitor LIBC function invocations

Monitor LIBC function invocations

If ( If (call stack call stack doesn’t match doesn’t match call graph call graph) ) exit ( exit (LIBC LIBC-

  • based attack

based attack); );

  • Monitor system

Monitor system-

  • call invocations

call invocations

If ( If (system call system call invoked from invoked from data memory data memory) ) exit ( exit (injected code execution injected code execution); );

  • Explicit policy definitions required!

Explicit policy definitions required!

  • Use program disassembly information and memory layout.

Use program disassembly information and memory layout.

  • Code can still execute on stack/heap, just cannot

Code can still execute on stack/heap, just cannot invoke system calls directly or via LIBC functions invoke system calls directly or via LIBC functions

e e-

  • NeXSh: Monitoring Processes for

NeXSh: Monitoring Processes for Anomalous and Malicious Behaviour Anomalous and Malicious Behaviour

slide-14
SLIDE 14

07 NOV, 2005. ACSAC 14 Gaurav 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:

kernel

system_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 e-

  • NeXSh: System Calls via LIBC

NeXSh: System Calls via 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

slide-15
SLIDE 15

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

e e-

  • NeXSh: Validating the Call Stack

NeXSh: Validating the Call Stack

slide-16
SLIDE 16

07 NOV, 2005. ACSAC 16 Gaurav 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 e-

  • NeXSh against LIBC attacks

NeXSh against LIBC attacks

socket:

e-NeXSh.so

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

e-NeXSh.so

INVALID call stack

slide-17
SLIDE 17

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

e e-

  • NeXSh: User

NeXSh: User-

  • Space Component

Space Component

  • Interposition of calls to LIBC functions

Interposition of calls to LIBC functions

  • Define

Define LD_PRELOAD LD_PRELOAD environment variable environment variable

  • Validate call stacks

Validate call stacks

  • Conduct stack walk to determine caller

Conduct stack walk to determine caller-

  • callee pairs

callee pairs

  • Validate caller

Validate caller-

  • callee pairs against program code

callee pairs against program code

  • Derive function boundaries from disassembly information

Derive function boundaries from disassembly information

  • Inspect

Inspect .text .text segment to determine segment to determine call call instructions instructions where caller invokes callee where caller invokes callee

  • If okay, allow through to LIBC

If okay, allow through to LIBC

slide-18
SLIDE 18

07 NOV, 2005. ACSAC 18 Gaurav 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 e-

  • NeXSh against Injected Code

NeXSh against Injected Code

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

INVALID return address

slide-19
SLIDE 19

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

e e-

  • NeXSh: Kernel

NeXSh: Kernel-

  • Mode Component

Mode Component

  • Interposition of system calls in kernel

Interposition of system calls in kernel

  • Extended the system

Extended the system-

  • call handler code

call handler code

  • Validate call sites of system

Validate call sites of system-

  • call invocations

call invocations

  • Extract “return address” of system call from stack

Extract “return address” of system call from stack

  • Match against process’ virtual memory address

Match against process’ virtual memory address ranges for all ranges for all .text .text segments segments

  • int $0x80

int $0x80 instruction must exist in a instruction must exist in a .text .text segment segment

  • If okay, allow through to system call function

If okay, allow through to system call function

slide-20
SLIDE 20

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

e e-

  • NeXSh: faq

NeXSh: faq

  • Can the attacker change write

Can the attacker change write-

  • permissions on data pages?

permissions on data pages?

  • No, this can only be done via a system call

No, this can only be done via a system call

  • Can the attacker spoof the return address for system

Can the attacker spoof the return address for system-

  • call

call invocations? invocations?

  • No, the kernel’s system

No, the kernel’s system-

  • call handler sets this up

call handler sets this up

  • Can the attacker fake a valid stack, and then invoke LIBC?

Can the attacker fake a valid stack, and then invoke LIBC?

  • No, we can

No, we can randomise randomise the offsets for the .stack and .text segments, and the offsets for the .stack and .text segments, and also also randomise randomise the old the old-

  • FP and return addresses on the stack. This

FP and return addresses on the stack. This prevents an attacker from creating a seemingly valid, but fake s prevents an attacker from creating a seemingly valid, but fake stack. tack.

  • What are the modifications to Linux?

What are the modifications to Linux?

  • Very minimal

Very minimal: assembly code (~10LOC) and C code (~50LOC) in the : assembly code (~10LOC) and C code (~50LOC) in the

  • kernel. ~100LOC of C code for LIBC wrappers
  • 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 utilities ApacheBench benchmarks and UNIX utilities

slide-21
SLIDE 21

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

Performance Overhead Performance Overhead

1.55% average decrease (± 2.14% std. deviation) 1.55% average decrease (± 2.14% std. deviation) in request in request-

  • handling capacity for Apache

handling capacity for Apache-

  • 1.3.23

1.3.23-

  • 11

11

Apache Macro-benchmarks: ApacheBench

14796.128 ±244.96 14663.876 ±142.90 14566.668 ±197.86

1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 11000 12000 13000 14000 15000

Average # Requests per second (with std. deviation)

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

slide-22
SLIDE 22

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

Performance Overhead Performance Overhead

  • e

e-

  • NeXSh macro

NeXSh macro-

  • benchmark: UNIX utilities

benchmark: UNIX utilities

  • Processing

Processing glibc glibc-

  • 2.2.5

2.2.5

  • ctags

ctags -

  • R

R ; ; tar tar -

  • c

c ; ; gzip gzip ; ; scp scp user@localhost user@localhost: :

  • Larger standard deviation than (at times, negative) overheads

Larger standard deviation than (at times, negative) overheads

slide-23
SLIDE 23

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

  • Limitations. Future Work
  • Limitations. Future Work
  • Indirect call instructions in stack trace?

Indirect call instructions in stack trace?

  • Harder to validate call stack

Harder to validate call stack

  • Need list of valid

Need list of valid indirect callers indirect callers for functions in call for functions in call stack stack

  • Static data

Static data-

  • flow analysis to determine all run

flow analysis to determine all run-

  • time values

time values for function pointers, C++ VPTRs for function pointers, C++ VPTRs

  • Collect training data to determine valid call stacks with

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

slide-24
SLIDE 24

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

Outline Outline

  • Software Run

Software Run-

  • Time Environments (x86/Linux)

Time Environments (x86/Linux)

  • Bugs and Breaches: Anatomy of Attacks

Bugs and Breaches: Anatomy of Attacks

  • e

e-

  • NeXSh

NeXSh: OS Fortification : OS Fortification

  • Related Work

Related Work

  • System

System-

  • call interposition

call interposition

  • Preventing execution of injected code

Preventing execution of injected code

  • LIBC address

LIBC address-

  • space obfuscation

space obfuscation

  • Conclusions

Conclusions

slide-25
SLIDE 25

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

Related Work: Related Work: System System-

  • Call Interposition

Call Interposition

  • Host

Host-

  • based Intrusion Detection Systems (IDS)

based Intrusion Detection Systems (IDS)

  • Forrest (HotOS

Forrest (HotOS-

  • 97), Wagner (S&P

97), Wagner (S&P-

  • 01)

01)

  • Co

Co-

  • relate observed

relate observed sequences sequences of system calls with

  • f system calls with

static FSM static FSM-

  • based models to detect intrusions

based models to detect intrusions

  • Imprecise (false positives) or high overheads

Imprecise (false positives) or high overheads

  • Vulnerable to mimicry attacks, Wagner (CCS

Vulnerable to mimicry attacks, Wagner (CCS-

  • 02)

02)

slide-26
SLIDE 26

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

Related Work: Related Work: Non Non-

  • Executable Stack/Heap

Executable Stack/Heap

  • Instruction

Instruction-

  • Set

Set Randomisation Randomisation

  • Barrantes (CCS

Barrantes (CCS-

  • 03), Kc (CCS

03), Kc (CCS-

  • 03)

03)

  • Randomised

Randomised machine instruction sets to disable injected code machine instruction sets to disable injected code

  • High overhead due to software emulation of processor

High overhead due to software emulation of processor

  • Non

Non-

  • Executable Stack/Heap

Executable Stack/Heap

  • Openwall, PaX,

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

  • Disable execution of injected code in data memory

Disable execution of injected code in data memory

  • Complex workarounds required for applications with a genuine

Complex workarounds required for applications with a genuine need for an executable stack or heap need for an executable stack or heap

slide-27
SLIDE 27

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

  • Obfuscation of LIBC Functions’ Addresses

Obfuscation of LIBC Functions’ Addresses

  • Bhatkar (SEC

Bhatkar (SEC-

  • 03), Chew (CMU

03), Chew (CMU-

  • TR

TR-

  • 02), PaX

02), PaX-

  • ASLR

ASLR

  • Prevent use of LIBC functions in attack

Prevent use of LIBC functions in attack

  • Vulnerable to brute

Vulnerable to brute-

  • forcing, Shacham (CCS

forcing, Shacham (CCS-

  • 04)

04)

Related Work: Related Work: Address Address-

  • Space

Space Randomisation Randomisation

slide-28
SLIDE 28

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

Conclusions Conclusions

  • e

e-

  • NeXSh is a simple, low overhead OS

NeXSh is a simple, low overhead OS-

  • fortification technique.

fortification technique.

  • Implemented prototype on the Linux kernel

Implemented prototype on the Linux kernel

  • Thwarts malicious invocations of system calls, both

Thwarts malicious invocations of system calls, both directly by injected code, and via LIBC functions directly by injected code, and via LIBC functions