7 ms·

LD_PRELOAD rootkits are by definition not "ultra-stealthy". Nothing here looks special, there are a plenty of these: https://github.com/chokepoint/Jynx2 https

• mid-kid 4y ago
  How do you detect one?
  • psacawa 4y ago
    I don't know what the correct thing to do, but you can easily detect processes that have the LD_PRELOAD environment variable defined. This is a rare enough use case for manual inspection. Something like ``` for f in /proc/*/environ ; do sudo strings $f | >/dev/null grep LD_PRELOAD && echo $f; done ```
    • mid-kid 4y ago
      Can't an LD_PRELOAD virus just hijack fopen/fread/etc to modify the contents of the file if its path matches the pattern you described?
      • miohtama 4y ago
        Yes it can. However I would assume the surface to block all diagnostics paths would be quite large and there is always some command/syscall left unblocked to detect any rootkit. Creating 100% stealth malware is possible, but difficult.
    • shaded-enmity 4y ago
      1. Can't the process just scrub LD_PRELOAD from its environment? Linker already done it's job at that point. 2. I'd suggest against using `strings` (let alone with sudo) on attacker controlled inputs
      • alex_duf 4y ago
        I'm curious about 2, why?
        • shaded-enmity 4y ago
          This is a nice summary: https://lcamtuf.blogspot.com/2014/10/psa-dont-run-strings-on-untrusted-files.html https://lcamtuf.blogspot.com/2014/10/psa-dont-run-strings-on...
        • GabrielTFS 4y ago
          Some versions of `strings` might try to parse the file as an executable, which could expose one to any vulnerabilities that may be present in the library used to do so. However, on my Fedora 36 machine at least, it doesn't do so by default and I'd have to specify the `-d` flag for it to do this.
      • shaded-enmity 4y ago
        Turns out (1) works: #include <stdio.h> #include <stdlib.h> static void begin() __attribute__((constructor)); void begin() { unsetenv("LD_PRELOAD"); } Build with: gcc -shared -fpie -o library.so library.c Test: LD_PRELOAD=~/library.so env | grep LD_PRELOAD
        • rurban 4y ago
          Usually guarded with an #ifndef DEBUG. Disallow LD_PRELOAD in Release builds
      • BenjiWiebe 4y ago
        You could look at the maps of a process instead of the environ. That would show it. Unless the ld_preload patches the process you are using to read the maps file, and gives you a false maps file.
    • chrismorgan 4y ago
      Just tried it, I have it happening naturally in two places: • libinput-gestures has spawned a /usr/lib/libinput/libinput-debug-events process with LD_PRELOAD=/usr/lib/coreutils/libstdbuf.so • Firefox has spawned many /opt/firefox-nightly/firefox-bin processes with LD_PRELOAD=libmozsandbox.so
    • Cthulhu_ 4y ago
      Wouldn't this malware be able to infect each of these steps and the shell itself to filter itself out of the results?
      • prvit 4y ago
        LD_PRELOAD rootkits are super common, you’re doing it wrong if you’re using dynamically linked binaries to look for malware on Linux.
    • LinuxBender 4y ago
      I see those defined when I use firejail + firefox. LD_PRELOAD=libmozsandbox.so
  • josephcsible 4y ago
    One of the easiest ways would be using a statically linked BusyBox. This works because statically linked binaries are unaffected by LD_PRELOAD, and BusyBox has equivalents of several of the tools that would find it if not for its hiding attempts.
• VoidWhisperer 4y ago
  Side tangent: Why does github let these repos for Malware stay up? I understand some of them use the excuse 'this is for education, i'm not responsible for what you do with it', but some don't even bother with that, and atleast my concern would be that some person could easily pull the code, modify it slightly, and off they go if the IOC/detections for the attack method aren't good yet
  • Cthulhu_ 4y ago
    Personal take: It's better to have malware code stay online and open, than to disappear into obscurity. This being open source also means that anti-malware companies can analyze the code and write detectors and counters to it. Removing it would just mean it gets hidden from the 'good guys' as well.
    • GekkePrutser 4y ago
      Not just anti malware companies. I work for an enterprise and I regularly use such malware proof of concepts to make sure our antimalware and EDR (endpoint detection and response) systems actually do detect these. Or if we have to sharpen the detection rules to make them work better. These disclosures are invaluable. Most companies modify their detection rules because generic rules tend to cause false positives that could potentially overwhelm the SOC (security operations center). It really depends on your environment a lot.
    • bediger4000 4y ago
      The 1990s "antivirus" industry was able to suppress most malware source and executable distribution. You could only find it in small print run zines, or the very occasional book. All that led to was people typing the source in themselves. The result was a proliferation of minor variants. My guess is the suppression held back the tide of Windows malware a year or two, but also gave MSFT a few years of fat, dumb and happy ignorance. Nimda, Code Red, Word macro viruses, etc hit Windows hard. If jokey small threats had been as available as they are today, MSFT might have been able to ramp up rather than get buried.
  • jhugo 4y ago
• 323 4y ago
  LD_PRELOAD equivalent was used in Windows malware circa 2006. It seems all the old Windows techniques are now recycled on Linux.
  • prvit 4y ago
    Oh no, first LD_PRELOAD kits for Linux date back to the 90s.
  • sophacles 4y ago
    LD_PRELOAD (ish) attacks are older than the web.
• farisjarrah 4y ago
  This seems to be different from previous LD_PRELOAD vulnerabilities in that it's using eBPF as part of the mechanism to obfuscate itself.
  • prvit 4y ago
    Sure, but that’s at best a minor implementation detail. Doesn’t meaningfully increase the difficulty of detection.
• u1tron 4y ago
  Have you seen the malware called "bpfdoor"?