ENPM809V

Kernel System Hijacking

What We Will Cover

• Shared IRQs
• Notifiers
• Tracers

Announcements

Announcements

• Next week we may have pre-recorded lecture again due to work conflict.
  • Will confirm by Wednesday
  • The rest of the lectures will be in-person

Overview

Events

• Events give us information about what is happening in the kernel
• Subsystem communicates through this mechanism (and shared memory)
• Two primary methods:
  • Shared IRQs
  • Notification events

Tracers

• Designed to figure out what is happening in the kernel
• Useful for: debugging, Vulnerability Research, Hooking functions, finding out how things work
• Multiple technologies including: ftrace, kprobes, ebpf

What they have in common?

• Can execute certain behavior based on something that happens

Shared IRQs

Shared IRQs

• Remember request_irq?
  • It has multiple flags including IRQF_SHARED.
• This allows a particular interrupt to be handled by multiple handlers/devices.
• What do you think we can do with this?

Shared IRQs

• Iterates through all the handlers with that IRQ
  • The handler passes it's own dev_id (based on what it was registered with at request_irq)
• If the handler is going to service the interrupt, it should return IRQ_HANDLED.
  • Otherwise it should return IRQ_NONE

Shared IRQs

• Iterates through all the handlers with that IRQ
  • The handler passes it's own dev_id (based on what it was registered with at request_irq)
• If the handler is going to service the interrupt, it should return IRQ_HANDLED.
  • Otherwise it should return IRQ_NONE

Why is this important

• IRQ Snooping!
• If you find a handler that is registered as a shared handler for a given IRQ you can register your own handler for the same IRQ
  • Caveat: Return IRQ_NONE to not intefere with the other shared handler

Notifiers

Notifier Chains

• An publish-subscribe model for event notifications
  • A callback with another device, module, etc. that is invoked based on an event triggered
• Multiple implementations of notifier chains (each behaving differently based callback execution context)

Notifier Chains Type

• Atomic
• Blocking
• SRCU - Sleepable Read-Copy-Update - Think blocking with different tradoffs
• Raw - Managing your own locking/blocking
• The API is defined include/linux/notifier.h

Notification Callbacks

Notification Callbacks

• Important things to note:
  • When events are generated - subsystem calls for notifier_call_chain
  • Call to event registration are requests to add the notifier_call function to a list of notifier_calls

Tracing

Tracing Mechansims

• Linux Kernel provides us with a few ways to trace
  • Kprobes/Uprobes
  • Tracepoints
  • Ftrace
  • eBPF - Extended Berkley Packet Filter
• Each has it's own benefits and drawbacks

Why Does This Exist?

• Debugging and analyze the Linux kernel
• Performance analysis
• Finding bugs
• Targeted logs and messaging

How are we going to use it?

• Bug hunting
• Figuring out how things work
• Hook/inject our code/shellcode into the kernel
• Learning tool for our own hooking mechanism

Kprobes

• An API that allows developers to trace via hooking into the kernel
• Uses hardware breakpoints to dynamically insert code
  • Inserts breakpoints on a specified instruction address
  • When the system hits the breakpoint, th eexception handler calls the function defined by the user of Kprobe

Basics of Kprobes

• Creating a kprobe - register a struct kprobe with the kprobe system
  • This is generally set by the register_kprobe function
• The User Must specify
  • symbol_name - the function to hook
  • pre_handler - any code that should be run before executing the function
  • post_handler - any code to be run after the function is finished executing
  • handler_fault - code to run when a fault occurs

Basics of Kprobes

• Creating a kprobe - register a struct kprobe with the kprobe system
  • This is generally set by the register_kprobe function
• The User Must specify
  • symbol_name - the function to hook
  • pre_handler - any code that should be run before executing the function
  • post_handler - any code to be run after the function is finished executing
  • handler_fault - code to run when a fault occurs

Basics of Kprobes

• Other useful functions
  • unregister_kprobe
  • kretprobe
  • See /include/linux/kprobes.h

Tracepoints

