Question... if you change the path wouldn't a decent security tool be able to identify that it is a different executable? Also, if you are allowing an executable to access a directory then the executable should also be protected. Thoughts?
A VM is a reasonably defensible boundary which you can use to make meaningful assessments about exposure and vulnerability. It's like safe sex--you assume your partner has an STD and take measures to prevent transmission. VMs are like condoms, as opposed to herbs or reputation heuristics.
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.
I think you'd get a better reception if you started out talking about a digital forensics scenario, and not a vulnerability. There are a lot of ways to install backdoors and rootkits but the mechanisms used aren't called vulnerabilities in estabilished terminology.
The idea for this blog post was that if someone becomes a user in your system but you have a basic security policy in place how can they circumvent it. That is how we came across LD_PRELOAD.
Hey, we agree that if someone can modify your env variables you have got problems ;) But, if you have valuable data on your system then you should have defense in depth so that your most important stuff (secrets, etc...) isn't stolen.
Sure, but that's not what your article is arguing. You literally have a heading "The Vulnerability". It's not a vulnerability, it's not an attack, it's just one option of what you can do after you're done exploiting your way into a system. Not even sure it's a particularly good option; modifying environment variables will mean that at least the target user is fully compromised. In turn, that will mean in pretty much all cases that the attacker is able to just transfer out any and all private keys. And note LD_PRELOAD is only applied when you start something; restarting a long-running process might in itself raise alarm bells or require re-unlocking keys. Much easier to directly take the keys from running process memory.
Yeah... we thought the same thing but we checked a couple other EDRs and saw that a few of them don't do this. If you guys know some EDRs that do this, let us know :)
lol, ok. That's not really an EDR product, and it's open source (which generally produces poor quality security tools, see ClamAV as a long-running joke).
I can't think of a commercial Linux EDR product that doesn't monitor /etc/ld.so.conf and the alternatives.
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.
Hey, I'm a co-founder of Bomfather, we just stumbled upon this problem when we were building our product. Our product doesn't actually secure this, the best solution is to just run your own private runner.
