Second, the thing about viruses (as opposed to other types of exploits) is that the user has to run them, and Linux doesn’t make downloaded files executable by default the way Windows does. Nor are Linux users conditioned to download programs from random sketchy sources the way Windows users do.
Nor are Linux users conditioned to download programs from random sketchy sources the way Windows users do.
I think about this every time install instructions for something are “run this terminal command to add our repo to your sources”. Would probably be pretty easy to get an auto-updating attack path for the unsuspecting. The first drop doesn’t even need to be malicious, just ship the virus as an update.
Yeah, if you’re doing some sort of curl | sh nonsense you’d better trust whoever is supplying that script implicitly. On the bright side, I’ve only ever seen that on the first-party website of the project being installed, so it could be worse.
I think about this every time install instructions for something are “run this terminal command to add our repo to your sources”.
Or when there’s an installation option that’s just piping curl/wget into bash, like
curl -sSL https://install.pi-hole.net/ | bash
It’s super convenient! But risky. Even if the fetched script is legit, the command is still one typo’d URL away from fetching and executing something entirely different (imagine squatters sitting on install.pi-hole.com instead of .net and serving a malicious script)
I appreciated that pi-hole was (and still is) transparent about the drawbacks of this installation method when I installed it years ago.
I think the biggest risk now is supply chain poisoning, where a system update or package installation runs executable code alongside it that can be malicious, as most supply chains for Linux distros don’t have automatic security checks in place but rather rely on the security of the identity of the package maintainer. If their setup gets compromised that’s the bigger risk rather than the traditional “virus” like you said
First of all, username checks out.
Second, the thing about viruses (as opposed to other types of exploits) is that the user has to run them, and Linux doesn’t make downloaded files executable by default the way Windows does. Nor are Linux users conditioned to download programs from random sketchy sources the way Windows users do.
I think about this every time install instructions for something are “run this terminal command to add our repo to your sources”. Would probably be pretty easy to get an auto-updating attack path for the unsuspecting. The first drop doesn’t even need to be malicious, just ship the virus as an update.
Yeah, if you’re doing some sort of
curl | shnonsense you’d better trust whoever is supplying that script implicitly. On the bright side, I’ve only ever seen that on the first-party website of the project being installed, so it could be worse.Or when there’s an installation option that’s just piping curl/wget into bash, like
curl -sSL https://install.pi-hole.net/ | bashIt’s super convenient! But risky. Even if the fetched script is legit, the command is still one typo’d URL away from fetching and executing something entirely different (imagine squatters sitting on install.pi-hole.com instead of .net and serving a malicious script)
I appreciated that pi-hole was (and still is) transparent about the drawbacks of this installation method when I installed it years ago.
I think the biggest risk now is supply chain poisoning, where a system update or package installation runs executable code alongside it that can be malicious, as most supply chains for Linux distros don’t have automatic security checks in place but rather rely on the security of the identity of the package maintainer. If their setup gets compromised that’s the bigger risk rather than the traditional “virus” like you said