13 ms·

Why GNU/Linux Viruses Are Fairly Uncommon

182 points by jason0597 7y ago

edoceo 7y ago
It's a joke, not analysis. Was hoping for the latter.
- chc-sc 7y ago
  I think the real answer is that relatively few people use GNU/Linux
  - tombert 7y ago
    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.
    - jwkane 7y ago
      lets not forget the "curl blahblah.com | sudo bash" bit-o-insanity.
      - saghm 7y ago
        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?
        jwkane 7y ago
        https://github.com/nodesource/distributions#installation-instructions https://github.com/nodesource/distributions#installation-ins... I'm sure there are plenty of others.
        robrtsql 7y ago
        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?
        waste_monk 7y ago
        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-bash-server-side/ https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...
        phaer 7y ago
        > 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.
      - tombert 7y ago
        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.
      - acdha 7y ago
        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.?
    - zuuow 7y ago
      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
      - deleted 7y ago
        [deleted]
      - pvorb 7y ago
        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 ...`.
        wang_li 7y ago
        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.
        Godel_unicode 7y ago
        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.
    - tptacek 7y ago
      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".
    - zaat 7y ago
      >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.
      - fao_ 7y ago
        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.
        zaat 7y ago
        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.
        raptorfactor 7y ago
        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/BSJlSAf.png https://i.imgur.com/4ZVNsPN.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/xpSiMMY.png https://i.imgur.com/ACLydv0.png https://i.imgur.com/ACLydv0.png
    - Const-me 7y ago
      > 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.
    - smnrchrds 7y ago
      Relevant xkcd: https://xkcd.com/1200/ https://xkcd.com/1200/
      - dinofacedude 7y ago
        Ah, XKCD. Truly a blessing to the modern world!
      - ChrisCinelli 7y ago
        Without an effective application isolation a la iOS, itis exactly this.
  - mjevans 7y ago
    Smart phones and app stores are the real place to look. There are issues there.
  - TACIXAT 7y ago
    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.
    - gh02t 7y ago
      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.
    - Godel_unicode 7y ago
      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.
  - fao_ 7y ago
    > 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.
    - jcranmer 7y ago
      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.
      - geofft 7y ago
        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."
        Beldin 7y ago
        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.
      - ohithereyou 7y ago
        >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...
  - _emacsomancer_ 7y ago
    Yes, but most of the important things are running on Linux, so it's not like it's not a potentially attractive target.
  - necovek 7y ago
    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.
- OrgNet 7y ago
  what is the latter? not an analysis?
ohazi 7y ago
On a more serious note, I'm surprised there hasn't been much discussion about potential malware in official Linux package repositories vs. developer-centric source repositories like npm, rubygems, crates.io, etc. One would hope that the bar is higher with strict maintainership rules, but there are a zillion packages, and you can't vet them all. Also, practically everyone installs binary packages, so until we have fully reproducible builds, hiding malware in some obscure but heavily depended on package could actually be relatively easy.
- nextos 7y ago
  Nix/Guix are quite cool to tackle this. They are progressing quite quickly towards reproducible builds, so you can avoid compromised servers sending malicious binaries. Also, since package definitions are quite declarative, I guess it's easier to perform static verification to spot malicious code getting introduced there. There's e.g. Vulnix that scans for CVEs [1]. [1] https://github.com/flyingcircusio/vulnix https://github.com/flyingcircusio/vulnix
  - swdunlop 7y ago
    NixOS (and NixPkgs) is great, but there are still plenty of binary only packages from difficult to build projects like PhantomJS in the ecosystem. It takes a serious commitment to build complex projects in Nix and maintain them. (edit) An example of binary packages in Nixpkgs: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/tools/phantomjs/default.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/developmen...
    - baroffoos 7y ago
      Should you really be installing programs that are impossible to build? Also phantomjs is discontinued.
      - swdunlop 7y ago
        That's a great question, but it does not invalidate the point that there is nothing about Nix that states that binary packages cannot and do not happen.
liability 7y ago
I've always sort of suspected there might be a 'don't shit where you eat' component to it. If you're just being a dick by screwing with people for fun, not profit, then maybe you screw with the windows users instead of your fellow linux users. Maybe that's giving them too much credit though.
- pfundstein 7y ago
  Most malware code I've seen is terribly written and barely works. Hobbyist malware programmers use Windows and write for Windows for the simple reason that it's all they know. Some skiddies use Kali Linux but only because they managed to follow step-by-step instructions on YouTube without which they're lost.
  - yesenadam 7y ago
    Maybe if it's 'good' you don't see it? Like we only hear about the criminals that get caught...
    - pfundstein 7y ago
      The funny thing is the most advanced malware out there today (that we know of) was created by the US and Israeli governments. [1] https://www.symantec.com/security-center/writeup/2010-071400-3123-99 https://www.symantec.com/security-center/writeup/2010-071400... [2] https://www.computerworld.com/article/2934593/duqu-2-0-kaspersky-israel-itbwcw.html https://www.computerworld.com/article/2934593/duqu-2-0-kaspe...
      - deleted 7y ago
        [deleted]
  - dead_mall 7y ago
    > Most malware code I've seen is terribly written and barely works. Yeaah cause someone is just going to be so kind enough to share their perfect example of what malware code should look like to the rest of the world.. (actually there's an F ton available on Github, quasar, pupyrat, etc) Don't be so naive man. As a hobbyist malware programmer myself, I know that you don't know what you're really talking about other than pointing out skids targeting Windows (cause most available malware/RATs are targeted for windows) and use Kali cause-so-many-yt-tutorials. edit: fwiw, I find it much easier writing malware under *nix cause they come with python and a bunch of dev libs, where as windows I have to dynamically load libraries in sneaky ways. Also implementing rootkits & RunPEs can be pretty damn puzzling -- definitely not that easy as you say
zanny 7y ago
Its a pet peeve of mine that the GNU/Linux world is 99% of the way to an incredible degree of security but distros are totally disinterested in going the last mile, often because its a lot of boring work. Mandatory Access Control should have been game changing in the security sphere, especially in the era of cgroups. Fine grained permissions controls in the kernel and filesystem would stomp out almost all potential malware vectors - both exploited software and injected binaries. GUI desktops could have provided UI to prompt users for unknown programs trying to access specific things and then send reports upstream of programs allowed for review. It would practically be a self-building database of program file access if done right. But that isn't the only avenue to it. You could pressure upstream to include discriptor files in git repos of a standardized format of file access for each binary that can be used to generate selinux / apparmor / tomoyo rules. You could do it the really hard way and just have a sprint to surface test every program in official repos and generate such files yourself. Programs should almost never be accessing anything outside their XDG conf file and data dir - they should be linking libraries to provide access to other stuff (input, gui, etc) and file access should go through the system wide file picker. As it is right now though pretty much every executed binary on most Linux systems is allowed to do whatever it wants that it has user access privilege to. Especially because most maintainers don't want to have to bother with the complaints of malcontent software breaking constantly trying to read arbitrary files. The Apparmor profiles of SUSE / Ubuntu or SELinux of Fedora are largely written for a few specific programs, usually web browsers and file sharing daemons, rather than be comprehensive. Its such a shame that all the technologies exist and are in place to make this work (even Arch has Apparmor support in its official repos now!) but there is no willpower / capital / interest in going the last step and trying to be all encompassing in your MAC profile and then lock down unknown programs appropriately. Android pretty much does this already, its a shame desktop Linux totally skipped over this avenue towards secure desktops. There is of course an argument that if you lock down programs with network access then thats all you need to secure your desktop but that position falters in the face of arbitrary programs being run at random that can include network access. The goal should be a default restricted profile - one where arbitrary binaries cannot do whatever they want to your system, in the context of having a comprehensive profile database of software being used that covers 99% of real world program usage and thus doesn't impose a sizable UX burden of constant usage prompts for common applications.
bediger4000 7y ago
It's conceivable that this is the real reason. Maybe Windows is a "dragon king" statistical outlier in terms of malware. As an example, every once in a while a file "type" that previously nobody knew could be executed causes problems because someone finally figures out that it could be executed. MacOS certainly has problems with malware, but not even to the same order of magnitude as Windows.
TheMagicHorsey 7y ago
The security of GNU/Linux is based mostly on people not being particularly interested in exploiting Linux users ... because they are more sophisticated and because there are less of them. If Linux ever becomes useable for the average consumer and its adopted widely, we will see plenty of viruses for it. I'm more optimistic about systems like Fuschia which are capability-based from the kernel up.
thyrsus 7y ago
2005: The short life and hard times of a Linux virus https://web.archive.org/web/20140925152325/http://librenix.com/?inode=21 https://web.archive.org/web/20140925152325/http://librenix.c... ...although market share certainly also plays a part.
commandlinefan 7y ago
Except that now everybody insists that you should be using package managers like apt and yum instead.
- Godel_unicode 7y ago
  Who are these people? In the Python community, no project ever used yum/apt. Their versions of basically every package (where they even have it) are hilariously out of date with what you should use. They are frequently missing major security fixes, in addition to the usual functionality ones. My understanding is that this applies to most other languages as well. To say nothing of docker base images and popular docker containers...
  - necovek 7y ago
    I am the one saying that: for any Python packages in Ubuntu main, use them. Why worry about tracking security issues of all your dependencies, when you can have that done by distribution's security team (Ubuntu pledges to patch all security bugs).
    - Godel_unicode 7y ago
      Are you a Python developer? How do you deal with the Ubuntu versions being different than the PyPI versions?
      - necovek 7y ago
        Are you a Python developer?[1] How do you deal with your project depending on an older version of a package with pip? Basically, it's just like that (but instead of specifying your version in requires.txt/setup.py, you just install a package with a particular version). You've got an older library version that gets automatic security updates but does not break backwards compatibility (or it's a bug in the distro). Ubuntu/Debian packages manage dependencies as well, so for anything you install from the "archive" (distribution's repository), you get compatible dependencies as well, so you can further reduce number of packages you need to pull in with pip. It's a bit of a bother if you've got two sources of dependencies, but if you can get free security updates and no backwards compatibility breakage for 5 years (Ubuntu LTS guarantee for packages in main), it's a small price to pay (though it certainly depends on the use case as well). And luckily, Python + PyPI are _not_ JavaScript + NPM: with Python, you get a large standard library, and as you do not always need the latest and greatest of everything, you will not have hundreds, if not thousands of dependencies that you get with JS+NPM. [1] Your first tongue-in-cheek question is, imho, totally inappropriate. If I misunderstood and it was not meant in a sarcastic way, I apologize for attempting to return the favour. :) Even then, your second question is totally valid and should have been sufficient if you honestly care.
Godel_unicode 7y ago
Ctrl+f "iot" Ctrl+f "Mirai" Oh, it's a joke. Got it.
- tfolbrecht 7y ago
  Leaving your door wide open isn't anyone's fault but your own. All the configurations and procedures for secure devices were there but manufactures couldn't bother.
JJMcJ 7y ago
Outlook doesn't run on *nix systems.
ChrisCinelli 7y ago
Are we talking of just virus or other types of malware and rootkits? Not sure what "uncommon" means but I think https://news.ycombinator.com/item?id=20682546 https://news.ycombinator.com/item?id=20682546 already documented that successful attacks are not rare.
pjmlp 7y ago
On the other hand, "Unpatched KDE vulnerability disclosed on Twitter" https://www.zdnet.com/article/unpatched-kde-vulnerability-disclosed-on-twitter/ https://www.zdnet.com/article/unpatched-kde-vulnerability-di...

182 points by jason0597 7y ago

edoceo 7y ago

It's a joke, not analysis. Was hoping for the latter.

chc-sc 7y ago
I think the real answer is that relatively few people use GNU/Linux
- tombert 7y ago
  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.
  - jwkane 7y ago
    lets not forget the "curl blahblah.com | sudo bash" bit-o-insanity.
    - saghm 7y ago
      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?
      - jwkane 7y ago
        https://github.com/nodesource/distributions#installation-instructions https://github.com/nodesource/distributions#installation-ins... I'm sure there are plenty of others.
        robrtsql 7y ago
        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?
        waste_monk 7y ago
        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-bash-server-side/ https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...
        phaer 7y ago
        > 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.
    - tombert 7y ago
      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.
    - acdha 7y ago
      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.?
  - zuuow 7y ago
    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
    - deleted 7y ago
      [deleted]
    - pvorb 7y ago
      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 ...`.
      - wang_li 7y ago
        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.
        Godel_unicode 7y ago
        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.
  - tptacek 7y ago
    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".
  - zaat 7y ago
    >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.
    - fao_ 7y ago
      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.
      - zaat 7y ago
        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.
      - raptorfactor 7y ago
        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/BSJlSAf.png https://i.imgur.com/4ZVNsPN.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/xpSiMMY.png https://i.imgur.com/ACLydv0.png https://i.imgur.com/ACLydv0.png
  - Const-me 7y ago
    > 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.
  - smnrchrds 7y ago
    Relevant xkcd: https://xkcd.com/1200/ https://xkcd.com/1200/
    - dinofacedude 7y ago
      Ah, XKCD. Truly a blessing to the modern world!
    - ChrisCinelli 7y ago
      Without an effective application isolation a la iOS, itis exactly this.
