2 ms·

I don't have the time, sorry. Too much on my plate! But I (and I apologize in advance for this) can tell you that one of the reasons why I would not have that m

I don't have the time, sorry. Too much on my plate! But I (and I apologize in advance for this) can tell you that one of the reasons why I would not have that much time for this is that I don't think it is fundamentally interesting in the face of a sophisticated adversary. Scanning files and memory or whatever is largely irrelevant in the age of exploits that completely compromise the device, all the way to a privilege level higher than where the actual scanner operates. Signatures fall apart if it is very cheap to evade them (and it is, with trivial modifications to payloads). Typical approaches to catching malware do not apply to zero-day attacks. They may sometimes work but my point in the comment above was to point out that this is just luck rather than a sustainable practice. Someone who knows you are looking for them can hide and lie far harder than you can possibly imagine. And if they've broken the system, they can use those very protections that were supposed to keep them out to prevent you from going after them. Kind of like how a castle is designed to prevent people from storming it, up until they actually sneak in and all those defensive measures stop you from retaking it ;)

cookiengineer 2y ago
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.

cookiengineer 2y ago

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.