• Programmer declared points in code that callout to registered probes (tracers)
  • Defined usually by macros TRACE_EVENT
• Needs to be defined at compile time.
  • If not present, then can't trace the event.
• Traces are more reliable than kprobes because their address is consistent

Ftrace

• Another tracing framework specific to the Linux Kernel
• Uses GCC Profiler (-pg flag) to make calls to mcount within each function call
  • mcount is a trampoline function
• These calls generally cause a lot of overhead
• Space is also allocated at boot for all tracepoints

Ftrace

• Another tracing framework specific to the Linux Kernel
• Uses GCC Profiler (-pg flag) to make calls to mcount within each function call
  • mcount is a trampoline function
• These calls generally cause a lot of overhead
• Space is also allocated at boot for all tracepoints

Extended Berkley Packet Filters - eBPF

• eBPF is an extension of the original BPF (found in most Unix systems)
• Allows developers to run sandboxed programs in a privilged context (a VM within the kernel)
  • Extends functionality to things like kprobes, uprobers, seccomp, XDP, and much much more

EBPF

• Usable on most Linux architectures X86_64, ARM64, etc.
• Allows full tracability within the Linux kernel without installing a full kernel module
  • Especially the fact that you can attach kprobes to eBPF programs

EBPF Bytecode

• Remember: eBPF is a VM inside of the Linux Kernel
  • Has it's own bytecode language (think like Java byte code, but in the kernel)
• Registers are near 1:1 matching to machine instructions for performance
  • Before running, it is sent to the eBPF Verifier to ensure the code is safe
    • Lots of rules that the verifier checks (instruction limit, tailcall limit, control flow restrictions, etc.)

EBPF Bytecode

• Remember: eBPF is a VM inside of the Linux Kernel
  
  • Has it's own bytecode language (think like Java byte code, but in the kernel)
    
• Registers are near 1:1 matching to machine instructions for performance
  
  • Before running, it is sent to the eBPF Verifier to ensure the code is safe
    
    • Lots of rules that the verifier checks (instruction limit, tailcall limit, control flow restrictions, etc.)
      

EBPF Bytecode

• eBPF has 11 64-bit registers and a handful of instructions
  • R0 is return value
  • R1 – R5 are arguments
  • R6 - R9 general purpose callee saved
  • R10 is the frame pointer, and is read-only
• R1 contains the “context” for the program, which is similar to an argv

EBPF Bytecode

• eBPF instructions are fixed-width: 64-bits
  • Opcode: 8 bits
  • Destination: 4 bits
  • Source: 4 bits
  • Offset: 16 bits
  • Immediate: 32 bits
  • Unused fields are zeroed
• There is only 16-byte instruction that performs a 64-bit immediate load

eBPF Is just like this:

https://www.youtube.com/shorts/P8-gYWaMUqs

eBPF Classwork

Setup

• You need to do this in an Ubuntu 20.04 VM
• git clone https://github.com/libbpf/libbpf-bootstrap
  • If you don't have git, do sudo apt install git
• Follow the directions for installing libbpf (inside the libbpf folder) or do sudo apt install libbpf-dev libbpf0

eBPF, KPROBE/UPROBE Exercise

1. Download and install bpftrace

2. Have bpftrace hook on write.

3. Have it print "Hello Write" when a write is triggered

4. Test it out!

5. Repeat this, but create a C program instead of bpftrace

Directions

• Inside of the libbpf-bootstrap/examples/c folder, there are examples of eBPF programs.
  • If you run the command make it will generate them for you
• Demonstrates what you can do (such as kprobes, uprobes, XDP, etc.).

Directions

• git clone https://github.com/ENPM809V/libbpf-keylogger
• Copy the keylogger.c and keylogger.bpf.c file into libbpf-bootstrap/examples/c
  • Open the Makefile, and append KEYLOGGER to APPS =

Directions

• Fill out the eBPF keylogger template to capture a keypress and key-depressing using a kprobe on input_handle_event
• You need to fill out the BPF_KPROBE with the definitions of input_handle_events parameters.
• Capture key presses then key-depresses!