- mjevans 7y ago
  Smart phones and app stores are the real place to look. There are issues there.
- TACIXAT 7y ago
  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.
  - gh02t 7y ago
    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.
  - Godel_unicode 7y ago
    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.
- fao_ 7y ago
  > 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.
  - jcranmer 7y ago
    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.
    - geofft 7y ago
      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."
      - Beldin 7y ago
        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.
    - ohithereyou 7y ago
      >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...
- _emacsomancer_ 7y ago
  Yes, but most of the important things are running on Linux, so it's not like it's not a potentially attractive target.
- necovek 7y ago
  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.
OrgNet 7y ago
what is the latter? not an analysis?

ohazi 7y ago

On a more serious note, I'm surprised there hasn't been much discussion about potential malware in official Linux package repositories vs. developer-centric source repositories like npm, rubygems, crates.io, etc. One would hope that the bar is higher with strict maintainership rules, but there are a zillion packages, and you can't vet them all. Also, practically everyone installs binary packages, so until we have fully reproducible builds, hiding malware in some obscure but heavily depended on package could actually be relatively easy.

nextos 7y ago
Nix/Guix are quite cool to tackle this. They are progressing quite quickly towards reproducible builds, so you can avoid compromised servers sending malicious binaries. Also, since package definitions are quite declarative, I guess it's easier to perform static verification to spot malicious code getting introduced there. There's e.g. Vulnix that scans for CVEs [1]. [1] https://github.com/flyingcircusio/vulnix https://github.com/flyingcircusio/vulnix
- swdunlop 7y ago
  NixOS (and NixPkgs) is great, but there are still plenty of binary only packages from difficult to build projects like PhantomJS in the ecosystem. It takes a serious commitment to build complex projects in Nix and maintain them. (edit) An example of binary packages in Nixpkgs: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/tools/phantomjs/default.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/developmen...
  - baroffoos 7y ago
    Should you really be installing programs that are impossible to build? Also phantomjs is discontinued.
    - swdunlop 7y ago
      That's a great question, but it does not invalidate the point that there is nothing about Nix that states that binary packages cannot and do not happen.

