Rebootless Security Patches for the Linux Kernel Caglar nver - - PowerPoint PPT Presentation

▶
rebootless security patches for the linux kernel
SMART_READER_LITE
LIVE PREVIEW

Rebootless Security Patches for the Linux Kernel Caglar nver - - PowerPoint PPT Presentation

Feb 09, 2023 238 likes •577 views

Rebootless Security Patches for the Linux Kernel Caglar nver 30.05.2014 Motivation Motivation Why do we care about updates on the fly Why do we care about updates on the fly More than 90% of the attacks exploit known security

slide-1
SLIDE 1

Rebootless Security Patches for the Linux Kernel

Caglar Ünver 30.05.2014

slide-2
SLIDE 2

2

Motivation Motivation

Why do we care about updates on the fly Why do we care about updates on the fly

  • More than 90% of the attacks exploit known security vulnerabilities
  • Important bugfixes and security updates roughly every month
  • Delaying the updates: a great security risk
  • Reboots: Service outage, administrator supervision needed (sysadmins working on

weekends) Challenges Challenges

  • Commodity kernels do not have well defined boundaries between their modules

and components

  • Some modules are always busy
slide-3
SLIDE 3

3

Outline Outline

  • 1. Classification of Kernel Updates
  • Updating Code Only
  • Updating Code and Existing Data
  • 2. DynAMOS - The Basic Approach
  • Quiescence Detection
  • Binary Rewriting
  • Redirection Table
  • 3. LUCOS - Using Virtualization for Live Updates
  • State Transfer
  • 4. Ksplice - Hot Updates at Object Code Level
  • Pre-post Differencing and Run-pre Matching
  • 5. Conclusion and Discussion
slide-4
SLIDE 4

4

  • 1. Classification of Kernel Updates
  • 1. Classification of Kernel Updates
  • Updating Code Only

Updating Code Only

  • Updating Code and Existing Data

Updating Code and Existing Data

  • 2. DynAMOS - The Basic Approach
  • Quiescence Detection
  • Binary Rewriting
  • Redirection Table
  • 3. LUCOS - Using Virtualization for Live Updates
  • State Transfer
  • 4. Ksplice - Hot Updates at Object Code Level
  • Pre-post Differencing and Run-pre Matching
  • 5. Conclusion and Discussion
slide-5
SLIDE 5

5

Classification of Kernel Updates (1) Classification of Kernel Updates (1)

Updates that modify the code only Updates that modify the code only

  • Keeps the existing data structures unchanged
  • May introduce new data structures, global variables
  • Easy to patch, if there are no semantic changes
slide-6
SLIDE 6

6

Classification of Kernel Updates (2) Classification of Kernel Updates (2)

Updates that modify the code and existing Updates that modify the code and existing data data

  • Existing data structures will be changed
  • State transfer from the old to the new data needed
  • What if the semantic of the patched code is changed?
slide-7
SLIDE 7

7

Classification of Kernel Updates (3) Classification of Kernel Updates (3)

Changing the semantic of the code

void foo() { ... do { ... unlock(semaphore); ... lock(semaphore); ... } while(someVar) return; } void foo() { ... do { ... lock(semaphore); ... unlock(semaphore); ... } while(someVar) return; }

slide-8
SLIDE 8

8

  • 1. Classification of Kernel Updates
  • Updating Code Only
  • Updating Code and Existing Data
  • 2. DynAMOS - The Basic Approach
  • 2. DynAMOS - The Basic Approach
  • Quiescence Detection

Quiescence Detection

  • Binary Rewriting

Binary Rewriting

  • Redirection Table

Redirection Table

  • 3. LUCOS - Using Virtualization for Live Updates
  • State Transfer
  • 4. Ksplice - Hot Updates at Object Code Level
  • Pre-post Differencing and Run-pre Matching
  • 5. Conclusion and Discussion
slide-9
SLIDE 9

9

DynAMOS (1) DynAMOS (1)

Quiescence Quiescence

  • If no parts of the resource are in use, either by sleeping

processes or partially-completed transactions

  • No function can be idle on the stack.
  • Updating modules in quiescence state is easier
  • Some processes never reach quiescence state (e.g.

Process scheduler)

slide-10
SLIDE 10

10

DynAMOS (2) DynAMOS (2)

Quiescence Detection Quiescence Detection

  • Function Usage Counters (but

not sufficient e.g. do_exit)

  • Stack-walkthrough Method (Has

side effects)

