This is not a vulnerability. If someone can modify your environment variables or /etc/ld.so.conf, your system is already wholly, entirely and utterly compromised.
This doesn't seem like a realistic threat to me. Under what circumstances are you not pretty much completely pwned if an attacker could start their own processes, or have root access?
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.
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.
Hey, the author here... Our blog post is mainly talking about how the vulnerability works, but even if there is an insider threat (or reverse shell or any kind of attack) there are ways to stop this. We at Bomfather have a solution for this (we aren't trying to plug ourselves here), but any good eBPF solution should be able to protect this.
The pattern across their repo is concerning: rebranding documented system features as "exploits."
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.
16 comments
[ 4.6 ms ] story [ 49.6 ms ] threadThis 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.
> 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.
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.
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.