4 ms·
LD_PRELOAD, The Invisible Key Theft
- deleted 1y ago[deleted]
- eqvinox 1y agoThis 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.
- nathan_naveen 1y agoHey, 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.
- eqvinox 1y agoSure, 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.
- stuaxo 1y agoHow is someone supposed to deploy this ?
- FeepingCreature 1y agoFirst, have remote shell.
- TheAdamist 1y agoLD_AUDIT is even more powerful and fun to use. And far lesser known.
- nathan_naveen 1y agoThank you! We will take a look!
- Mattwmaster58 1y agoThis 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.
- webstrand 1y agoYeah if you have the level of access necessary to inject a LD_PRELOAD, you have the level of access necessary to set PATH so an entirely different binary loads, too.
- nathan_naveen 1y agoQuestion... 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?
- blibble 1y agothere aren't any decent security tools it's snake oil assume each and every VM is born compromised and deal with them accordingly
- nathan_naveen 1y agoVMs are themselves untrustworthy we should be computing with paper and pencil (and flipping bits with an eraser)... Lol!
- wahern 1y agoA 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.
- formerly_proven 1y ago> run EDR > 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.
- ilc 1y agoWhat you take if you use a bad one?
- danielhlockard 1y agodear lord. This is not new. ld_preload to do things like this existed even back when I was doing Cyber Defense Competitions at Iowa State back in '07
- bpt3 1y agoYep. Every few months, someone learns about this, thinks they've made a new discovery, and writes a breathless blog post imagining the possibilities of what can be done with it. Spoiler alert, you almost certainly have been completely pwned already if someone can set LD_PRELOAD or modify /etc/ld.so.conf.
- Retr0id 1y agoLD_PRELOAD "works as designed" but people who don't know about it often make false assumptions, leading to exploitable bugs. One such assumption is "if /bin/foo is a trustworthy executable then any process with /proc/pid/exe pointing to /bin/foo is trustworthy"
- nathan_naveen 1y agoExactly, that is our thought process! 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.
- bpt3 1y agoPlease describe the scenario where someone needs to make the assumption you described and it is reasonable to expect that they are unaware that symbolic links could be changed by a third party library?
- Retr0id 1y agoI know one example off the top of my head, but it's part of an exploit chain I haven't got around to reporting yet ;) What's the relevance of symlinks here?
- nathan_naveen 1y agoHey, 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.
- Retr0id 1y agoI'm not familiar with the state-of-the-art in Linux EDRs but I assumed checking LD_PRELOAD was table stakes.
- nathan_naveen 1y agoYeah... 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 :)
- bpt3 1y agoWhat did you check? Nearly every EDR product does this to my knowledge.
- nathan_naveen 1y agoKubeArmor...
- bpt3 1y agolol, 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.
- gabriel 1y agoI would back it up a little bit and say that any EDR thing would be capable of observing the source of the functions that a program will run and detect outliers. It's a great program to write, everyone should give it a try! It can also be unexpectedly complicated to get all of the corner cases right and you'll drive yourself mad once you try to think of the ways your detection method can be circumvented.
- blibble 1y agothere is no additional threat here beyond what you can already do as the user an attacker that is already your user can do far worse than hook into libc
- nathan_naveen 1y agoThe 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.
- SamuelNickel 1y agoThis is Not a vulnerability. It is expected behavior. If someone can Set Environment variables or write to /etc/ it is already game over
- deleted 1y ago[deleted]
- richm44 1y agoHere's an example I made a while ago of how easy it is to use LD_PRELOAD to hook things and change file contents etc. https://github.com/richmoore/reciprocity https://github.com/richmoore/reciprocity
- nathan_naveen 1y agoNice! Looks cool!
- pjc50 1y agoNext week: pthread_attach(). Over the coming months, OP will gradually discover all the techniques that cheat/anticheat people have used for decades.
- eqvinox 1y ago> Next week: pthread_attach(). 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.
- fulafel 1y agoWait until you hear about $PATH, $LD_LIBRARY_PATH, $IFS, and so on - or the rest of the OS files in /etc and /lib aside from /etc/ld.preload.
- huerne 1y agoThe 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.