slide-11
SLIDE 11

11

DynAMOS (3) DynAMOS (3)

Binary Rewriting Binary Rewriting

  • Adds jump instruction at the top
  • f the function
  • Make sure that no thread

context or interrupt context is executing in the first 5 or 6 bytes

  • f the function

Function_V1 Function_V2

First 5 or 6 Bytes

  • Virt. Addr

Jump Jump

slide-12
SLIDE 12

12

DynAMOS (4) DynAMOS (4)

State Tansfer is needed: State Tansfer is needed:

  • Existing data structures changed
  • Semantic of the function changed
  • Updated unit not in quiescence state
slide-13
SLIDE 13

13

  • 1. Classification of Kernel Updates
  • Updating Code Only
  • Updating Code and Existing Data
  • 2. DynAMOS - The Basic Approach
  • Quiescence Detection
  • Binary Rewriting
  • Redirection Table
  • 3. LUCOS - Using Virtualization for Live Updates
  • 3. LUCOS - Using Virtualization for Live Updates
  • State Transfer

State Transfer

  • 4. Ksplice - Hot Updates at Object Code Level
  • Pre-post Differencing and Run-pre Matching
  • 5. Conclusion and Discussion
slide-14
SLIDE 14

14

LUCOS (1) LUCOS (1)

  • Virtual Machine

Monitor(VMM) controls system resources

  • VMM intercepts and

emulates memory and I/O accesses

VMExit VMExit

slide-15
SLIDE 15

15

LUCOS (2) LUCOS (2)

  • Quiescence state is not a prerequisite

Quiescence state is not a prerequisite

  • Manual patch creation
  • Patch files: Code + data structures as loadable kernel

modules

slide-16
SLIDE 16

16

LUCOS (3) LUCOS (3)

  • Update Manager loads

kernel modules for the patched function(s) and data structure(s)

Code Data Function1 V1 Data1 V1 Data1 V2

VMM

Update Server Function1 V2 VM

slide-17
SLIDE 17

17

LUCOS (4) LUCOS (4)

  • Update Manager iterates all

kernel threads and makes sure that none of them is executing in the first 5 bytes of the function

  • Update Manager inspects

kernel call stacks for counting threads executing in the patch code

  • Control is passed to Update

Server via hypercall

  • Update Server applies

binary rewriting for inserting jump and for replacing return address of the function

Code Data Function1 V1 Data1 V1 Data1 V2

VMM

Update Server Function1 V2 VM Apply Apply the patch the patch (Hypercall) (Hypercall)

slide-18
SLIDE 18

18

LUCOS (5) LUCOS (5)

  • Memory virtualization

techniques provided by x86 architecture – Shadow paging & NPT/EPT

  • Update Server resumes the

VM

  • Old function accesses to
  • ld data

Code Data Function1 V1 Data1 V1 Data1 V2

VMM

Update Server (1) Write (1) Write Access Access Function1 V2 VM

slide-19
SLIDE 19

19

LUCOS (6) LUCOS (6)

  • Memory access intercepted
  • Update Server checks if

VM is accessing to either versions of the data

Code Data Function1 V1 Data1 V1 Data1 V2

VMM

Update Server (1) Write (1) Write Access Access (2) (2) VMExit VMExit Function1 V2 VM

slide-20
SLIDE 20

20

LUCOS (7) LUCOS (7)

  • Update Server invokes

state transfer function to maintain data consistency

Code Data Function1 V1 Data1 V1 Data1 V2

VMM

Update Server (3) State (3) State Transfer Transfer (1) Write (1) Write Access Access (2) (2) VMExit VMExit Function1 V2 VM

slide-21
SLIDE 21

21

LUCOS (8) LUCOS (8)

  • Usage information of the
  • ld function and data is

updated via callbacks

  • Callbacks are invoked in

the context of VMM

  • Update Server terminates

the patch when the old function and data is not in use

Code Data Function1 V1 Data1 V1 Data1 V2

VMM

Update Server Terminate Terminate the patch the patch (Hypercall) (Hypercall) Function1 V2 VM Function Function returns. returns. Invoke Invoke callback callback (Hypercall) (Hypercall)

slide-22
SLIDE 22

