Why GNU/Linux Viruses Are Fairly Uncommon
gnu.org
gnu.org
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.
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].
(edit) An example of binary packages in Nixpkgs: https://github.com/NixOS/nixpkgs/blob/master/pkgs/developmen...
Of course, you loose some Nix advantages. But it's a great way to get a regular Unix environment for one-off things or desperate cases.
Users' metal models of trustworthiness don't track very well the actual scrutiny software is subjected to. This might be a problem with any distribution system.
I mean, I agree in principle that it's a hard problem. But the actual solution we've landed on in the Linux world seems like... well, just not really the first thing we should be worried about.
It's a tough balancing act.
A "sketchy" web site is the one festered with ads, pop-ups, seemingly modern-looking but with no actual content or with dead links...
This is incorrect. It wouldn't make a single difference.
If somebody had stolen the signing keys and could do a https://www.cloudflare.com/learning/security/glossary/bgp-hi... there will be no trace.
We know how to publish the input and output hashes. It's one of the use cases for a global ledger. Using CF's trust root would be pointless.
None of those package repositories are maintained by a limited set of curators.
Debian's repositories and other linux distributions repositories are curated.
Uploading a malicious package to npm is as easy as typing 'npm publish'.
> "reflections on trusting trust"
It's a very useful piece of art and a thought experiment.
In practice, it's not interesting for the average package. Very few packages are self-hosting and in such a position to leverage that sort of clever trickery.
A good debian maintainer will also review code of their packages and make sure such trickery has no chance to be afood (e.g. by preventing a gem from downloading a custom ruby interpreter to bootstrap itself, but rather manually bootstrapping up themselves).
> None of those package repositories are maintained by a limited set of curators.
It's always interesting to me how few people seemingly know this. Python package maintainers realize how easy it is to add packages to PyPI, but many admins and even SOC operators inherently trust it because they think that it "must be reviewed by someone".
Also, there have been plenty of security issues with Ubuntu and Debian: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue52#Commu... https://www.linuxinsider.com/story/32240.html
Also there have been bugs in apt: https://www.fosslinux.com/6167/massive-security-bug-found-in...
Also the official ISO from the Mint website: https://arstechnica.com/information-technology/2016/02/linux...
Also the AUR malware mentioned on thread: https://www.bleepingcomputer.com/news/security/malware-found...
Also the kernel.org compromise: https://www.zdnet.com/article/linux-kernel-source-code-repos...
Edit: let's throw in the redhat ceph intrusion while we're at it (note that this includes InkTank). https://www.zdnet.com/article/red-hats-ceph-and-inktank-code...
There's a really fascinating project by the authors of TUF called in-toto[1] that addresses exactly this problem.
And nobody says that not doing anything is ok, but please do it properly, do some basic threat modeling first.
P.S. I'm not against reproducible builds, I think they are useful for many things, just not for security. They may even let us do decentralized trustless peer-to-peer build system someday.
Therefore, in my view it provides a smallish real benefit and a large moral hazard.
Except for that time that Debian developers "knowing better" completely neutered most cryptography on all updated Debian systems[1]:
>Affected keys include SSH keys, OpenVPN keys, DNSSEC keys, and key material for use in X.509 certificates and session keys used in SSL/TLS connections. Keys generated with GnuPG or GNUTLS are not affected, though.
Massive, rapid key rotation schemes had do be implemented to cover their screwup because all keys were trivially enumerable, to the point where all affected keys were blacklisted[2].
[1] https://www.debian.org/security/2008/dsa-1571
[2] https://security.stackexchange.com/questions/3422/what-is-th...
Ultimately the problem doesn't have a good solution right now. Reproducible builds are a part of the solution, as is making it harder for malicious debian packagers to upload infected binaries. You need to protect the entire supply chain.
I've heard far more stories about malware making it into developer repos (usually inadvertently) than making it to package repos. I suspect it's partially the relative areas of focus of developers vs package maintainers and partially just having another set of eyes at least glancing at what's going on.
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.
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.
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.
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.
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.
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...
Basically, the level of diversity in the ecosystem, while part of a reason for less widespread acceptance, also discourages any mainstream attacks.
Some skiddies use Kali Linux but only because they managed to follow step-by-step instructions on YouTube without which they're lost.
[1] https://www.symantec.com/security-center/writeup/2010-071400...
[2] https://www.computerworld.com/article/2934593/duqu-2-0-kaspe...
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
Let's see some of your code.
...although market share certainly also plays a part.
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.
But solutions like selinux, apparmor, and tomoyo are built on the premise that it's the user, administrator, or packager best positioned. But this is a false premise. These people are the worst positioned to understand which privileges are needed, when they're needed, and how to constrain them. They're certainly not well acquainted with the software and how it operates. The only tools at their disposal are external policy mechanisms which are often extremely difficult and complex to use to achieve the desired level of access with the external environment. And they're incapable of refactoring the target software to improve the situation. It shouldn't be any surprise, then, why these resources are underutilized.
seccomp is an improvement but it's much too low-level. Other than the obvious issues that a simplistic syscall filtering mechanisms is too brittle, seccomp 1) doesn't support file paths, and 2) the inheritance semantics makes it nigh impossible to refactor existing code which invokes other programs while 3) also setting a high bar of minimal complexity for new code. Again, no surprise why this resource is underutilized.
This is why OpenBSD's pledge and unveil are infinitely easier tools for securing programs. They were conceived and refined with the goal of making it easy to lock down programs, not to maximize purely abstract requirements like fine-grained control or administrator flexibility. And in any event tools like file permissions and other access controls remain readily available to augment the built-in privilege restraints.
Android is a poor example, especially for server systems, because Android programs don't need to interoperate directly with each other. Whereas on server systems the degrees of interoperability and dependence of various pieces of software are extremely complex and varying. One alternative, forcing everyone to write microservices, at best simply shifts the burden around; it doesn't help to minimize that burden, nor does it permit us to incrementally and organically improve the situation.
The problem is that it's much more difficult to write software that way, which is why few people do it. And it doesn't actually solve the problem of trust because it's exceptionally difficult to prove that those rules capture and constrain the most security-relevant aspects of the program, so you're back at square one in terms of trusting the developer and their skill.
Your argument makes the most sense if security were simply a matter of enumerating filesystem and syscall access. But it's rarely that easy. Usually you need certain kinds of access at various stages of the programs, or the types of access required are a function of the inputs to the program--e.g. the files specified on the command-line or the configuration file. Handling these requirements in the most appropriate ways tends to devolve to a matter of writing ad hoc code in the context of the peculiarities of the program architecture. Declarative solutions divorced from the structure of the code don't work well. What's most important are the time, place, and manner of constraining particular privileges, as opposed to merely identifying all the privileges and switching from "insecure" to "secure" at a single point in the application.
The person best positioned to lock down a program is the maintainer of the platform on which all the other programs run.
In fact the individual program developers should strive not only to ignore security altogether, but to develop a common set of tools that delivers arbitrary third-party code to the user's machine. This makes security theater unlikely as any given developer will only have expertise in their program proper and not in the security of their program plus the arbitrary third-party code. This also ensures maximum velocity of domain-appropriate development and focuses on ease of program installation-- the exact opposite of the problem being parodied in the article.
That velocity will rapidly grow the platform. This neutralizes any efforts to thwart progress through ad hoc program lockdown as futile. At the same time it puts massive pressure on the platform itself to gracefully handle misbehaving programs lest systemic insecurity decrease installation velocity.
Thus you get a system where arbitrary programs may be installed as quickly as possible with a security model that works even if 100% of the programs installed are malicious.
The cost is that arbitrary user data is exfiltrated during most program installations and runtimes (but that is a minor implementation detail).
I’ve been hoping that we’ll get there for a couple decades but SELinux was quite the reminder that when faced with work a lot of people will just turn off a security measure and rant about it rather than contributing.
They will not take your ticket until you turn it off and try again, and to your great surprise they will not be sharing their favourite selinux tagging configs with you.
So in the end, what can be protected with a decent SElinux config will be that statically generated catblogs-r-us.io site you run, but not the company financial database. "Priority inversion", or something to that effect.
Not sure what "uncommon" means but I think https://news.ycombinator.com/item?id=20682546 already documented that successful attacks are not rare.
"Unpatched KDE vulnerability disclosed on Twitter"
https://www.zdnet.com/article/unpatched-kde-vulnerability-di...
To say nothing of docker base images and popular docker containers...
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).
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.
The Ubuntu versions of Flask, pymongo, and elastic are all out of date in the 18.04 (LTS) repos. Many are also out of date (although not as much) in all Canonical repos. Flask at least is missing security patches (bad) or the version number is misleading because they silently backported the fix (almost worse) in LTS. I've had backwards compatibility broken repeatedly by upgrading Canonical LTS versions of elastic and also numpy. It's actually happened so often that the set of tests in my CI that test with Ubuntu packages is named "what did they break this time" and can't fail the build.
I asked if you're a Python developer as it's my experience that sysadmins often think about this problem from the perspective of "use the repos, one less thing for me to manage" and developers think of it from the perspective of "I need the version of Flask that comes from PyPI, since that's what other devs will/have use(d)". I have very seldom encountered Python developers who use the distro-provided packages, and usually when I have it's because they didn't know about pip/PyPI. I apologise that the ambiguity caused offense, words are hard on computers :partyparrot:
Well that's exactly the problem I run into with most packages (even outside of programming dependencies like Python libraries), but if ./configure, make, make install fails for any reason, the first google hit on the error message is "why are you trying to install this from source? Use the repos, that's what they're for"...
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.
Oh, it's a joke. Got it.