LD_PRELOAD, The Invisible Key Theft
bomfather.dev
bomfather.dev
This sort of seems like saying IF an attacker gets the keys to your car, they could install a module that would allow them to come back and steal the car with a push of a button. Technically true, but they could also just steal the car straight up, or do any number of other things.
it's snake oil
assume each and every VM is born compromised and deal with them accordingly
Most of this recent eBPF tooling, especially the products that pretend to mitigate exploits, is just recapitulating the security theater of the Windows world. And we all know how that turned out. Windows' security was a joke until Microsoft changed course and started focusing on correctness and meaningful and defensible architectural boundaries. Sadly the corporate embrace of Linux seems to be pulling the ecosystem along the same path Windows and the big Unix vendors were taken.
From a defenders perspective, you have lost if an attacker has root access on your system. You are right. Consider instead the attackers perspective.
To an attacker compromising and system and gaining root is just the first step of a many step process. One of the hardest steps is modifying the system to silently collect and exfil secrets and data that is valuable to you. Let's say you want encryption keys and only keys, how do you get them? For the sake of example say they are stored on the file system and you want to exfil them as they rotated weekly. Do you write a program with a cron job that checks once per day and uploads them? What if three months later they switch from rotating their keys once a week to once every two hours?
1. How long does it take you to notice your missing most of the keys and what is the cost of this failure?
2. Once you notice you aren't getting all the keys, you need to figure out why. This can take time and money. Do you access the compromised machines again? What if you can't get back into the machine again to figure what happened?
3. Once you figure out why, you need to deploy a patch to your exfil kit. This again costs time and money. What if you didn't test it properly and it breaks the compromised host and exposes your entire operation? You might have to push this one to thousands of compromised machines.
Instead, use LD_PRELOAD to hook filesystem writes, pattern match the key format on and exfil the keys as they are written. Since the hook is environment variable based, it can survive changes to the targeted program. Granted there are other approaches as well, but LD_PRELOAD is simple, powerful, flexible and often used for non-malicious things so it doesn't immediately trigger alarm bells.
I can't think of a commercial Linux EDR product that doesn't monitor /etc/ld.so.conf and the alternatives.
> does not detect initial compromise
> does not detect persistent so
> does not detect preloads
> does not detect injection
> does not detect exfiltration
What does the D stand for again? Besides the entire threat vector and article being an unsurprising non-story. Yes, if you can modify the execution environment you can modify the executed code.
Over the coming months, OP will gradually discover all the techniques that cheat/anticheat people have used for decades.
I think you meant PTRACE_ATTACH, there is no pthread_attach ;)
The newer process_vm_readv() is easier btw, for the implied function of reading from the target process' memory.
Spoiler alert, you almost certainly have been completely pwned already if someone can set LD_PRELOAD or modify /etc/ld.so.conf.
One such assumption is "if /bin/foo is a trustworthy executable then any process with /proc/pid/exe pointing to /bin/foo is trustworthy"
We know that this isn't anything revolutionary, but most people assume that this kind of thing can't happen, so we wrote a blog post about it.
What's the relevance of symlinks here?
That said, your example doesn't make much sense to me. I'd be willing to bet a lot of money that the authors of the exploit chain you mentioned are aware of LD_PRELOAD and /etc/ld.so.conf.
Their GPU "hijacking" demo has the victim deliberately publish CUDA IPC handles to world-readable shared memory (0666), then calls normal CUDA IPC functionality an "attack."
Their eBPF paper on ArXiv lacks evaluation or performance metrics.
The company appears to be three people: the founder and his two teenage sons (10th and 8th grade) listed as paper co-authors. No customers, no team page, launched right before college application season. The technical work exists but reads like it's optimized for admissions committees rather than advancing security research.
LD_PRELOAD has been a standard Linux feature since the 90s. Calling it "The Invisible Key Theft" and pitching an eBPF product as the solution misrepresents both the threat model and what constitutes novel security research.
an attacker that is already your user can do far worse than hook into libc