22

  • 1. Classification of Kernel Updates
  • Updating Code Only
  • Updating Code and Existing Data
  • 2. DynAMOS - The Basic Approach
  • Quiescence Detection
  • Binary Rewriting
  • Redirection Table
  • 3. LUCOS - Using Virtualization for Live Updates
  • State Transfer
  • 4. Ksplice - Hot Updates at Object Code Level
  • 4. Ksplice - Hot Updates at Object Code Level
  • Pre-post Differencing and Run-pre Matching

Pre-post Differencing and Run-pre Matching

  • 5. Conclusion and Discussion
slide-23
SLIDE 23

23

Ksplice (1) Ksplice (1)

  • Ksplice Inc. :Created by four MIT students based on a

master's thesis

  • Provides prebuilt and tested updates for the Red Hat,

CentOS, Debian, Ubuntu and Fedora Linux distributions

  • Acquired by Oracle on 21 July 2011
  • Used by over 700 customers running more than 100,000

production systems at that time

slide-24
SLIDE 24

24

Ksplice (2) Ksplice (2)

  • Creating patches manually: quite complex and error prone
  • Automatic patch creation
  • Analysis at the Executable and Linkable Format (ELF)
  • bject code layer

➢

Doesn't matter if it's C or Assembly code

➢

Inlined functions detected

  • Most of the Linux security patches do not make semantical

changes to data structures

slide-25
SLIDE 25

25

Ksplice (3) Ksplice (3)

  • Input:

➢

Original source (pre source) of the running kernel (buggy).

➢

The code in the running kernel (run code) (buggy).

➢

Source of the patched kernel (post source).

  • Preparation

➢

Compile the pre source and post source using -ffunction- sections and -fdata-sections compiler options (gcc)

➢

Pre and post object files created

slide-26
SLIDE 26

26

Ksplice (4) Ksplice (4)

Pre-post Differencing and Run-pre Matching Pre-post Differencing and Run-pre Matching Steps: Steps:

  • Compare the pre and post object files
  • Detect and replace kernel functions that have been

changed

  • Calculate symbols
  • Detect quiescence state
  • Patch
slide-27
SLIDE 27

27

Ksplice (5) pre-post differencing Ksplice (5) pre-post differencing

Post object files Pre object files Diff Diff Post code functions that differed Pre code

  • ptimization

unit that differed Extract Extract diff diff Extract Extract diff diff Primary module Link with generic Link with generic Kernel module Kernel module

  • Primary module has

unresolved symbols

slide-28
SLIDE 28

28

Ksplice (6) run-pre matching Ksplice (6) run-pre matching

  • Reversing what the

Linker did

  • Symbol tables of Linux

Kernel is not used

  • Allows accessing to

every symbol in the kernel

  • Actually, Linux Kernels

without any symbol tables can be patched.

slide-29
SLIDE 29

29

Ksplice (7) Ksplice (7)

Quiescence Detection: Quiescence Detection:

  • Calls stop_machine for detecting quiescence state:

Makes patching atomic. Causes 0.7 milliseconds delay

  • Stack-walkthrough used for quiescence detection
  • If check failed: wait couple of seconds, check again
  • Using Ksplice for customer support: Diagnostic tool

sends the report to oracle. Oracle prepares a bugfix as a ksplice patch.

slide-30
SLIDE 30

30

  • 1. Classification of Kernel Updates
  • Updating Code Only
  • Updating Code and Existing Data
  • 2. DynAMOS - The Basic Approach
  • Quiescence Detection
  • Binary Rewriting
  • Redirection Table
  • 3. LUCOS - Using Virtualization for Live Updates
  • State Transfer
  • 4. Ksplice - Hot Updates at Object Code Level
  • Pre-post Differencing and Run-pre Matching
  • 5. Conclusion and Discussion
  • 5. Conclusion and Discussion
slide-31
SLIDE 31

31

Conclusion Conclusion

  • Binary rewriting and stack-walkthrough is used in such

frameworks.

  • Keeping the old code consistent with the new code is

complex and expensive (state transfers, callbacks).

  • LUCOS exploits virtualization technologies, whereas

Ksplice operates on object code level.

  • Ksplice: not limited to C or Assembly code. But compiler

and linker dependent.

  • Ksplice: Minimum programmer involvement. %88 of the

security patches from May 2005 to May 2008 can be applied automatically.

slide-32
SLIDE 32

32

Discussion Discussion

  • How reliable are usage counters in LUCOS
  • Applying LUCOS in multi-core platforms
  • Applying Ksplice and LUCOS on real time operating

systems

  • Patch rollback