It's a joke, not analysis. Was hoping for the latter.
95% of the server market, though. Which is a huge proportion of attack space. Why steal one sod's credit card numbers when you can steal 100s of them at the same time.
What people call "viruses" usually refer only to attacks that work by getting people to execute random crap on their computer with their privileges. Servers are set up and administered in a way such that it is far harder to get somebody to run the payload containing the virus in the first place, so viruses target machines that are administered by end users (which would include home computers and smartphones!). The 95% market share for servers is irrelevant since viruses don't target servers in the first place.
So this is why the 'curl | bash' idiom feels like an anti-pattern to me...
For example, every time I use Windows, it feels like every app is asking to run as administrator. Admittedly, I haven't used Windows for about a year, but in Linux, it's pretty rare that I ever do admin/sudo outside of the command line, and I only ever use it when I know what I'm doing. Obviously this isn't something that could not be fixed in Windows, and maybe it already has been.
1. The kind where users are rarely asked to assume admin privileges and all the data a user has to protect is available without administrator access.
2. The kind where users are frequently asked to assume admin privileges and some of the data a user has to protect requires administrator access.
I don't believe Linux has any real edge here. I agree that 95% of the effect is due to Linux's paltry desktop user base; I'd guess than at least 4% is due simply to malware that targets Linux not being called "a virus".
There is nothing even remotely obvious about that statement. If it was anything near possible it wouldn't an ongoing problem, unsolved for the last 12 years, since the introduction of UAC in Windows Vista.
Now I wouldn't say that Microsoft didn't progress. Far from it. Almost no one I knew kept Vista UAC enabled, as it was constant nag. Nowadays most folks can live with it, and corporations don't feel like they have to disable it and compromise their security to maintain their employees productive.
But it is still annoying way to often for it's own good. Many people are just automatically allowing everything, just like they press Yes or OK on every dialog box without ever reading it.
The reason it is so different on Windows is, in a nutshell, that Windows is a very different beast, and the way users and developers operate on it is not at all similar to what is done on Linux.
The integration of Windows applications with the OS API is something that, for better and for worse, doesn't exist on Linux. Be it the GUI, the Settings storage (registry vs config files) or any other part of the system.
https://i.imgur.com/BSJlSAf.png
https://i.imgur.com/4ZVNsPN.png
I also did the same with a signed binary:
Not completely, but I think it's mostly OK. I only see UAC prompts rarely, usually in one of these 3 cases.
1. Some software that I've written has good reasons to require elevation, I sometimes work on low level system software which uses weird WinAPI calls.
2. When installing software. The default location of installed programs, C:\Program Files, is read only unless running elevated. Probably done for extra security.
3. When using very old software, or bad quality ports from other OSes. UAC was introduced in Vista, some software which was written for WinXP or older versions requires elevation for no good reason.
I think an annoying truth that us Linux-users don't like to admit is that another large part of what makes linux "more secure" is that only technical people bother using it. My parents are both smart people, but aren't programmers or anything, and as a result didn't like Linux when I tried to get them to use it; if they did use Ubuntu it's entirely possible that they'd figure out how to get a virus pretty quickly.
If you get MITM'd (admittedly difficult with TLS) or the site got compromised (but not the build IX / developer's keyring) it would be possible to replace the script with a malicious one.
Also, you can detect the curl|bash installation method server-side and serve different content [1] on that basis, which is not possible with deb packages.
Finally, providing a curl|bash installation method implies that the developers either do not understand packaging, or don't care about it. This is fine e.g. if developers want to remain platform agnostic or just can't be bothered packaging, but if you develop a curl|bash installer you send the message "I want to distribute my software but don't care enough to do it properly / in a standards compliant way".
Also, and this is more subjective, most curl|bash installers I've seen make assumptions about their environments that do not necessarily hold in less common distributions - which makes you wonder why they don't just develop e.g. a deb if it only works reliably on Ubuntu and maybe Debian.
[1] https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...
And how do you get the GPG key to verify such signatures from third-parties? Usually via https from their website, no?
> Also, you can detect the curl|bash installation method server-side and serve different content
Yes, but you are supposed to trust people you get you packages from not to do it. And so and it should only make a difference if their servers are compromised and they sign packages with a key stored offline.
I think the latter is much less common then one would hope, with release processes in CI and such.
Maybe to fuck up your machine... but if they want to snoop on your passwords, encrypt your files, mine bitcoin, participate in a DoS attack... they can do that without elevating
Edit: of course, it could just manipulate the path to include it's own evil sudo wrapper, but the chess match always sounds like this.
Basically, the level of diversity in the ecosystem, while part of a reason for less widespread acceptance, also discourages any mainstream attacks.