liability 7y ago

I've always sort of suspected there might be a 'don't shit where you eat' component to it. If you're just being a dick by screwing with people for fun, not profit, then maybe you screw with the windows users instead of your fellow linux users. Maybe that's giving them too much credit though.

pfundstein 7y ago
Most malware code I've seen is terribly written and barely works. Hobbyist malware programmers use Windows and write for Windows for the simple reason that it's all they know. Some skiddies use Kali Linux but only because they managed to follow step-by-step instructions on YouTube without which they're lost.
- yesenadam 7y ago
  Maybe if it's 'good' you don't see it? Like we only hear about the criminals that get caught...
  - pfundstein 7y ago
    The funny thing is the most advanced malware out there today (that we know of) was created by the US and Israeli governments. [1] https://www.symantec.com/security-center/writeup/2010-071400-3123-99 https://www.symantec.com/security-center/writeup/2010-071400... [2] https://www.computerworld.com/article/2934593/duqu-2-0-kaspersky-israel-itbwcw.html https://www.computerworld.com/article/2934593/duqu-2-0-kaspe...
    - deleted 7y ago
      [deleted]
- dead_mall 7y ago
  > Most malware code I've seen is terribly written and barely works. Yeaah cause someone is just going to be so kind enough to share their perfect example of what malware code should look like to the rest of the world.. (actually there's an F ton available on Github, quasar, pupyrat, etc) Don't be so naive man. As a hobbyist malware programmer myself, I know that you don't know what you're really talking about other than pointing out skids targeting Windows (cause most available malware/RATs are targeted for windows) and use Kali cause-so-many-yt-tutorials. edit: fwiw, I find it much easier writing malware under *nix cause they come with python and a bunch of dev libs, where as windows I have to dynamically load libraries in sneaky ways. Also implementing rootkits & RunPEs can be pretty damn puzzling -- definitely not that easy as you say

