Posted on 12/18/2014 2:47:48 PM PST by zeugma
December 16, 2014
Blog Contributions by Tyler Borland, Sr. Security Researcher and Stephen Coty, Chief Security Evangelist, Alert Logic
Since we are in the thick of the holiday season, we are analyzing which operating systems support the needs of e-commerce and brick and mortar retail shops. Due to the lower cost of ownership and efficiencies such as a non-resource heavy operating system that allow for applications to run more smoothly, we found that Linux is dominating when it comes to e-commerce site deployment.
According to a 2013 report from W3Tech, approximately 65% of all web servers on the Internet utilize a Unix/Linux based operating system.[1] We uncovered a bug that impacts all Linux platforms, including mobile devices, and we’re calling it “grinch.” Fortunately, there are ways to detect the exploit of this bug in your environment until a patch is released.
A Change in the Landscape
In August of this year, we released a blog that details the exploitation of the new logging system (JournalD) to hijack terminal sessions for remote execute commands.
We dove further into the Linux platform and discovered grinch, which exists in the new authorization system that allows privilege escalation through wheel.
Wheel is a special user group that controls access to the su command, which allows a user to masquerade as another user. When a Linux system is built, the default user is assigned to the wheel group that allows for administrative task execution within the system. For example, if the file is owned by user XYZ and group wheel, it will run as XYZ:wheel, no matter who executes the file.
New Linux ecosystems attempt to implement new methods of authentication and authorization to remove a large assortment of vulnerability vectors introduced with random setuid binaries. While we can look at capabilities as a part of the cure, Policy Kit (Polkit) is one of the main drivers for straying away from setuid binaries. A simple ‘man polkit’ allows us to read deeply into the new authorization API for privileged programs.
Background on Polkit
Most privileged system operations are already controlled by Polkit, a well-established, fine-grained, and (possibly) network-transparent service for managing privileged operations by ordinary users.
When talking about Polkit, we need to understand we are no longer dealing with a single daemon. Instead, we are dealing with a whole new authority management wrapped in a setuid root daemon that gives us access to new tools and ways of doing things. Each piece of this ecosystem exposes possible vulnerabilities through backend D-Bus implementation, the front end Polkit daemon, or even userland tools that use Polkit for privilege authorization. This ecosystem allows us to achieve local privilege escalation in the modern era. One set of tools is PackageKit.
PackageKit
PackageKit is a set of tools that allows an abstraction layer (over D-BUS) to work across package management systems and architectures. PackageKit attempts to make the management process easier to navigate in the face of a multitude of different package management ecosystems like APT, Yum, pacman, and others. PackageKit uses PolKit in the backend for user authentication. So, in Fedora, while DNF or Yum may not allow access to specific user(s) to install packages, PolKit rules are separate and may allow the action, which is something that will be addressed with PKCon. For now, only an understanding of the default rule layout is needed.
PolKit Authorization Rules
On a default setup, authorization rule files are kept in /etc/polkit-1/ and /usr/share/polkit-1/. These are sorted by the basename of the file (10- before 20-) and /etc/ will overrule /us/share/. With an ls -la on /etc/plkit-1/, we can see:
ls -lah
total 28K
drwxr-xr-x. 5 root root 4.0K Dec 6 2013 .
drwxr-xr-x. 142 root root 12K Nov 16 10:18 ..
drwxr-x—. 7 root polkitd 4.0K Dec 11 2013 localauthority
drwxr-xr-x. 2 root root 4.0K Aug 4 2013 localauthority.conf.d
drwx——. 2 polkitd root 4.0K Oct 3 12:15 rules.d
A couple of polkitd uid/gid permissions are seen, but mostly the permissions are root owned. Inside these folders, the files are written in simple JavaScript to manage Polkit privileges. So, if we wanted to change these permissions outside of an arbitrary file write or other exploits, we would need root/polkitd privileges. Let’s take a look at one of these files in /etc/polkit-1/rules.d/50-default.rules:
/* -*- mode: js; js-indent-level: 4; indent-tabs-mode: nil -*- */
// DO NOT EDIT THIS FILE, it will be overwritten on update
//
// Default rules for polkit
//
// See the polkit(8) man page for more information
// about configuring polkit.
polkit.addAdminRule(function(action, subject) {
return [“unix-group:wheel”];
});
Understanding this piece of the API is relatively straightforward. An admin rule is set up to declare that the PolKit admin is any user in the wheel group. Yes, users in wheel can run Sudo and wheel access is required when a user attempts to execute administrative tasks like changing time, adjusting user access, performing maintenance, or troubleshooting services. By abusing our group privileges, we no longer need the user’s password (or root when Sudo is not utilized).
If we were to compromise the user through a client-side vulnerability or any privilege escalation on the box itself, we would no longer need to worry about cached Sudo authorization timestamp tokens or trying to trick users into providing their credentials with bashrc, environment modifications, or other means. Instead, we can abuse the user’s group privileges to give us access, thus granting direct authentication bypassven if the wheel user cannot get root like in Ubuntu ecosystems.
Exploitation With PKCon
So, we know that any user in the wheel group has “most” admin privileges. I say “most” because there are certain other checks taken into account when attempting actions like adding new repository signatures. A user’s role determines the ability to install any package from an installed repo without authentication. This is done with a tool called PKCon (PackageKit Console Client). Let’s check that out.
]$ id
uid=1000(blahman) gid=1000(blahman) groups=1000(blahman),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
]$ Yum install cowsay
Loaded plugins: auto-update-debuginfo, langpacks, refresh-packagekit
You need to be root to perform this command.
]$ dnf install cowsay
Dependencies resolved.
…
Downloading Packages:
cowsay-3.03-14.fc20.noarch.rpm 89 kB/s | 26 kB 00:00
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Error: Unable to initialize yumdb history: [Errno 13] Permission denied: ‘//var/lib/dnf’
]$ pkcon install cowsay
Resolving [=========================]
Querying [=========================]
Testing changes [=========================]
Finished [=========================]
Installing [=========================]
Resolving dependencies [=========================]
Downloading packages [=========================]
Testing changes [=========================]
Installing packages [=========================]
Finished [=========================]
]$ cowsay got root?
______________
< got root? >
———–
\ ^__^
\ (oo)\_______
(__)\ )\/\
||—-w |
|| ||
We couldn’t use Sudo for a variety of reasons (lack of permissions, password, etc.), Yum was inaccessible because it requires root, and DNF wouldn’t work because of FS permission checks; however, PKcon worked flawlessly. In order to exploit this, all we need is a single vulnerability in any package in a repo. There are tons to choose from. If we type ‘PKCon’ or simply ‘man PKCon,’ we can find a list of repos in use and then pull a list of all bins and version numbers. I won’t provide one here because you don’t want everything handed to you.
Conclusion
This simple logic will mostly affect home users who run on an account with wheel. This includes most people, as they need Sudo. Fixing the issue is as simple as managing PolKit authorization rules or properly managing group privileges for users.
We find that possession of user logs and knowledge of your own environment are the best security content to help you navigate away from a bug like grinch. Know how your Linux administrator is installing packages and managing updates—do they use Yum to install packages? Firing on any of the newer methods like PKCon will be an immediate trigger of the exploit in use.
While this type of attack is certainly seen in corporate environments (everyone seems to need to have wheel for one reason or another), your success rate may vary depending on target. There are all sorts of other fun techniques you can utilize with default Polkit rules, and I leave it to the reader to discover more fun.
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.