4 ms·

But the issues you're describing are literally where the eBPF kernel module chimes in and what the process analysis is about, no? You can detect a lot of malic

But the issues you're describing are literally where the eBPF kernel module chimes in and what the process analysis is about, no? You can detect a lot of malicious behaviour this way, where programs and processes deviate from their usual behaviour; e.g. trying to access files they're not supposed to.

saagarjha 2y ago
Someone with a kernel-level exploit can completely neuter your eBPF detection. They can make it never return data, or return bogus/benign data. You can try to catch them in that lie, but it's really hard, and even if you do they can just stop your process from being able to report on it. Again, a real-life analogy might help: it is really, really hard to protect yourself against a criminal who has the cops on their side. You're definitely not going to be allowed to go into the crime scene yourself, so you have to trust what they're telling you. All your complaints are going through them. If a dirty cop doesn't like you your life can get a whole lot worse!
- cookiengineer 2y ago
  The point of eBPF is that eBPF receives and processes data _before_ the kernel does.
  - stefan_ 2y ago
    Thats just not true? Your eBPF programs run in a VM in the kernel, occasionally JITed, but of course the kernel is free to feed them whatever data it wants.
    - cookiengineer 2y ago
      Where does your hypothesis come from? Any architecture chart will point out that XDP will be processed before all other network modules. If XDP is not offloaded, the driver will always process the XDP hooks before the rest of the network stack is called. In your assumed concept, how else would offloading to a NIC that does not run a kernel work?
      - h4ck_th3_pl4n3t 2y ago
        I think there is a misunderstanding of the two perspectives. Grandparent's assumption is that the kernel is compromised. Your assumption is that you can detect malicious behaviour before it happens (and before the kernel is compromised).
      - tptacek 2y ago
        XDP receives packets before the network stack does, but not before the kernel; in almost all cases, it's just a hook to process packets off the DMA buffer. None of this matters; the kernel controls XDP; not only that, but there's nothing an XDP program can do without rendezvousing back through the kernel.
        cookiengineer 2y ago
        > XDP receives packets before the network stack does, but not before the kernel; in almost all cases, it's just a hook to process packets off the DMA buffer. If the kernel really processes and parses the data packet _before_ eBPF and XDP can then you could exploit the kernel via single data packets. That's the context of the discussion, still. Meaning that in the hypothetical scenario that you found a programming error in the kernel code regarding the parsing of network packets. Note: Parsing is not the same as copying, and I used the word parsing specifically on purpose here. If the kernel does not process or parse the network packet other than sending the pointer to the previously copied buffer to an eBPF program - then that means a malicious packet can be blocked before anything else in the network stack is affected, right? So, what do you think happens when I decide to write an eBPF/XDP program that blocks e.g. all TCP packets? A) The network stack receives the packet B) The network stack does not receive the packet If your answer is A, we have a different definition of what you describe as the term "network stack". To me, the network stack is everything that comes _after_ XDP passthrough. And that's outside the influence of my userspace/kernelspace program that tries to protect the system. Also XDP is the earliest position in the kernel architecture to detect/validate/block malicious network packets. Because let's be real: I am never gonna be able to get anything merged in the kernel driver code of my network cards.
  - saagarjha 2y ago
    That's not really the case. The kernel-much like a police force-is not a monolithic entity, there are various parts of the kernel that get information before others. eBPF does let you "hook" various parts of the kernel, so that you can get an "exec" event from before the exec actually happens (you can't stop it, though, so even this is somewhat dubious). But someone in the kernel can intercept the hook itself, or uninstall it completely. In the police analogy even if you have a friend in the force that you know is good, they are still part of the police. Even if the first thing they do when they get information is share it with you, there's no guarantee the dirty cop isn't sitting in the mail room ready to shred things before they get it.
    - deleted 2y ago
      [deleted]

saagarjha 2y ago

Someone with a kernel-level exploit can completely neuter your eBPF detection. They can make it never return data, or return bogus/benign data. You can try to catch them in that lie, but it's really hard, and even if you do they can just stop your process from being able to report on it. Again, a real-life analogy might help: it is really, really hard to protect yourself against a criminal who has the cops on their side. You're definitely not going to be allowed to go into the crime scene yourself, so you have to trust what they're telling you. All your complaints are going through them. If a dirty cop doesn't like you your life can get a whole lot worse!

cookiengineer 2y ago
The point of eBPF is that eBPF receives and processes data _before_ the kernel does.
- stefan_ 2y ago
  Thats just not true? Your eBPF programs run in a VM in the kernel, occasionally JITed, but of course the kernel is free to feed them whatever data it wants.
  - cookiengineer 2y ago
    Where does your hypothesis come from? Any architecture chart will point out that XDP will be processed before all other network modules. If XDP is not offloaded, the driver will always process the XDP hooks before the rest of the network stack is called. In your assumed concept, how else would offloading to a NIC that does not run a kernel work?
    - h4ck_th3_pl4n3t 2y ago
      I think there is a misunderstanding of the two perspectives. Grandparent's assumption is that the kernel is compromised. Your assumption is that you can detect malicious behaviour before it happens (and before the kernel is compromised).
    - tptacek 2y ago
      XDP receives packets before the network stack does, but not before the kernel; in almost all cases, it's just a hook to process packets off the DMA buffer. None of this matters; the kernel controls XDP; not only that, but there's nothing an XDP program can do without rendezvousing back through the kernel.
      - cookiengineer 2y ago
        > XDP receives packets before the network stack does, but not before the kernel; in almost all cases, it's just a hook to process packets off the DMA buffer. If the kernel really processes and parses the data packet _before_ eBPF and XDP can then you could exploit the kernel via single data packets. That's the context of the discussion, still. Meaning that in the hypothetical scenario that you found a programming error in the kernel code regarding the parsing of network packets. Note: Parsing is not the same as copying, and I used the word parsing specifically on purpose here. If the kernel does not process or parse the network packet other than sending the pointer to the previously copied buffer to an eBPF program - then that means a malicious packet can be blocked before anything else in the network stack is affected, right? So, what do you think happens when I decide to write an eBPF/XDP program that blocks e.g. all TCP packets? A) The network stack receives the packet B) The network stack does not receive the packet If your answer is A, we have a different definition of what you describe as the term "network stack". To me, the network stack is everything that comes _after_ XDP passthrough. And that's outside the influence of my userspace/kernelspace program that tries to protect the system. Also XDP is the earliest position in the kernel architecture to detect/validate/block malicious network packets. Because let's be real: I am never gonna be able to get anything merged in the kernel driver code of my network cards.
- saagarjha 2y ago
  That's not really the case. The kernel-much like a police force-is not a monolithic entity, there are various parts of the kernel that get information before others. eBPF does let you "hook" various parts of the kernel, so that you can get an "exec" event from before the exec actually happens (you can't stop it, though, so even this is somewhat dubious). But someone in the kernel can intercept the hook itself, or uninstall it completely. In the police analogy even if you have a friend in the force that you know is good, they are still part of the police. Even if the first thing they do when they get information is share it with you, there's no guarantee the dirty cop isn't sitting in the mail room ready to shred things before they get it.
  - deleted 2y ago
    [deleted]