> "Well if someone ... then its game over". They are not entirely wrong

They're not at all wrong, and your argument has no merit. As a defender, I'd pray that attackers use toolkits like the ones you linked that are essentialy utter trash and trivially detected (as is anything ebpf-based).

Yep, dunno why you've been downvoted. Kernel rootkits are just normal dkms kernel modules. Why would the attacker use these new eBPF rootkits when the old open source ones are far more sophisticated and need similar privileges?

While I do agree generally that we're still experimenting with the guardrails around eBPF, it seems like the more fundamental problem of the "ease of privilege escalation" is what we should be focused on?

But I can see how eBPF itself might be considered too powerful to wait for that to be solved.

I'm honestly more worried about Linux desktop/small startups that can't afford expensive commercial guidance and are likely to not understand/care about the implications of eBPF until its too late.

As far as I know, eBPF today is only usable as root - or, if they expanded the permissions for eBPF, can be limited to only be used by root. The same root user can install a kernel module to do everything that eBPF lets you do. Getting to root on a machine is the endgame, at least as far as that machine is concerned.

An eBPF enabled kernel makes a great jump off point for any exploit chain.

In 2020, CAP_BPF was added to allow the use of eBPF.

For most programs, you'll use a combination of CAP_BPF, CAP_PERFMON and/or CAP_NET_ADMIN. For some edge cases (such as hardware offload), you'll need the entire CAP_SYS_ADMIN (basically root).

I wrote more about this here: https://mdaverde.com/posts/cap-bpf/

Interesting. That's basically read-only root permission, which should probably be handed out sparingly, but it makes sense for isolation purposes to separate out your BPF programs from root.

'bpftool' provides a list of loaded bpf programs, but playing around with it just now, it is not obvious to me how to get the actual loaded bpf program details (e.g, pre-JIT version of the loaded program [or even the JIT version]). The man page is pretty terse.

'bpftool prog' / 'bpftool prog list' / 'bpftool prog show' all provided the same output (sample below), and e.g., adding the index in the list, to any of the above commands is an error.

e.g.,

  # bpftool prog
  8: cgroup_device  name sd_devices  tag 1f97e470ec084ee5  gpl
        loaded_at 2022-11-02T08:58:10-0700  uid 0
        xlated 464B  jited 292B  memlock 4096B
  173: cgroup_device  name sd_devices  tag c7286db13d0052fa  gpl
        loaded_at 2022-11-05T23:53:24-0700  uid 0
        xlated 464B  jited 292B  memlock 4096B
  174: cgroup_skb  name sd_fw_egress  tag 6deef7357e7b4530  gpl
        loaded_at 2022-11-05T23:53:24-0700  uid 0
        xlated 64B  jited 58B  memlock 4096B
  .
  .
  .

Does anyone know if it is possible, and how to get the details on the loaded bpf programs?

You can see the interpreter instructions through bpftool:

  bpftool prog dump xlated id 173

To see the JITed instructions:

  bpftool prog dump jited id 173

For the interpreted insns, you can also see the instructions in different forms, which is pretty neat. For example you can get a control flow graph in DOT format with `visual` specified at the end:

  bpftool prog dump xlated id 173 visual

I learned about these commands through this blog post: https://qmonnet.github.io/whirl-offload/2021/09/23/bpftool-f...

Thanks. Visibility seems to be pretty good. Something like AIDE/Tripwire for BPF might be the next step.

This is effectively what Falco(https://falco.org/) is

the bpftool-prog(8) man page documents the bpftool-prog subcommands

FWIW, programs compiled through a modern toolchain can ship their own debug data. For example, the restrict_filesystems program loaded by systemd

    $ sudo bpftool prog dump xlated id 50
    int restrict_filesystems(unsigned long long \* ctx):
    ; int BPF_PROG(restrict_filesystems, struct file *file, int ret)
       0: (79) r3 = *(u64 *)(r1 +0)  
       1: (79) r0 = *(u64 *)(r1 +8)
       2: (b7) r1 = 0 
    ; uint32_t *value, *magic_map, zero = 0, *is_allow;
       3: (63) *(u32 *)(r10 -20) = r1
    ; int BPF_PROG(restrict_filesystems, struct file \*file, int ret)
       4: (bf) r1 = r0                                                             
       5: (67) r1 <<= 32             
       6: (77) r1 >>= 32
    ; if (ret != 0)           
       7: (55) if r1 != 0x0 goto pc+59                                             
       8: (b7) r1 = 32               
       9: (0f) r3 += r1
      10: (bf) r6 = r10        

https://github.com/systemd/systemd/blob/c76691d708ac7fe13b7c...

Unfortunately, most of the programs loaded by systemd are more-or-less hand-generated (the ingress/egress programs specifically) and do not include this information.

It's a surprisingly small group of folks who work in this space upstream, but I know that they're aware of this as an opportunity to improve things :)

> eBPF has the potential for file-less malware to run hidden from detection

so do ROP chains. There's a lot of fluff in the industry about "file-less" this and "LOL-bin" that, but really this isn't anything new, the fact that people are still writing post exploitation stages that write persistent files to disk is out of sheer laziness/attackers not being forced to do anything different. Forcing attackers to write ROP compilers isn't really a worthwhile goal anyways because you only ever have to do that once as an adversary (and it would take, what, a single person a few weeks?) whereas getting to the point where file detection is so good would take a massive industry wide effort and billions of dollars.

eBPF-for-evil is not a worthwhile concern because it's not meaningfully different or more powerful than the same old techniques we've all known about since the 90s.