No immediate action recommended by our team
A new vulnerability could affect every system that remotely uses Linux as the core of its platform — that’s the message one security company would have you believe.
However, while this Grinch could potentially impact your Linux systems, you really have nothing to worry about if you are following standard best practices in maintaining your network and access protocols.
Red Hat even dove into the coverage of the issue yesterday afternoon to downplay some of the hyperbolic statements in the media that have been spurred by the original report. Red Hat issued an
official statement toward the end of the news-day cycle, talking about the Grinch issue that is making headlines, and clarified, in their words, “this report incorrectly classifies expected behavior as a security issue.”
Many security publications have reported on the seriousness of the Grinch vulnerability, and now there are a handful of
counterpoint articles circulating saying otherwise. Maybe it’s all semantics and whether you want to call it a vulnerability or not is up to you, either way it’s something you should be aware of if your system is built on Linux.
And, as one of our engineers pointed out, if your system is built on Linux, and you work with it in-depth every day, you should already know about this feature/vulnerability/whatever-it’s-being-called-today. For ease-of-reading, we are not going to put “vulnerability” inside quotes every time we refer to the issue in this article.
What is the Grinch? And should I be worried?
First things first: No, you should not be worried.
The vulnerability was discovered by Alert Logic, a security and cloud compliance company, and detailed in a blog
post titled “Don’t let the Grinch steal Christmas.” Alert Logic breaks down why they perceive this issue to be a vulnerability in Linux in this fairly detailed post.
Dubbed “Grinch,” in a nod to Theodore “Dr. Seuss” Geisel’s famous Christmas-stealing villain, Alert Logic maintains this vulnerability could impact any Linux-based system, from CMSs built on Linux, to enterprise servers, workstations, and even Android devices that are built on a version of the Linux kernel for their core operating system.
In Alert Logic’s report, the Grinch vulnerability is described as exploiting the Linux authorization system by allowing an attacker to self-promote their user level to gain privilege escalation. In other words, a malicious user could give themselves super user privileges, allowing them full root access admin rights.
In an article for
PC World, enterprise software news writer Joab Jackson cautions that an attacker could use the Grinch vulnerability as an access-point to gain access to other systems within the same network.
“With full root access, an attacker would be able to completely control a system,” Jackson writes, “including the ability to install programs, read data and use the machine as a launching point for compromising other systems.”
By using PolicyKit, a third-party software framework maintained by Red Hat, an admin — who has already been granted access to your systems — can bypass the need to login at root access. Computer World points out that PolicyKit is designed that way “to aid users in installing and running software packages.”
The danger lies in the potential for someone to install a software package containing malware at the root level. However, your IT and sysadmin team should know what they are installing.
Could a regular user escalate their privileges to root access? Possibly, but they would need an admin’s password in order to do it. And then you are outside the definition of “software vulnerability” and firmly into the territory of simply having strong password requirements. Anyone can alter virtually any system if they have all the passwords to that system — but if that happens, that doesn’t make it a “bug”; it just means you shouldn’t have your system password set to “password.”
While this issue may be news to many, it is something that has always been present in the PolicyKit framework. If you’re a Linux IT professional, this is not news to you.
Red Hat’s official statement on the issue is direct and to the point:
“Red Hat does not consider this to be a security issue or even a bug. This is the expected behavior of the PackageKit console client.”
So is it a vulnerability or not?
It depends on your definition of vulnerability.
If your IT team works with Linux on a daily basis, they are most likely aware of the ability to escalate privileges for root access through PolicyKit, and they probably agree with Red Hat that it is a design feature (and makes their job easier). If you are a c-level manager or non-die-hard Linux user, you may think that if there is any possible way for someone to elevate their privileges, then it is definitely a vulnerability.
It could be easy to argue that Alert Logic is trying to take a page out of Sucuri’s playbook — the company that first reported on Heartbleed — and “brand” this vulnerability the way Sucuri so successfully did for Heartbleed. And, of course, gain press and potentially new customers from doing so.
Multiple articles refer to Grinch as being as bad as Shellshock, Heartbleed, or the next terrible bug. It’s not. To be fair to Alert Logic, though, they never refer to any of those legitimately major security issues by name in their original
report. Yet it is hard not to feel like they are making a mountain out of a mole hill.
And, it is important to note that even Alert Logic states their team has not come across any examples of someone using the Grinch “vulnerability” in a real-world setting to compromise a Linux system.
That’s pretty safe odds for a feature that has been central to PolicyKit for years.
How do I protect myself?
Again, we want to emphasize that our engineers do not consider this to be a flaw that requires any immediate action on your part. And Red Hat does not consider it a bug or security issue at all.
If you are following normal password and sysadmin privilege best practices, you should be fine. You know who you are giving admin access to, and these should be coworkers, employees, developers, and system administrators that you trust to begin with.
Writing for
Threat Stack, Jen Andre sums up the issue quite well:
“PolicyKit is working as designed, because by design it’s circumventing authentication mechanisms built into Linux for the sake of usability. That said, it’s important to be aware of the risks you are introducing and the tradeoffs of taking security shortcuts for convenience in the software you deploy on your Linux workstations and servers.”
The best defense is to remain vigilant of who has admin privileges on your system, and maintain standard sysadmin best practices. Be aware of what tradeoffs your are making for ease and usability. And don’t give admin access to the guy who is constantly installing software full of malware on his office PC (every large office has one of those guys).
Standard best practices apply: Be aware of who you are giving access rights to, maintain strong passwords, and if someone leaves your organization (be it on good or bad terms), remove their access credentials.
------
Update, 12/19/2014:
Article updated for clarity, to reflect official statement from Red Hat, and to include quotes from Threat Stack.
------
Works Cited / For Further Reading:
Linux ‘Grinch’ vulnerability could put a hole in your security stocking. (
PCWorld)
Grinch root access vulnerability impacts all Linux platforms. (
TechWorm)
Oh, the Who-manity: ‘Grinch’ security bug wreaks havoc on Linux. (
Digital Trends)
The Linux ‘Grinch’ Vulnerability: Separating Fact from FUD. (
Threat Stack)
Does the ‘Grinch’ issue affect Red Hat Enterprise Linux? (
Red Hat)
Published: December 18, 2014 at 2:44 PM