It's a shame that AI is ruining certain phrases, the "You’re absolutely right" was appropriate but I've been trained reading so many AI responses to roll my eyes at that.
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.
OP seems to be a startup selling an eBPF script that tries to identify whether individual executables running as your user "should" or "should not" do particular things. (Like a Windows antivirus program, but for build servers and AI training.) I guess in that context it's good to remember that LD_PRELOAD exists, so it's easy to make any action appear to originate from any executable.
Yeah 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.
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.
LD_PRELOAD is so useful for non-malicious stuff that I hope it doesn't get a reputation as a bad thing to find on your system. That being said, I agree with you and also disagree.
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.
It's a sneaky supply chain threat for docker images. I'm not sure standard container registry tools actively scan for this. Of course you shouldn't be running random untrusted docker images that you find on the internet but it happens all the time in dev envs and in sloppy production environments.
I had ran to my connecting flight, got on as the doors were about to close up (there were a few people still coming, also running).
I sat down, huffing from the run, I asked the flight attendant for a quick sip of water. I said this:
“Excuse me, sorry to bother you but I just had to run to catch the flight, can I get a sip of water? I’m gonna have a heart attack and die of thirst.” Jokingly but still huffing from the run. The captain heard it. Said a few words to another flight attendant, and off the flight I went.
Hindsight, I shouldn’t have made the comment and should have just gone to the restroom but… lesson learned. Southwest got me on a flight 45 minutes later to get home.
This comes up every time npm install is discussed. Yes, npm install will "ignore" your lockfile and install the latest dependancies it can that satisfy the constraints of your package.json. Yes, you should use npm clean-install. One shortcoming is the implementation insists on deleteing the entire node_modules folder, so package installs can actually take quite a bit of time, even when all the packages are being served from the npm disk cache: https://github.com/npm/cli/issues/564
I've found splitting up my ultrawide into 6x2 cells, then you can use Ctrl+Shift to select every cell your mouse enters additively. I've wanted something like this for linux for a long time but haven't found anything.
Off the top of my head, you could include your own checksum in the payload. Their code only modifies the address. Nothing would prevent them from reverse engineering checksum, too.
There are ways to detect a replaced/proxied global window function too, and that's another arms race.
As others have noted, npm install can/will change your lockfile as it installs, and one caveat for the clean-install command they provide is that it is SLOW, since it deletes the entire node_modules directory. Lots of people have complained but they have done nothing: https://github.com/npm/cli/issues/564
The npm team eventually seemed to settle on requiring someone to bring an RFC for this improvment, and the RFC someone did create I think has sat neglected in a corner ever since.
Is there no flag to opt out of this behavior? For Rust, Cargo commands will also do this by default, but they also have `--offline` for not checking online for new versions, `--locked` to require sticking with the exact version of the lockfile even when allowing downloading dependencies online (e.g. if you're building on a machine that's never downloaded dependencies before, so they aren't cached locally, but you still don't want to allow implicit updates), and `--frozen` (which is a shorthand for both `--locked` and `--offline`). I'm honestly on the fence about whether this is even sufficient, since I've worked at multiple places where the CI didn't actually run with `--locked` because whoever configured it didn't realize, and at least once a surprise update to the lockfile in CI ended up causing an issue that took a bit of time to debug before someone realized what was going on.
