Posted on 12/18/2014 2:47:48 PM PST by zeugma
This primarily affects Linux/Unix systems that have local users.
Bottom Line: Local users in the wheel group can install software (and possibly do other things) without authentication checks. If you have a webserver (or process that runs under one) that runs as a user in the wheel group, they can do bad things.
On my system as an unprivileged user, I was able to validate this.
$ /usr/bin/pkcon install CTL
Resolving [=========================]
Querying [=========================]
Testing changes [=========================]
Finished [=========================]
Installing [=========================]
Resolving dependencies [=========================]
Downloading packages [=========================]
Testing changes [=========================]
Installing packages [=========================]
Finished [=========================]
That should NOT have been possible without at least prompting for a password. I don't know the full ramifications of this. As it said in the article, most times, if you are a primary user, you will be added to wheel by default. Wheel users are generally given access to sudo, so they can do administrative functions. In general, it's what you want. However, this particular bug allows people to get around the fact that you're normally prompted with a password if you want to execute any of those functions. In the example above I shouldn't have been able to install that package. I haven't tested it yet for localinstalls (the example pulls a program from a repo), but I'd be surprised if it didn't allow it. What that means is that you can create a local package that is SUID, and install it without passwords, then use that SUID program to further compromise the system (or have it replace a standard binary I'd suspect).
Lots of corporate systems use the wheel group to allocate sudo permissions. It might make sense to not to that until this issue can be fixed. It's probably a better idea to use finer-grained controls to manage sudo anyway, such as other groups, and specific command allows/denys.
If you don't have local users other than yourself, it's not such a big deal, but I question whether or not someone could take advantage of a browser issue to do the same thing. That might make it possible to silently install malware. Bad. Bad.
Other thoughts are appreciated.
I'll be looking at this more later this evening as well.
Shadowace, Fedora definitely impacted (I'm running F20)
Is this Kaspersky trying to sell it’s crappy anti virus again
From /. user Jesse McDonald:
The problem is with the part of their PackageKit configuration which apparently allows administrators to install software without authenticating first. It’s rather like putting the line
%wheel ALL = (root) NOPASSWD: /usr/bin/yum
in your sudoers file. PolicyKit can also be configured to require authentication for each action, it just wasn’t set up that way on their system. There’s nothing wrong with identifying the members of the “wheel” group as administrators, but the policies should be configured such that administrators need to authenticate prior to installing new software. (This seems to be the default on CentOS 6.4; I have no idea what they were running. “pkcon install” does not work by default here without authentication, even for a member of the “wheel” group.)
In layman’s terms, this can occur on “some” misconfigured systems due to PEBKAC error. Problem Exists Between Keyboard And Chair. Also see: BS and FUD.
Just upgraded from Linux Mint 17 to 17.1.
Love this computer. Linux, running 1 64bit Athlon and 2gb of Ram, does circles around any of my windoze machines with twice the proc and twice the ram.
But there’s no wheel in /etc/group. In that way and several other ways, the piece is FUD. Don’t add a wheel, and don’t misconfigure the system.
IIRC, the author was a Red Hat user but submitted no bug report to Red Hat at the time.
Critical Git Security Vulnerability Announced
Github has announced a security vulnerability and has encourage users to update their Git clients as soon as possible. The blog post reads in part: "A critical Git security vulnerability has been announced today, affecting all versions of the official Git client and all related software that interacts with Git repositories, including GitHub for Windows and GitHub for Mac. Because this is a client-side only vulnerability, github.com and GitHub Enterprise are not directly affected. The vulnerability concerns Git and Git-compatible clients that access Git repositories in a case-insensitive or case-normalizing filesystem.
No. As I reported in my comments, I was able to replicate this priviledge escalation myself.
I wouldn't call it PEBKAC, as I quite purposefully do NOT use nopasswd in sudoers. I used to a long time ago, but have gotten so that I actually LIKE the password confirmation not having it provides.
I'm running a Fedora 20 installation (KDE spin), and generally know what I'm doing.
I was able to replicate this issue. I'll be testing a Mint installation, and will be running the same tests against virgin default installs of some ISOs I have around here in the next few days to see what is/is not affected. I have a feeling that the actual issue comes from one of the /etc/polkit.d config settings. I haven't looked hard at polkit configs before, but it looks like I have a reason to now.
From what I've seen Fedora and Mint (two very different distros with completely separate lineages) both create wheel users by default through the normal install process. This isn't a user configuration problem. As I said in the previous post, I suspect it's a polkit configuration issue.
I think I switched over to using wheel for sudoer access on Fedora 18 or so. Prior to that, I used to just go in and visudo to add my user to the file manually. Looks like that might be the way to go in the future.
Zeugma, and all, I do not think this is anything to get upset over. It apparently is mostly an issue of misconfiguration of PolKit in some Linux installs.
I do not believe this would be an issue on a standard Mac OS X install. Root is not enabled by default, and users are not assigned to Wheel. Super User is one more level above Administrator on a Mac for this reason and requires another user name and password to be activated. In addition, PolKit is not installed by default on OS X Macs. . .
I have been looking into this and nowhere do I see it extended into UNIX.
RedHat has just released a statement that this is NOT a vulnerability but an intended "feature" of the way that Wheel works. A remote exploit is not possible. RedHat claims that it requires physical possession of the computer. As reported in CIO Magazine:
But the system was designed to work that way—in other words, grinch is not a bug but a feature, according to Red Hat.“If you are trusting users to install any software on your system without a password by using software that leverages Policykit, you are inherently bypassing the authentication and access control built into Linux,” wrote Jen Andre, cofounder of the Threat Stack security monitoring firm, in a blog post on the topic.
Even though the grinch behavior is intended, it still can be abused or modified to compromise systems, Alert Logic senior security researcher Tyler Bourland wrote in an email to the IDG News Service.
“The issue here is that there is a way to open up the surface area to attacks,” Bourland wrote. “If installing packages worked like every other operation, such as removing packages or adding repositories, and always asked for a password, then this wouldn’t have the abuse potential we’ve identified.”Nonetheless, the use of Polkit has some severe limitations for the would-be attacker, Andre said in an interview.
The attacker would need to have physical access to the Linux computer and have to interact with the machine through an attached keyboard and mouse. If the attacker had this level of access, it would be just as easy to reboot the machine into a recovery mode and access the data and programs that way, Andre noted.
Also, Polkit is not installed by default on all Linux machines—in fact, the primary use case is for workstations that have graphical desktop interfaces, which themselves constitute a small percentage of Linux machines running today, Andre said. . .
. . . Even Tyler, the co-author of the original report, seems to admit that grinch is not so severe.
Grinch is a “surface opening stager and by itself nothing much,” Bourland wrote, referring to how an attacker would need additional vulnerabilities to use in conjunction with grinch to stage an attack,in an email on the Open Source Security mailing list.
At this point, i would not be worried about it. I hope this helps.
I thought the modern Debian GNU/Linux systems do not support the Wheel group?
Debian doesn’t use wheel. The above seems to have to do with Redhat-based distributions.
Also, ‘wheel’ is traditionally a BSD thing. Surprised to see it is still around in any Linux distribution in 2014.
Thanks. The initial reports are often worse than it appears once you have time to go through and look at all the implications. What surprised me was how easy this was to validate on my system. That and the fact that I don't really know much at all about polkit and its config files don't really help at all. I plan to poke around a bit this weekend to make sure they are right about it being a local-only exploit. If that's true, then it really puts it into a lower level threat, because with physical access, all bets are off.
Good to know it's not something that will show up in genuine Unix systems, including OSX as well.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.