Like all operating systems, Linux isn’t perfectly secure. Nothing is. As security guru, Bruce Schneier said, “Security is a process, not a product.” It’s just that, generally speaking, Linux is more secure than its competitors. You couldn’t tell that from recent headlines which harp on how insecure Linux is. But, if you take a closer look, you’ll find most — not all, but most — of these stories are bogus.
For instance, Boothole sounded downright scary. You could get root access on any system! Oh no! Look again. The group which discovered it comes right out and says an attacker needs admin access in order for their exploit to do its dirty work.
Friends, if someone has root access to your system, you already have real trouble. Remember what I said about Linux not being perfect? Here’s an example. The initial problem was real, albeit only really dangerous to an already hacked system. But several Linux distributors botched the initial fix so their systems wouldn’t boot. That’s bad.
Sometimes fixing something in a hurry can make matters worse and that’s what happened here.
In another recent case, the FBI and NSA released a security alert about Russian malware, Drovorub. This program uses unsigned Linux kernel modules to attack systems. True, as McAfee CTO, Steve Grobman said, “The United States is a target-rich environment for potential cyber-attacks,” but is production Linux run by anyone with a clue really in danger from it?
I don’t think so.
First, this malware can only work on Linux distributions running the Linux 3.6.x kernel or earlier. Guess what? The Linux 3.6 kernel was released eight-years ago.
I suppose if you’re still running the obsolete Red Hat Enterprise Linux (RHEL) 6 you might have to worry. Of course, the fix for signing Linux kernel modules has been available for RHEL 6 since 2012. Besides, most people are using Linux distros that are a wee bit newer than that.
In fact, let’s make a little list of the top production Linux distros:
- CentOS/RHEL 7 started with kernel 3.10.
- Debian 8 started with kernel 3.16.
- Ubuntu 13.04 started with kernel 3.8.
- SUSE Linux 12.3 started with kernel 3.7.10.
All these years-old distros started life immune to this attack. All recent Linux versions are invulnerable to this malware.
But, wait! There’s more. And this is the really annoying bit. Let’s say you are still running the no longer supported Ubuntu 12.04, which is theoretically vulnerable. So what. As Red Hat’s security team points out, “attackers [must] gain root privileges using another vulnerability before successful installation.”
Once more for Linux to be compromised — for your system to get a dose of Drovorub — your system already had to be completely compromised. If an attacker already has root access, you are totally hosed.
Yes, there’s a security problem here, but it’s not a technical one. In the tech support business we like to call this kind of trouble: Problem Exists Between keyboard And chair (PEBKAC). So yes, if you have a complete idiot as a system administrator, you’ve got real trouble, but you can’t blame Linux for it.
Let’s look at another example: Doki, a new backdoor trojan. This time around, although described by many as a Linux problem, it’s not. It can only successfully attack Linux systems when whoever set up the Docker containers exposed the management interface’s application programming interface (API) on the internet.
That’s dumb, but dumber still is that for it to get you, your server’s firewall must be set to open up port 2375. Here’s a lesson from networking security 101: Block all ports except the ones you must have open. And, while you’re at it, set your firewall to reject all incoming connections that are not in response to outbound requests. If your administrator hasn’t already done this, they’re incompetent.
Finally, let’s consider the recent sudo command problem. This sudo security vulnerability was real, it’s since been patched, but it requires, again, a case of PEBKAC to work. In this case, you had to misconfigure sudo’s set up so that any user could theoretically run sudo. Once again, if you already have an insecure system, it can always get worse.
There’s a common theme here. The problems often aren’t with Linux. The problems are with totally incompetent administrators. And, when I say “totally incompetent,” that’s exactly what I mean. We’re not talking subtle, small mistakes that anyone might make. We’re talking fundamental blunders.
Whether you’re running Windows Server, Linux, NetBSD, whatever on your mission-critical systems, if you utterly fail at security, it doesn’t matter how “secure” your operating system is. It’s like leaving your car keys in an unlocked car, your system will be hacked, your car will be stolen.
So, enough with blaming Linux. Let’s blame the real problem: Simple system administrator incompetence.