Ld_preload, the Invisible Key Theft
Posted3 months agoActive3 months ago
bomfather.devTechstory
calmmixed
Debate
60/100
SecurityLinuxExploit
Key topics
Security
Linux
Exploit
The article discusses how LD_PRELOAD can be used to steal SSH keys, and the discussion revolves around the severity of this vulnerability and potential mitigations.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
26m
Peak period
30
0-2h
Avg / period
7.7
Comment distribution46 data points
Loading chart...
Based on 46 loaded comments
Key moments
- 01Story posted
Oct 16, 2025 at 11:29 AM EDT
3 months ago
Step 01 - 02First comment
Oct 16, 2025 at 11:55 AM EDT
26m after posting
Step 02 - 03Peak activity
30 comments in 0-2h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 17, 2025 at 9:55 AM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45606611Type: storyLast synced: 11/20/2025, 6:24:41 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
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.
> 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.
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"
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.
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.
I can't think of a commercial Linux EDR product that doesn't monitor /etc/ld.so.conf and the alternatives.
an attacker that is already your user can do far worse than hook into libc
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.
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.