zanny 7y ago

Its a pet peeve of mine that the GNU/Linux world is 99% of the way to an incredible degree of security but distros are totally disinterested in going the last mile, often because its a lot of boring work. Mandatory Access Control should have been game changing in the security sphere, especially in the era of cgroups. Fine grained permissions controls in the kernel and filesystem would stomp out almost all potential malware vectors - both exploited software and injected binaries. GUI desktops could have provided UI to prompt users for unknown programs trying to access specific things and then send reports upstream of programs allowed for review. It would practically be a self-building database of program file access if done right. But that isn't the only avenue to it. You could pressure upstream to include discriptor files in git repos of a standardized format of file access for each binary that can be used to generate selinux / apparmor / tomoyo rules. You could do it the really hard way and just have a sprint to surface test every program in official repos and generate such files yourself. Programs should almost never be accessing anything outside their XDG conf file and data dir - they should be linking libraries to provide access to other stuff (input, gui, etc) and file access should go through the system wide file picker. As it is right now though pretty much every executed binary on most Linux systems is allowed to do whatever it wants that it has user access privilege to. Especially because most maintainers don't want to have to bother with the complaints of malcontent software breaking constantly trying to read arbitrary files. The Apparmor profiles of SUSE / Ubuntu or SELinux of Fedora are largely written for a few specific programs, usually web browsers and file sharing daemons, rather than be comprehensive. Its such a shame that all the technologies exist and are in place to make this work (even Arch has Apparmor support in its official repos now!) but there is no willpower / capital / interest in going the last step and trying to be all encompassing in your MAC profile and then lock down unknown programs appropriately. Android pretty much does this already, its a shame desktop Linux totally skipped over this avenue towards secure desktops. There is of course an argument that if you lock down programs with network access then thats all you need to secure your desktop but that position falters in the face of arbitrary programs being run at random that can include network access. The goal should be a default restricted profile - one where arbitrary binaries cannot do whatever they want to your system, in the context of having a comprehensive profile database of software being used that covers 99% of real world program usage and thus doesn't impose a sizable UX burden of constant usage prompts for common applications.

