Grinch Vulnerability Could Put a Hole In Your Linux Stocking 118
itwbennett writes In a blog post Tuesday, security service provider Alert Logic warned of a Linux vulnerability, named grinch after the well-known Dr. Seuss character, that could provide attackers with unfettered root access. The fundamental flaw resides in the Linux authorization system, which can inadvertently allow privilege escalation, granting a user full administrative access. Alert Logic warned that Grinch could be as severe as the Shellshock flaw that roiled the Internet in September.
Update: 12/19 04:47 GMT by S : Reader deathcamaro points out that Red Hat and others say this is not a flaw at all, but expected behavior.
Grinch is not a flaw - has no CVE!!! (Score:5, Informative)
Also check out Red Hat Knowledgebase article [redhat.com] on this too.
Re: (Score:3, Insightful)
Do you need root to add yourself to the 'wheel' group? if so, not a security hole. And the 'wheel' trick only works from the physical console - presumably intended for server machines kept under lock and key with other access security in place. Now if it's enabled by default on desktop systems, that'd be pretty nasty.
I can't see anybody using this feature except possible admins of access-restricted servers. But even for them, how hard is it to use sudo? It sounds like a pretty dumb, unnecessary feature
Re:Grinch is not a flaw - has no CVE!!! (Score:5, Informative)
Yes, you do.
So to translate: News flash, designated admins can do admin things!
Re: (Score:2)
Sure, but the potential to mis-configure a subsystem that has big red asterisks around it anyway such that a trusted user might exceed authority is a far cry from a security vulnerability that might put a hole in my Christmas stocking. Other things to avoid include making /bin/bash suid root, chmod -R o+rwx /, etc etc.
Re: (Score:2)
in other news: chmod +s bash does not work as bash has code which does not allow itself to be SUID. :-)
Seems too many people actually did that
Re: (Score:1)
But you can modify the source and compile your own bash that re-enables running SUID. ;)
Care to help find a name for that huge security risk?
Re: Grinch is not a flaw - has no CVE!!! (Score:1)
Thats more an idiot-admin proofing issue than a security risk.
Re: (Score:3)
If I can modify, recompile, and install bash on a system, I pretty much own it, and wondering about which method(s) I'm going to use to exert control is pointless. If I'm not supposed to be able to do that, there's already been a major security breach.
Re: (Score:3)
It still doesn't take too terribly much to get around minor issues like that. I actually did that as part of a class once where the instructor made all the groups setup guest accounts with a known password and encouraged us to hack eachother's machines.
One group had accidently made /home owned by guest. Whoops. That was some fun figure out how to exploit. .profile (or whatever korn shell uses, they made us
I moved their home dirs (write permission on the parent dir), created new ones (ditto), then dropped a
Re: (Score:3)
But who would put users into wheel group if not for real maintenance work? If you're going to have people in a limited group, create a new group for that purpose.
Re:Grinch is not a flaw - has no CVE!!! (Score:4, Funny)
OMG I discovered a critical security flaw in Linux, guise! If someone has your root password and is sitting at your desk, then with just a few simple keystrokes they can have total access to your system! They can read all your shit, delete your files, anything! Haxx0rs!! It's proven, Linux is unsafe and we should all go run windows instead.
Re: (Score:2)
In a related story, going to the console and booting to single user mode will allow you to set the root password to anything you like. ZOMG!!!
Re:Grinch is not a flaw - has no CVE!!! (Score:4, Informative)
Enjoy the following excerpt right from info su on a Debian box:
23.6.1 Why GNU `su' does not support the `wheel' group
(This section is by Richard Stallman.)
Sometimes a few of the users try to hold total power over all the
rest. For example, in 1984, a few users at the MIT AI lab decided to
seize power by changing the operator password on the Twenex system and
keeping it secret from everyone else. (I was able to thwart this coup
and give power back to the users by patching the kernel, but I wouldn't
know how to do that in Unix.)
However, occasionally the rulers do tell someone. Under the usual
`su' mechanism, once someone learns the root password who sympathizes
with the ordinary users, he or she can tell the rest. The "wheel
group" feature would make this impossible, and thus cement the power of
the rulers.
I'm on the side of the masses, not that of the rulers. If you are
used to supporting the bosses and sysadmins in whatever they do, you
might find this idea strange at first.
Makes me cringe harder every time I read it
Re: (Score:2)
Re: (Score:2)
Of course you do. If non-root users could add themselves to groups, a lot more things would break.
Re: (Score:2)
I think the ONLY interesting point they have is that there are environments where a lot of people have wheel for one reason or another, or where wheel may be even given out by default. In such an environment, then installing this PackageKit software allows anyone to install software.... as expected.
This really is some of the dumbest clickbait disguiesed as a vulnerability that I have ever seen.
Best solution...don't put every account in wheel, and um, don't install PackageKit...unless this is what you want..
Re: (Score:2)
Do you need root to add yourself to the 'wheel' group?
Yes.
Hint: on Debian-based distros, wheel is better known as sudoers.
Re: (Score:2, Funny)
As soon as I heard this, I changed my password to all control characters: ^H^U^H^U^W^U^W^U
Re:Grinch is not a flaw - has no CVE!!! (Score:5, Informative)
This is patently stupid. Yes, if you give a badguy administrative access, bad things can happen--even if you use a fancy GUI to give the bad guy administrative access. The only thing that is even slightly newsworthy here is that maybe a novice admin won't understand the purpose of the wheel group and could be tricked into giving permissions, but there are a lot of ways you can trick a dumb admin, there's no need to single this one out.
Any user in the wheel group .. (Score:1)
"Local administrators are trusted users
So, you have to be an administrator in order to achieve administrator level
Re:Grinch is not a flaw - has no CVE!!! (Score:5, Interesting)
Which Linux systems include the wheel group? Haven't come across that on Linux systems in years (if ever). That's a BSD thing, where GID 0 is "wheel".
On Linux, GID 0 is "root". Or, at least, every Linux system I've used in the past 10 years (none of which are RedHat, though; they do weird and not-so-wonderful things over there)
One of the first things we do on our Linux systems is create the "wheel" group as a system group (UID under 100), and add our admin users to that group. No users go into GID 0. And sudo is configured to only allow group wheel access to things they need access to.
Wheel Group (Score:2)
Debian derived distros disable the password on the root account by default, and only use the wheel group. RedHat distros set a root password during install, but also require the creation of a non-root user; this user is added to the wheel group. What Linux systems have you been using that are not RedHat or Debian derived?
Re: (Score:2)
What are you smoking?
Debian installer specifically asks for a root password, won't let you install the system without a non-root users, and there's no wheel group in /etc/group. There is a sudo group that the first user created during the install is added to.
What Debian system are you using?
Re: (Score:3)
Apologies. It's been a while since I installed debian, and I was misled by my google searches. Ubuntu-derived distros do this, and it seems Gnome/gdm does not allow root login by default. You are correct.
So, it seems I'm smoking bad google searches.
Re: (Score:1)
are you trying to break the internet? you don't apologize when you are wrong!
you start attacking the person.
Re: (Score:2)
Re: (Score:2)
Debian does not use a "wheel" group. Some Debian-derived distros might, but Debian itself doesn't. I recently installed a Debian server, and it is not how you describe: a root password was set during install, and there is no wheel group. This was from the official Debian 7 "wheezy" installer [debian.org].
Re:Wheel Group (Score:4, Informative)
Re: (Score:2)
I don't know if you meant to include Fedora but on all my Fedora installs the only member of the wheel group has been root. I believe the same is true of Centos but I don't have it installed anywhere right now to check.
Re:Wheel Group (Score:4, Informative)
centos: /etc/group
# grep wheel
wheel:x:10:root
redhat 5 /etc/group
# grep wheel
wheel:x:10:root
redhat 6 /etc/group
# grep wheel
wheel:x:10:root
Re: (Score:2)
I very much appreciate the information and the correction, and I am sure that others do as well.
Don't mind me, I'm just gonna be curling into a ball and hoping that it's all over soon.
Re: (Score:2)
I'm pretty sure Debian used to. I don't know if it still does. Ubuntu certainly does not.
Re: (Score:3)
Older than BSD, it's a TENEX thing, from 1969
Re: (Score:1)
On linux, RMS purposefully broke "wheel" out of (IMO flawed) ideological butthurt. This he describes very well himself in "info su".
There is no real reason to use a non-0 GID for wheel. It works nicely in either case, except on linux only after you tell various things to honour it because you are one of those fascist administrators who shuts out normal users from accessing root functions with more than a shared password.
Re:Why 'wheel'? (Score:4, Informative)
just shortened form of slang "big wheel", a person with authority. It was term first used for user accounts with admin privileges in the TENEX operating system (later called TOPS-20).
Extra trivia, the name TENEX was chosen because it was intended to be superior alternative to TOPS-10, as in Ten Extended. OK, that's enough, god I'm old
As bad as ShellShock (Score:2)
So is ShellShock fixed now?
I gathered the basic variant is, but then people developed other variants.
yes, it took about 48 hours (Score:3)
Yes, in the first hours there were various workarounds and fixes suggested, and people came up with ways to get around those first workarounds. About 48 hours after the release, consensus congealed around using Red Hat's fix.
There is a very limited set of cases where it could be a compatibility issue if you had custom scripts relying on the old behavior, but that was judged to be fairly insignificant.
Re: (Score:2)
Relax dude. Now that the media is hyping vulnerabilities, this is just a way for the TV networks to make a movie about the vulnerability that stole Christmas from some poor sysadmins. They'll replay it every Christmas until the end of time. Our great great grandchildren will have to suffer through it.
Re: (Score:1)
Re: (Score:3)
It is fascinating what semi-competent morons think they can do a grand announcement of things that have completely misunderstood. Likely somebody like this will next decry sudo as "the next Shellshock vulnerability".
Re: (Score:1)
Re: Grinch is not a flaw - has no CVE!!! (Score:1)
Cannot tell if being ironic or genuinely idiot.
Please clarify
Re: (Score:1)
no details because there is no vulnerability other than user error. no different than running windows as an admin user.
Quite possibly the stupidest vulnerability ever (Score:2, Informative)
"Oh no, Linux includes a "wheel" user group by default that grants superuser privileges to users in it! And someone could possibly add themselves to that group and gain root access!"
Re: (Score:3)
"Oh no, Linux includes a "wheel" user group by default that grants superuser privileges to users in it! And someone could possibly add themselves to that group and gain root access!"
I think what they're trying to say is that Polkit has different AAA rules than sudo does, which you might not expect. So, gain mastery of Polkit and all the other new *Kits and systemd and whatnot if you expect to be able to run a secure server.
Even if they are publicity whoring and trying to get the press excited about a "Chri
Re: (Score:1)
which is yet another excellent reason to get rid of this crap that systemd and it's ilk are
Re: (Score:3)
Please; this had nothing to do with systemd. It's about PackageKit, which has been around for quite a bit longer. 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" g
Re: (Score:1)
"Oh no, Linux includes a "wheel" user group by default that grants superuser privileges to users in it! And someone could possibly add themselves to that group and gain root access!"
Actually, wheel doesn't grant superuser by default. Being in wheel + installation of a *non-stock* sudo = superuser. Being in wheel and knowing root's password = su superuser. Wheel group != admin, despite what some distros would have you believe.
That wheel == administrators is a bad, poorly documented assumption on the part of the polkit+packagekit authors. The original group writing the original report about the issue were able to install software as root without a prompt and without knowing a password. T
Re: (Score:2)
"Oh no, Linux includes a "wheel" user group by default that grants superuser privileges to users in it! And someone could possibly add themselves to that group and gain root access!"
Or put another way:
"Oh no, Windows includes an "Administrators" group by default that grants superuser privileges to users in it! And an existing administrator could possibly add themselves to that group and gain administrator access!"
Agreed, stupidest vulnerability ever.
Re: (Score:2)
we need a tacky name for that windows vulnerability, else it's never going to make the news!
Re: Quite possibly the stupidest vulnerability eve (Score:2)
Krampus, obviously.
This is dumb (Score:1)
Let me make sure I understand this . . . (Score:2)
I get the impression this means that we're looking at a PEBKAC issue rather than a software bug. Sorry, I know of no OS which can be secured against PEBKAC exploits.
Also, to exploit the PEBKAC error requires the Chair to be locally attached via the system console. Uh, hate to bust your bubble guys, but if somebody has console access (physical access) to a server they OWN that server for a
Re: (Score:2)
Indeed. This definitely is a Layer-8 problem.
Re: (Score:2)
or reboot, interact with grub, start a shell ...
instructions are a google search away for "recover from lost root password"
Bootloader password (Score:2)
If you are concerned about security, you will have a boot loader password configured, no changing the kernel command line. Of course, you would also have ensured no removable media are bootable, and have set a bios password, and have kept the server physically secured (no removing the BIOS battery, removing any disks etc.).
Why, yes you did. (Score:2)
Your a mean one (Score:2)
Original Author itching for a story (Score:1)
The original author has written pieces for many publications, as he has a university degree in writing. He could have written stories about medicine, or law, or cooking. Instead Joab Jackson writes about computer stuff. He is always itching for a good story (one that gets a lot of eyeballs and makes his publisher smile and say "good job Jack!"). In this case, a sensational headline, and what looks like a menacing scoop. But is it the Shellshock bug? Is it the Heartbleed bug? No. Its normal behavior
Re: (Score:2)
when there is ridiculous clueless hype like the itworld article it's worth having a slashdot article about it just so that people here can discuss how it is clueless hype giving a featured platform a bad name for no reason.
Wrecking a car causes damage! Film @ 11 (Score:3, Interesting)
The flaw we're seeing here is various "computer security journalists" (and journals) destroying their reputations.
This is on the order of discovering that big heavy things that fall on your foot can cause pain.
Re: (Score:2)
Let me tell you about the time I was living outside the gravity well, not pretty there either, turns out when big heavy things collide with your foot inertia can be a bitch too
Re: (Score:2)
outside the gravity well, "heavy" can mean "being painful to de-acelerate" using part of the body such as foot due to possessing great inertia. Heavy really is all about lack of ease of acceleration
Uh Oh (Score:2)
"Alert Logic warned that Grinch could be as severe as the Shellshock flaw that roiled the Internet in September"
While a big deal, Shellshock was very limited in scope and the large scale exploit implications were stamped out very quickly through updates to vulnerable web front-ends (which was just about the only exploitable path, despite so many proclamations that the sky was falling and every internet-connected linux device will get rooted in a matter of days). If this is as severe as Shellshock, I will t
Re: (Score:2)
Well pretty much all vulnerabilities can be solved by updating the web front end. But shellshock was pretty much as bad as it gets, because it was extremely widely deployed in web servers, and so simple to exploit that even your mother could do it. It doesn't get worse than that.
Re: (Score:1)
I'd really like to hear what Bennett Haselton has to say about that.
A Much Better Article - Separate Fact from FUD (Score:2, Informative)
This article is a better one. Less fear-hype, more reason:
http://blog.threatstack.com/the-linux-grinch-vulnerability-separating-the-fact-from-the-fud
Clickbait? (Score:2)
Re: (Score:2)
Re: (Score:2)
if your linux stocking gets holey, SystemD will darn it
Local users (Score:2)
Seems to me that if you are a "local user", which is someone with access to the actual keyboard of the server, you likely have direct access to the actual server itself, which is even more a security risk.
Change headline or remove article (Score:2)
Can we vote the ARTICLE down so it will go away? Or change the headline/summary? Nothing like spreading yet more false security FUD. :(
Over-hyped. (Score:5, Informative)
From the oss-sec mailing list:
http://www.openwall.com/lists/... [openwall.com]
This is not a vulnerability, this is expected behaviour.
http://www.openwall.com/lists/... [openwall.com]
This paragraph suggests so many things which are simply wrong, confused,
or irrelevant that i don't know what to make of the rest of the article.
* modern debian GNU/Linux systems do not have a wheel group at all. No
particular versions or flavors of "Linux system"
* on systems where members of group wheel really do have unrestricted
access to the su command, having wheel in the first place *is* the
vulnerability -- it is a misconfiguration to expect an account to be
non-privileged if it is a member of wheel.
* the last sentence appears to be about setuid/setgid binaries, but
makes no mention that the overwhelming majority of binaries are not
setuid/setgid.
Later on, the post suggests that wheel group membership is related to
sudo privileges.
It also seems to assume that polkit always permits access for members of
group wheel. I can find no such configuration on a modern debian system.
I don't think there's anything significant in this ambiguous,
underspecified, and confused report.
http://www.openwall.com/lists/... [openwall.com]
Yeah I looked into this (the article/etc was completely confusing and
took some time to parse):
1) the article states they contacted red hat, we were unable to find
any inbound email or bugzilla entry pertaining to this issue, as always
if you have an issue you wish to report please contact secalert@...hat.com
2) this is expected behaviour, admin users can install software (do I
have to say this? really? yes. I was told I should say this).
3) don't run web apps as admin users (do I have to say this? really?
yes. I was told I should say this).
4) if you feel the need to run a web app as an admin user restrict what
they can do via SELinux, and don't let them install software (do I have
to say this? really? yes. I was told I should say this).
So TL;DR: it's not a security vulnerability, and it will NOT be getting
a CVE.
I can only assume this article/vuln is perhaps referring to something
like Cpanel and other control panels that people sometimes install
insecurely/improperly and then never update. Or something. Who knows.
So if you have root access, (Score:2)
... you can get root access.
The "wheel" group is an admin group (Score:5, Informative)
Truth: some Linux distros have a "wheel" group.
Truth: this group is used as a list of people with elevated permissions
Truth: one of the elevated permissions often assigned to this group is the ability to become root, especially with sudo
Falsehood: all users on a Linux system are members of the "wheel" group
Falsehood: one can add oneself to the "wheel" group without having permissions already elevated above regular user status
tl;dr: someone misunderstands groups and called it a vulnerability
Jesus Slashdot (Score:3)
I read the report and was perplexed (Score:2)
being an Ubuntu user I don't have a wheel group, but this seems to be related to the fact that local users don't need root to install packages from the repositories. If there is a bad package in a trusted repository, then an untrusted local user could install it and the bad package could give that user root access. This is expected behaviour, I don't think you can install local packages through this rule (if you can then there is a vulnerability, create your own deb package with an install script that gives
Re: (Score:1)
cowsay is a program which generates ASCII pictures of a cow with a message.
I think someone sent him a prank saying that if you can install cowsay
cowsay got root?
will tell you whether you have root access or not.
When in fact it just prints an ascii picture of a cow.
Frightening (Score:2)
to think that I remember when Wheel actually meant something! TOPS-20 forever! What a great OS, even if it had a lot of security holes.