This seems to be different from previous LD_PRELOAD vulnerabilities in that it's using eBPF as part of the mechanism to obfuscate itself.

Sure, but that’s at best a minor implementation detail. Doesn’t meaningfully increase the difficulty of detection.

How do you detect one?

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 ```

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

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

Usually guarded with an #ifndef DEBUG. Disallow LD_PRELOAD in Release builds

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.

I'm curious about 2, why?

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.

This is a nice summary: https://lcamtuf.blogspot.com/2014/10/psa-dont-run-strings-on...

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

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?

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.

Wouldn't this malware be able to infect each of these steps and the shell itself to filter itself out of the results?

LD_PRELOAD rootkits are super common, you’re doing it wrong if you’re using dynamically linked binaries to look for malware on Linux.

I see those defined when I use firejail + firefox.

    LD_PRELOAD=libmozsandbox.so

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.

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

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.

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.

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.

> Why does github let these repos for Malware stay up?

Sad state of affairs when people routinely ask for more censorship on what was supposed to be the freest technology to ever exist.

Since Linux is open source, how about not only “allowing” things like this to stay up, but encouraging everyone know about them?

They could also write it from scratch themselves; having the source code available doesn't make it that much easier. Defence doesn't come from trying to scrub all records of the attackers' methods.

Taking the repos down would only inconvenience legitimate researchers. All the sketchy users discuss on forums and either post the code inline or upload to a random VPS.

Do you think it would make it harder to find for people specialize in making malware like this?

> 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

I did this and it passed every anti virus on virustotal. I could have wrote the virus myself in a weekend but I thought it was funny that anti virus can't detect a virus thats modified ever so slightly I think we just need a better way of scanning for this stuff.

Exploit DB etc, already exist. They're used for penetration tests as well, to simulate a real attacker, better to have something that you can work off of as a model to detect then let the attacks be the secrets of criminal organizations and state actors.

You train like you fight, you can't do research and build detections if you don't have some examples.

This sort of thing can be useful for white-hats.

Have you seen the malware called "bpfdoor"?

LD_PRELOAD equivalent was used in Windows malware circa 2006.

It seems all the old Windows techniques are now recycled on Linux.

Oh no, first LD_PRELOAD kits for Linux date back to the 90s.

LD_PRELOAD (ish) attacks are older than the web.