People are often surprised when they discover that I regard Linux as an insecure operating system. Let's see why.
<note warning>TL;DR
</note>
RCE is the worst bug that can happen to an operating system. Let's see some of the bugs that allowed attacker to execute arbitrary code on your machine. The list is not comprehensive, it is just to illustrate the situation.
I will probably stop updating this, as it is getting long, and it seems to fulfill the intended illustration purposes and it is now just copy-pasting debian-security mailing list, so subscribe that if you want further updates.
Who: Anyone who can send you a DHCP offer (e.g. ISP, attacker on shared WiFi etc.)
Discoverability: trivial (notice that function in variable gets executed on Bash respawn + notice that dhclient runs Bash scripts with environment variables)
Availability: 1989 - 2014
Who: anyone who can get access to your SSH public key or anyone who can try 2^14 SSH handshakes with your server.
Discoverability: trivial (notice SSH client does not scream after keys on server are changed)
Availability: 2006 - 2008
Who: anyone who can make you open a PNG image (webpage, e-mail, instant message avatar, file browser previews…)
Discoverability: hard (classic buffer overflow + bypassing standard security measures like ASLR and NX)
Availability: 2001 - 2015
Who: anyone who can make you open a compressed file (webpage, e-mail…)
Discoverability: hard (classic buffer overflow + bypassing standard security measures like ASLR and NX)
Availability: at least 2012 - 2015
Who: anyone who can send you a DNS reply (your ISP, shared WiFi…)
Discoverability: hard (classic buffer overflow + bypassing standard security measures like ASLR and NX)
Availability: 2009 - 2016
====
Other fun bugs:
Who: Anyone who can send you a video file (webpage, mail, flash drive...)
Discoverability: rather easy
Availability: unknown, probably several years before 2016
Remarks: This and the “Stardict is sending passowrds to China” issue described here demonstrate the urgent need for application firewalls known from other operating systems, which are not available in Linux (some out-of-tree kernel patches exist).
Who: any SSH server you connect to.
Discoverability: probably hard
Availability: 2010 - 2016
As you can see, Linux system with a standard set of most popular applications was exploitable all the time. And as nothing has changed, I believe it is exploitable right now. Many security researchers are right now hunting for security bugs not to report them, but to sell them to blackhats, governments and companies like HackingTeam. And they are successful.
Workaround: run exploitable (read: all) applications in sandboxes. Unfortunately sandboxes are not implemented in Linux either (you can use SELinux or separate user, but you still face local privilege escalation exploits like CVE-2008-0600 and no isolation in X11 server). You can use user-friendly virtualization like QubesOS and hope there are not too many bugs like CVE-2015-3456, CVE-2015-5154 or CVE-2015-7835 that allow virtual-machine escape. Oh god, I am running this page for less than a year and there have already been three?! It looks like you have no chance to get a secure system…
Several other bugs show that Linux was not designed with security in mind. What does that mean? For example in railway security, if something fails, the failure must lead into a “more secure” state. For example failed traffic control leads to stopped train. Not in Linux.
Note that these bugs are given only as an example - fixing them is not a solution. They demonstrate that the entire design/ecosystem is just plain wrong. Fix them and another will be discovered shortly. The only solution is to change the design rules from the roots.
One would expect that crash of a screen locker will lead to an ununlockable session. Nope, it leads to fully unlocked session without any password entered.
Reported 2006, not patched as of 2015, CVE-2015-8025 from October 2015, CVE-2015-7496 from November 2015 - yes, again and again, 9 years, and the critical bug is still unpatched! \o/
Note: KDE 5 probably implemented it the right way, finally! Well, not.
Another example of fail-deadly (instead of fail-safe) is configuration of Tor. This is usually done in a way that we set proxy to use it and optionally create an user/virtual machine that can connect only to this proxy (another fail-deadly case, if these firewall rules fail, they get exposed to the open internet instead of losing connection). Unfortunately, I personally experienced an Privoxy update that replaced simply /etc/privoxy/config with default configuration without asking. In default configuration, all connections are just proxied to the internet without Tor.
There is absolutely no protection of the clipboard. Accidental pastes of confidential information into webpages or IRC client happen without warning. Right design would be to flag applications with various security levels and require authorization to transfer clipboard from the more secure to the less secure.
I have configured my system to automatically discard clipboard contents after two minutes. It does not completely prevent such leaks, but is sufficient in most cases.
Okay, so let's implement a warning window. But please don't do it as a pop-up that has some default action button selected! I'm typing on the keyboard and right before I'm about to hit specebar, the popup shows. And I activate the button with spacebar without noticing what was the message!
Security timeouts like in Firefox should be present.
By default, the Terminator terminal emulator has “Alt+A” bound to “broadcast keystrokes to all terminals”. This means that you are one key from a disaster (typing your passwords, e-mails, commands… into other terminals). No indication is displayed when this feature is activated. (yeah, I just accidentally pasted several fortunately non-confidential lines into IRC this way)
Another example of opaque design where user can be tricked into accidentally executing malicious code is a bug that existed in older Debian versions. Its manifestation follows:
Another similar bug was seen being exploited in the wild: the target user was known to use Midnight Commander (mc). When file.pdf was selected and Enter pressed, the PDF viewer was launched (similar with JPG, ODT etc.). However, if the file had eXecutable bit set, pressing Enter would execute it using the system default interpreter (which would of course fail in case of a standard PDF file). So an ext2-formatted flash drive (to allow us to set permissions, which won't be possible on vfat) containing a crafted PDF file was given to the user claiming interesting documents are on it. Once the file was “opened”, we got shell on the user's machine.
Both users affected by these bugs were long-term professional Linux users, so it's not the case of some socially-engineered BFU.
Files from untrusted sources should have a flag set. They should not be run without a warning.
Privacy policy and information management enforced on applications are simply missing. One would say that spying is domain of proprietary applications working for their vendor, but in Linux we see open source applications can be high-quality spies too. This can be attributed to programmers that simply don't care or in more paranoid version to intentional malice.
An application should never! send anything to the network without an explicit user consent. This simply does not apply in Linux. Many, many, many popular applications are listening to the world, checking updates, sending your traffic etc. by default and sometimes even without any settings to stop!
There is no application firewall available for Linux and iptables probably don't allow you to match by executable name.
<note tip>There is a kernel patch for this: https://github.com/Douane/Douane</note>
Workaround: run it under another user or virtual machine and firewall it.