Hacker News new | ask | show | jobs
by sgarland 354 days ago
And this is why this exploit mechanism works so well.

Most installers are doing the same basic patterns: checking for dependencies, checking the distro, etc. It’s not hard to figure these out and spot them in different scripts.
1 comments
treve 354 days ago
Does it work really well? Any major examples?
link
sgarland 354 days ago
OK, fair-ish point. You won’t find major examples, because it’s not a CVE if you willingly download and execute malicious code. I hope you can understand the theoretical (but very real) risks of doing this, though.

For me personally, I try to use a distro/platform specific package if it exists, since hopefully that means at least one human has read through some of the code, and probably installed it. If that’s not available, I do download the script to review before executing it (and not re-downloading it to pipe to a shell). I’m sure I wouldn’t catch everything, but I would probably catch odd embedded curl calls and the like.

link
treve 351 days ago
It wasn't meant as a gotcha. I'm actually curious if this went wrong, and if it was more of a spear-fishing style attack or a vulnerability hitting multiple people.

Tons of devs download thousands of NPM packages as well, and each can execute code upon install, so a single curl-to-shell pipe from a HTTPS endpoint from a domain you checked always felt way safer than any `npm install`, and so a pretty minor in comparison and yet it gets a lot more attention than package manager, which _feels_ like security cargo culting. Plenty of supply chain attacks in package managers of course. But yeah, would like to be corrected if that intuition is wrong.

link
arp242 354 days ago
As far as I know there are zero examples, CVE or not. I have asked several times over the years and thus no one has been able to provide an example. It just doesn't happen because it just doesn't make much sense.

As I already said years ago[1], if you want to hide some nefarious stuff then you'd do it in something like autoconf soup, or something like that. The install.sh is just too obvious of a place. And this is exactly what happened in the real-world xz attack. I can guarantee you very few, if any, packagers are auditing all of that. And even if they did: it's just so easy to miss.

[1]: https://www.arp242.net/curl-to-sh.html

link