How to write a rootkit without really trying | Hacker News Reader

How to write a rootkit without really trying

blog.trailofbits.com

118 pointsingve10 comments

Author here. Happy to answer any questions.

Are you aware that this can be done without elevated privileges using seccomp(2)[0] and ptrace(2)[1] using SECCOMP_RET_TRACE? (or with ptrace alone using PTRACE_SYSEMU) Although the ptrace API can be daunting and I believe it's somewhat involved to do anything besides changing values returned by the call, however the upside (or downside) is you don't need to learn any kernel programming. I wish these APIs were more accessible as I feel there's a lot of potential to use them in creative ways.

EDIT: Just noticed your mention at the bottom of the post, feel free to disregard this

[0]http://man7.org/linux/man-pages/man2/ptrace.2.html

[1]http://man7.org/linux/man-pages/man2/seccomp.2.html

Yup! I looked into implementing KRF[1] with ptrace originally, but ultimately went the kernel module route for a few different reasons:

1. I was more familiar with the relevant kernel APIs/techniques

2. ptrace adds a 2x (3x?) overhead to each syscall and works on inferior processes only

3. I want KRF to eventually fault ptrace(2) itself!

[1]: https://github.com/trailofbits/krf

https://media.ccc.de/v/35c3-9532-kernel_tracing_with_ebpf seems to have PoC that you can do interception. Did I misunderstand that?

I skimmed through their talk, but my understand of eBPF is that it cannot do syscall interception (i.e., actually changing the code that a syscall executes) itself. Their PoC, from what I can tell, is a separate kernel module that disables some of eBPF's safety checks so that they can do more expressive things within it.

They do, however, show that eBPF can be used to detect changes to particular files and alert the user/provide feedback when that happens. That's extremely useful, although not the same as actually denying that change (which would require modifying the syscall itself).

Edit: I just watched up to the point when they discuss `bpf_probe_write_user`, which I didn't know about. Looks like you can indeed use that to do much of what I'm interested in!

I haven't watched that talk, but in the past I've done this by LD_PRELOADing a shared object that injected a seccomp filter on init with SECCOMP_RET_TRAP as appropriate and then rewrote the saved thread state higher up the stack to simulate the syscall / replace the return value. It worked pretty well.

Ya, I was curious about that too. Finally started messing with bcc, found: https://stackoverflow.com/questions/43003805/can-ebpf-modify... and a tangentally related https://dev.framing.life/tracing/uprobes-and-int3-insn/

I still wish you'd called it "Camus"

Definitely going with that for the 1.0.

>eBPF can’t intercept syscalls

Perhaps soon it will be able to, though! See the "seccomp trap to userspace" patches.

Reply on news.ycombinator.com