Hacker News Reader

Comment by chc-sc | Hacker News Reader

I think the real answer is that relatively few people use GNU/Linux

> I think the real answer is that relatively few people use GNU/Linux

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.

When you attack a server, you don't use a virus, you use a phish or something else to gain access to it to do your dirty bidding.

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.

It occurs to me that malicious code that scans WordPress etc. sites for vulnerabilities, installs itself, and sends spam and propagates itself does match the general shape of a virus (even to the point where pattern-matching antivirus would genuinely be effective against it). We just for whatever reason tend not to refer to it as a "WordPress virus," but rather e.g. a "reverse shell" or a "botnet."

I'd call that a worm, not a virus. The main distinction being that a worm propagates all by itself, while a virus requires some user action.

>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 this is why the 'curl | bash' idiom feels like an anti-pattern to me...

Right. Every time you read about a million credit cards being stolen it’s almost certainly from a Linux server, meanwhile the community is patting itself on the back because no viruses are targeting the tiny number of Linux desktop users...

That's about 95% of it. There are other things that give Linux a bit more of an edge in this space as well.

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.

lets not forget the "curl blahblah.com | sudo bash" bit-o-insanity.

I've definitely seen plenty of `curl | bash` installations suggested before (and can honestly say that I've run some, despite knowing the risks), but _sudo_? Is that a thing that people actually do?

https://github.com/nodesource/distributions#installation-ins... I'm sure there are plenty of others.

At the risk of appearing ignorant.. what exactly is the problem here? Do we trust the nodesource deb repo but we do not trust the bash script which is coming from the nodesource domain?

Deb packages have cryptographic signatures that can be verified to confirm it actually came from nodesource (or whoever)

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...

> Deb packages have cryptographic signatures that can be verified to confirm it actually came from nodesource (or whoever)

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.

This seems a little different to me than most `curl | bash` scripts, as it's trying to integrate with the system package manager. Not trying to imply the same security implications don't apply, but there's not really a way to integrate with them without requiring root, and it seems like the entire purpose of this is to integrate with the package manager, which gives you things like an easy way to get updates. (From looking further down the instructions, it looks like this is just setting up a PPA on debian-based distros; I'd personally just paste the config into a file myself, but realistically the security concerns are the same, since I think most package managers give the ability to execute custom code as part of the install process, and it'll be running as root when that code is executed)

Yeah...I don't think I've ever actually done that, but I could see some blog post saying to.

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.

How often do you see that in cases where someone wasn’t going to run the software anyway? I’m not sure how much of a risk this is adding now that HTTPS has become routine — is it really better to install a tarball, unaudited package on NPM/PyPI/etc.?

As if a virus really needed administrator access for anything...

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

You could even replace every command I run with a malware version simply by altering the $PATH in ~/.bashrc. If you manage to replace, say, apt-get with a malware version, you'll get admin permissions every time I run `sudo apt-get ...`.

If your sudo is configured correctly it will have an administrator defined PATH. However if you have sudo price to run apt-get, anything that could manipulate your rc files can just run sudo apt-get on its own. No need to trick you.

Unless it doesn't have your password, and sudo is configured to require auth to elevate. This is the STIG requirement for this exact reason

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.

So far as I can tell, there are two kinds of (effectively) single-user systems, in which a malware infection is targeting a single person:

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".

>Obviously this isn't something that could not be fixed in Windows, and maybe it already has been.

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.

The main flaws with UAC is that you don't know what application is asking for it (This actually ties into a deeper problem which is, you don't know where application binaries reside, and applications are less predictable on Linux). Instead you have to correlate with what you've done recently, which might not align with the process that requested permission.

Not sure what you mean, this is not generally true - the dialog states the name of the process or the application requesting elevation, as you can see in a quick google pics search.

This is not true. Here, I took these screenshots for you where I copied an unsigned binary to a random location and forced a UAC prompt:

https://i.imgur.com/BSJlSAf.png

https://i.imgur.com/4ZVNsPN.png

I also did the same with a signed binary:

https://i.imgur.com/xpSiMMY.png

https://i.imgur.com/ACLydv0.png

Interesting! Looks like my memory failed me, the one time I don't double check...

> and maybe it already has been.

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.

Relevant xkcd:

https://xkcd.com/1200/

Ah, XKCD. Truly a blessing to the modern world!

Without an effective application isolation a la iOS, itis exactly this.

Yea, probably 1% or less of desktop users. However, I bet those targets would be extremely high value (dev environments, server access). I am sure advanced groups heavily invest in gaining access to servers.

Yeah, a lot of high-value secure systems run Linux and GNU. Web services, government systems, the vast majority (edit: it's now all) of the TOP500 supercomputers etc. I suspect at least part of it is that these systems get much more targeted attacks because of their high value, whereas viruses are to an extent un-targeted shotgun attacks. I suspect the economics of virus writing dictate that most of the effort is put towards the most popular platform, i.e. Windows.

The thing there is you almost never need external tooling post-exploitation on Linux; it ships with most of the tools you could want. Add on that nobody seems to be able to harden web servers or SSH, and why would you need "viruses" in a targeted attack? Hack naked, and there's no hash to find.

It's part that, but it's amplified by the fact that even in the tiny desktop GNU/Linux usage, there is no one GNU/Linux: a virus targetting a KDE, or GNOME, or XFCE, or—you get the point—something else, is targetting an even smaller part of that already small number of users.

Basically, the level of diversity in the ecosystem, while part of a reason for less widespread acceptance, also discourages any mainstream attacks.

Yes, but most of the important things are running on Linux, so it's not like it's not a potentially attractive target.

Smart phones and app stores are the real place to look. There are issues there.

Reply on news.ycombinator.com