bediger4000 7y ago

It's conceivable that this is the real reason. Maybe Windows is a "dragon king" statistical outlier in terms of malware. As an example, every once in a while a file "type" that previously nobody knew could be executed causes problems because someone finally figures out that it could be executed. MacOS certainly has problems with malware, but not even to the same order of magnitude as Windows.

TheMagicHorsey 7y ago

The security of GNU/Linux is based mostly on people not being particularly interested in exploiting Linux users ... because they are more sophisticated and because there are less of them. If Linux ever becomes useable for the average consumer and its adopted widely, we will see plenty of viruses for it. I'm more optimistic about systems like Fuschia which are capability-based from the kernel up.

thyrsus 7y ago

2005: The short life and hard times of a Linux virus https://web.archive.org/web/20140925152325/http://librenix.com/?inode=21 https://web.archive.org/web/20140925152325/http://librenix.c... ...although market share certainly also plays a part.

commandlinefan 7y ago

Except that now everybody insists that you should be using package managers like apt and yum instead.

Godel_unicode 7y ago
Who are these people? In the Python community, no project ever used yum/apt. Their versions of basically every package (where they even have it) are hilariously out of date with what you should use. They are frequently missing major security fixes, in addition to the usual functionality ones. My understanding is that this applies to most other languages as well. To say nothing of docker base images and popular docker containers...
- necovek 7y ago
  I am the one saying that: for any Python packages in Ubuntu main, use them. Why worry about tracking security issues of all your dependencies, when you can have that done by distribution's security team (Ubuntu pledges to patch all security bugs).
  - Godel_unicode 7y ago
    Are you a Python developer? How do you deal with the Ubuntu versions being different than the PyPI versions?
    - necovek 7y ago
      Are you a Python developer?[1] How do you deal with your project depending on an older version of a package with pip? Basically, it's just like that (but instead of specifying your version in requires.txt/setup.py, you just install a package with a particular version). You've got an older library version that gets automatic security updates but does not break backwards compatibility (or it's a bug in the distro). Ubuntu/Debian packages manage dependencies as well, so for anything you install from the "archive" (distribution's repository), you get compatible dependencies as well, so you can further reduce number of packages you need to pull in with pip. It's a bit of a bother if you've got two sources of dependencies, but if you can get free security updates and no backwards compatibility breakage for 5 years (Ubuntu LTS guarantee for packages in main), it's a small price to pay (though it certainly depends on the use case as well). And luckily, Python + PyPI are _not_ JavaScript + NPM: with Python, you get a large standard library, and as you do not always need the latest and greatest of everything, you will not have hundreds, if not thousands of dependencies that you get with JS+NPM. [1] Your first tongue-in-cheek question is, imho, totally inappropriate. If I misunderstood and it was not meant in a sarcastic way, I apologize for attempting to return the favour. :) Even then, your second question is totally valid and should have been sufficient if you honestly care.

Godel_unicode 7y ago

Ctrl+f "iot" Ctrl+f "Mirai" Oh, it's a joke. Got it.

tfolbrecht 7y ago
Leaving your door wide open isn't anyone's fault but your own. All the configurations and procedures for secure devices were there but manufactures couldn't bother.

JJMcJ 7y ago

Outlook doesn't run on *nix systems.

ChrisCinelli 7y ago

Are we talking of just virus or other types of malware and rootkits? Not sure what "uncommon" means but I think https://news.ycombinator.com/item?id=20682546 https://news.ycombinator.com/item?id=20682546 already documented that successful attacks are not rare.

pjmlp 7y ago

On the other hand, "Unpatched KDE vulnerability disclosed on Twitter" https://www.zdnet.com/article/unpatched-kde-vulnerability-disclosed-on-twitter/ https://www.zdnet.com/article/unpatched-kde-vulnerability-di...