There seems to be a recurring phenomenon in the technology press, where any trojan that affects Linux or Macs becomes front page news. On the other hand, trojans that affect Windows are mostly ignored, perhaps because this is considered to be the normal state of affairs.
There are two common statements made in the discussions of these rare events:
- No operating system will ever be secure from Trojans.
- Linux/Mac only have fewer viruses because no one uses them.
The first statement is almost correct, whereas the second one is a flat out myth in my opinion. Let me explain, and I’ll listen if you still disagree after reading the following in its entirety.
1. No operating system will ever be totally secure from Trojans… but only as long as they allow anyone to write un-sandboxed software for it.
If users have the ability to run anything, they can also install anything they are tricked into running. Anyone can trick people into running a script to format their drive on any operating system… if the user is gullible enough to click through the prompts and enter the admin password. There is only one way around this: Don’t let the users run anything they want!
Take the XBox 360, for example. It’s actually a full fledged computer, with huge marketshare, running a Microsoftoperating system. Yet, with all these compounding points of vulnerability it has no known trojans floating around in the wild. Why? Because full system access is restricted to established companies with a clear chain of responsibility. Users can’t run unsigned software on the system, and even with XNA indie devs get only crippled sandbox access.
Apple’s taking this same approach with their Mac App Store. Apps delivered through the store must run in a sandboxed environment. Microsoft is also doing the same thing with their Windows 8 app store. If devs want to create their own apps with full system access, they won’t be able to play in these ecosystems. Of course, Apple and Microsoft still let their own apps, the ones devs will be competing against, run with full system access (look for anti-trust lawsuits here later).
After “Secure Boot” (i.e. restricted boot) is prevalent, and the operating systems are locked down to not allow anyone to sideload any non-OEM software, we could be completely free of trojans and viruses. That might be good for the average level of system security, but it would be a horrible blow to innovation, competition, and the indie/hobbyist developers.
2. Does system adoption directly correlate to an increased likelihood of viruses / trojans? No. Not in my opinion. There are many reasons Linux systems have fewer viruses, and market share is only one factor. I’ll address these from the Linux perspective. On the Mac side of things, several of the points don’t apply, as Apple has taken free software and brought it into its closed, walled garden.
A huge percentage of Linux software is installed from signed repositories:
1) The downloads themselves are cryptographically signed.
When a user downloads software and drivers for Windows, they’re typically doing it from many different websites on the internet, and trusting that the admins of every one of those sites is competent and has done their due diligence to implement the proper security. At the time of the download, there is no check to verify that the file the user is getting was actually created by a trusted source (and not a hacker that has pwn’d the site) or is being served by some man in the middle.
On Linux, with few exceptions, the hardware drivers are also included with the kernel. As for software, users typically download that from only a limited set of distro-owned repositories. All software is delivered in installation packages that are cryptographically signed and those signatures are checked at installation time. If a package has been replaced with a hacked version and was therefore not signed with a trusted cert, users will get a big fat error warning them of that.
2) The repositories (“repos”, for short) keep all of the software up to date, not just the kernel or things made by the distro creator.
When a security flaw is found in a Windows application, the vendor will usually put an update on their website. With the exception of a few MS partners that have their drivers on Windows Update, it is up to the user to go discover that and update their software.
On Linux, security issues can be raised and patches created by any entity, not just the original software author. These updates are applied and pushed into the repos for all applications. Users become aware of it almost immediately – as most distros check regularly and prompt users to click a button to update the app.
More than 99% of the software is open source:
It’s not unreasonable to wonder “How does having the source code available for any nefarious hackers to peruse, make software more secure?”. The answer can be summed up in something Eric Raymond said about 13 years ago: “Given enough eyeballs, all bugs are shallow”.
In the Windows world, we are trusting the vendor to have done the due diligence to investigate their own code for buffer overflows and other exploitable flaws. No one else has seen the code, so automated software source scans/reviews are impossible.
In the Linux world, there are dozens of companies and security researchers that constantly run scans over the entire ecosystem of software in their repositories – not just the software they’ve developed themselves.
Open source code also tends to lend itself to re-use. In the Linux world, devs are not even going to be tempted to go implementing a security-centric feature like SSL libraries themselves, when there are perfectly working ones available for their open source apps to use for free. Having that code open, such that they can step their debugger into and fix any underlying bugs themselves, is a great asset.
On Windows, there’s a reinforcement of the “not invented here” mindset as apps re-implement the wheel for their closed-source project in order to avoid paying other proprietary software developers for a decently vetted utility library. A Linux distribution (distro) is more than just Linux. Linux is the kernel, and many of the other components are part of the GNU environment. Common packages (ex. Apache web server) are used in other open source operating systems, including BSD. And, in case you didn’t know, the BSD guys are kind of nuts about security. So, these components have been scrutinized with a hundred fine toothed combs.
Combine the open-source nature of Linux with the repository system used for software distribution, and anyone can see why Linux exploits have shockingly short lifespans: When a 0-day exploit is found, the geeks rush to see who can come up with the best fix (since everyone has access to the source), and it’s pushed into the repos and out to everyone immediately.
Linux distros are diverse:
Successful trojans rely on some bug or flaw to exist, in order to gain elevated privileges. (I know: duh, right?) On Windows, malware authors can be pretty sure that the kernel bug that exists on their Windows 7 box also exists on your Windows 7 box (if both are up to date).
On Linux, these would-be-hackers would be extremely lucky if two different distros are running the same kernel — much less the same patch-sets — and maybe if they were built with the same compile options. The same bugs do not exist everywhere, which makes Linux a less viable target. It’s still an attractive target (since a large percentage of the always-on servers on the Internet run it), it’s just not as easily exploited at the OS level.
So, the conclusion is obvious: Even if they had the exact same market share, it is extremely unlikely that Linux would ever have the same number of exploits as we see in closed-source ecosystems such as Windows. This is a direct result of the open nature, which allows for innumerable companies and hobbyists to access and maintain all portions of the system–a feature that simply can’t be replicated in proprietary operating systems. Linux will always have more eyes looking through the code to make it secure, than there are eyes looking through the code to exploit it.