View previous topic :: View next topic |
Author |
Message |
makomk n00b
Joined: 15 Jul 2005 Posts: 46 Location: Not all there
|
Posted: Thu Mar 23, 2006 11:35 pm Post subject: Gentoo games group leads to security hole - big surprise(!) |
|
|
So, it looks like Gentoo's unusual use of the games group has lead to a security hole - if Nethack is installed, anyone can modify the game state data and cause it to run arbitrary code. (On other systems, the "games" group is used to make sure that users can't manually modify the stored game state, and no users are members of it. On Gentoo, however, you have to be in the "games" group to run any games, and so all users who can run games can make arbitrary changes to the system-wide game state directory on games like Nethack).
To be honest, I suspected something like this might happen sooner or later - protecting Nethack from this kind of attack probably wasn't seen as important, since if it's installed in the normal way you can't do this (at least, not as easily). Why exactly did Gentoo use the games group in this way, anyway?
Last edited by makomk on Fri Mar 24, 2006 12:14 am; edited 1 time in total |
|
Back to top |
|
|
BlackEdder Advocate
Joined: 26 Apr 2004 Posts: 2588 Location: Dutch enclave in Egham, UK
|
Posted: Thu Mar 23, 2006 11:46 pm Post subject: |
|
|
You'd better open a bugreport about this at bugs.gentoo.org |
|
Back to top |
|
|
makomk n00b
Joined: 15 Jul 2005 Posts: 46 Location: Not all there
|
Posted: Fri Mar 24, 2006 12:02 am Post subject: |
|
|
BlackEdder wrote: | You'd better open a bugreport about this at bugs.gentoo.org |
No need - they already know about it (the link's to the GLSA, which is how I found out about it). I'm just posting here to complain about the whole mess... |
|
Back to top |
|
|
PaulBredbury Watchman
Joined: 14 Jul 2005 Posts: 7310
|
Posted: Fri Mar 24, 2006 12:43 am Post subject: |
|
|
If nethack allows a saved game file to run arbitrary code, then the bug is obviously in the nethack code
I would like to know whether, ahem, "(at least, not as easily)", means that it's still a bug in nethack, and whether it's still a potential security exploit in other distros? |
|
Back to top |
|
|
asiobob Veteran
Joined: 29 Oct 2003 Posts: 1375 Location: Bamboo Creek
|
Posted: Fri Mar 24, 2006 9:08 am Post subject: |
|
|
nethack should get fixed. I mean if the /bin/passwd program could execute arbitary code all linux distros are screwed. (note the passwd program has the setuid so it runs with root powers when a normal user runs it -- how else can a user change their password in /etc/passwd and /etc/shadow) |
|
Back to top |
|
|
GenKreton l33t
Joined: 20 Sep 2003 Posts: 828 Location: Cambridge, MA
|
Posted: Sat Mar 25, 2006 8:31 pm Post subject: |
|
|
More information can be found at the actual bug report https://bugs.gentoo.org/show_bug.cgi?id=125902. It does seem that the problem is solely with gentoo's use of the games group and not the game nethack. I really don't see whats wrong with a light patch onto it to fix our problems. Nethack doesn't exactly update often anyways. |
|
Back to top |
|
|
Q-collective Advocate
Joined: 22 Mar 2004 Posts: 2071
|
Posted: Sat Mar 25, 2006 10:48 pm Post subject: |
|
|
Maybe someone should write a patch for nethack then? |
|
Back to top |
|
|
mrsteven Veteran
Joined: 04 Jul 2003 Posts: 1938
|
Posted: Sun Mar 26, 2006 9:53 pm Post subject: |
|
|
The problem has two sides:
- The unchecked call to fscanf: It is not really what I call clean code, but it works, as long as no one else than the owner of the savegame is allowed to modify it. That's the minor problem.
- Gentoo's handling of savegames: It allows other users than the owner of a savegame to modfy it. If a user has write permission to the directory in which the savegames are stored he could also delete savegames of other players (unless the sticky bit is set). Not nice... I don't understand why savegames don't go into $HOME generally, since that is where they belong. Symlink attacks are also a possible problem.
There is also a problem with system wide highscore lists on most multiuser systems. On one hand every user who wants his score to be recorded must be able to write to the highscore file. On the other side he could also destroy that file by using dd if=/dev/zero of=/var/games/my_highscore_list, for example. _________________ Unix philosophy: "Do one thing and do it well."
systemd: "Do everything and do it wrong." |
|
Back to top |
|
|
bobobo Tux's lil' helper
Joined: 24 Nov 2005 Posts: 122
|
Posted: Sun Mar 26, 2006 11:46 pm Post subject: |
|
|
in nethack, savegames are saved on purpose in a directory that users can't access. Well actually they can access it (i think), but they are not supposed to have read/write on the files, so it would make no sense for the savegames to be in home. It's the design of nethack : when you die, you die, no save/reload. Now this works fine on most systems, but conflicts here with gentoo... |
|
Back to top |
|
|
Q-collective Advocate
Joined: 22 Mar 2004 Posts: 2071
|
Posted: Sun Mar 26, 2006 11:54 pm Post subject: |
|
|
bobobo wrote: | in nethack, savegames are saved on purpose in a directory that users can't access. Well actually they can access it (i think), but they are not supposed to have read/write on the files, so it would make no sense for the savegames to be in home. It's the design of nethack : when you die, you die, no save/reload. Now this works fine on most systems, but conflicts here with gentoo... |
Maybe I've played too little nethack, but how can you save a game if you don't have write permissions? |
|
Back to top |
|
|
IntergalacticWalrus Guru
Joined: 07 Jan 2003 Posts: 513 Location: Montreal QC (Canada)
|
Posted: Mon Mar 27, 2006 8:10 am Post subject: |
|
|
I've always hated Gentoo's overcomplicated games handling. It's like they were trying too much. A "games" group? That's pure management overkill. Not to mention the messy, FHS-violating /usr/games structure. Well, then again the FHS way to handle games is even messier. I never understood why games had to have their own damn directory structures.
Anyway, I hope the special games handling will eventually get scrapped in the future. Games should be handled just like anything else. |
|
Back to top |
|
|
bobobo Tux's lil' helper
Joined: 24 Nov 2005 Posts: 122
|
Posted: Mon Mar 27, 2006 8:18 am Post subject: |
|
|
Well, i don't know for sure since i only played nethack on gentoo, but i believe a user cannot access the savegames, except by running the nethack process, nethack then uses setuid() or setgid() calls to allow the reading/writing of savegames (can someone infirm/confirm that ?). |
|
Back to top |
|
|
wolf31o2 Retired Dev
Joined: 31 Jan 2003 Posts: 628 Location: Mountain View, CA
|
Posted: Mon Mar 27, 2006 2:48 pm Post subject: |
|
|
People seem to forget something...
This *is* 100% a bug in nethack. It is only Gentoo's unique way of handling games that has *exposed* it. If a user were to manage to get himself into the "games" group on *any other distribution* then he would be able to make changes to the save games for nethack and still cause *other users* on the system to run *arbitrary code* or *overwrite any file* that they have write access to.
The proper solution is a *twofold* solution. First, nethack itself *must* be patched to not allow the code execution. Second, we need to rethink our games policy. Don't think we're going to drop the games group requirement, simply because of the enormous workload it would cause simply to get anything accomplished on this (think about having to revbump every game in the tree). Anyway, we're currently leaning towards using a "scores" group that nobody is a member of with nethack running setgid scores. This still *requires* that the game is patched, as anyone in the new scores group would still be able to perform the same actions as users currently in the games group.
The whole point of the GLSA is bunk, in my opinion. We use the games group to limit who has access to these games. Changing that to being some other group doesn't mitigate this, but only changes the attack vector. We also cannot simply drop the games group requirement and make things setgid games, as that doesn't resolve the issue as there are thousands of boxes out there with users already in the games group. _________________ Ex-Gentoo Developer
Catalyst/Genkernel Development Lead
http://wolf31o2.org |
|
Back to top |
|
|
Houdini Apprentice
Joined: 14 Jun 2002 Posts: 224 Location: New Mexico Tech, Socorro, NM
|
Posted: Mon Mar 27, 2006 4:00 pm Post subject: |
|
|
Is there a reason that Gentoo does games the way it does, instead of how Everybody Else (tm) does it? SetGID "games" with sane permissions on that always seemed to be reasonable. I'm sure that a lot of thought went into the Gentoo way, and I would like to see some of the design ideas (if any are around).
As a quick(er) fix, maybe the two approaches could be mixed. Having a games group seems reasonable, as it allows easier management of which users can play games. Having games setXID (X = {G, U}) to something else, call it "gamesbin" for now, could add security to the current approach. It would require a bump to all games, something which no one wants to do, but it might be worth it. If there's an eclass for games already, it could be changed there. If there's not, maybe this could serve as motivation for that to start happening. _________________ ^]:wq |
|
Back to top |
|
|
doyster n00b
Joined: 27 Sep 2005 Posts: 15
|
Posted: Mon Mar 27, 2006 7:51 pm Post subject: |
|
|
wolf31o2 wrote: | People seem to forget something...
This *is* 100% a bug in nethack. It is only Gentoo's unique way of handling games that has *exposed* it. If a user were to manage to get himself into the "games" group on *any other distribution* then he would be able to make changes to the save games for nethack and still cause *other users* on the system to run *arbitrary code* or *overwrite any file* that they have write access to.
The proper solution is a *twofold* solution. First, nethack itself *must* be patched to not allow the code execution. Second, we need to rethink our games policy. Don't think we're going to drop the games group requirement, simply because of the enormous workload it would cause simply to get anything accomplished on this (think about having to revbump every game in the tree). Anyway, we're currently leaning towards using a "scores" group that nobody is a member of with nethack running setgid scores. This still *requires* that the game is patched, as anyone in the new scores group would still be able to perform the same actions as users currently in the games group.
The whole point of the GLSA is bunk, in my opinion. We use the games group to limit who has access to these games. Changing that to being some other group doesn't mitigate this, but only changes the attack vector. We also cannot simply drop the games group requirement and make things setgid games, as that doesn't resolve the issue as there are thousands of boxes out there with users already in the games group. |
And if a user were to manage to get himself into the "disk" group on any distribution, then he would be able to read and write arbitrary data to the hard drive. I don't think that this is "100%" a bug in nethack. It should be fixed, since if nethack were to somehow generate a buggy save game file, it could have bad effects, but on any other system, there would be no way for a normal user to modify the files that nethack tries to write to. Personally, i like the idea of the "scores" group, although it seems to me that it would make more sense to make the games group equivalent to the games group in other distributions, and create a new group for people who can play games. I understand that that would be a lot more work though. |
|
Back to top |
|
|
GNUtoo Veteran
Joined: 05 May 2005 Posts: 1919
|
Posted: Mon Mar 27, 2006 11:29 pm Post subject: |
|
|
PaulBredbury wrote: | the bug is obviously in the nethack code |
wolf31o2 wrote: | This *is* 100% a bug in nethack |
nethack code or not the way gentoo handle games must be fixed
but we can temporaly patch nethack.while working on resloving this issue
it's like if there were a bug inside selinux,pax or something equivalent...of course the problem is ALSO in the aplication that isn't well written...
but what if you run binary games? i don't only mean commercial games but certain games such as cube use binaries in order to prevent cheating(or if not why gentoo also install the default binary?)
genericaly protecting gentoo against this problem is not a bad idea...because we won't be able to search(and find) bugs and fix all games
*mabe we should be able to do the folowing(not very usefull because high risk still exist):
knowin that sudo is not safe we won't use it
we could instead use su and a hack that permit us to have an environement such as when we are loged natively(that means that we must be able to run things un /usr/bin and give acess to $HOME to all programs running inside this environement) and run games from that environement
but we must be carefull and look if it can compromise or not the normal user acount(for the hack giving acess to /usr/* )
mabe also chroot or jail?
the problem is that the atacker WILL be able to control this system...so it's a bad idea(usefull only for a quick and dirty fix)
Last edited by GNUtoo on Mon Mar 27, 2006 11:56 pm; edited 1 time in total |
|
Back to top |
|
|
GNUtoo Veteran
Joined: 05 May 2005 Posts: 1919
|
Posted: Mon Mar 27, 2006 11:50 pm Post subject: Re: Gentoo games group leads to security hole - big surprise |
|
|
makomk wrote: | So, it looks like Gentoo's unusual use of the games group has lead to a security hole - if Nethack is installed, anyone can modify the game state data and cause it to run arbitrary code. (On other systems, the "games" group is used to make sure that users can't manually modify the stored game state, and no users are members of it. On Gentoo, however, you have to be in the "games" group to run any games, and so all users who can run games can make arbitrary changes to the system-wide game state directory on games like Nethack).
To be honest, I suspected something like this might happen sooner or later - protecting Nethack from this kind of attack probably wasn't seen as important, since if it's installed in the normal way you can't do this (at least, not as easily). Why exactly did Gentoo use the games group in this way, anyway? |
i don't understand verry well the situation...
how can the game group prevent people from manualy modify the game's data?
why not locking the files and permit only the game executables to modify theses files?
there is also a solution...lol...switch to plan9(you can setup "permissions" per programs...a program can have acces only to the part of the filesystem and the hardware he need to run...that design is safer and a lot more simple from all root/user and similar) and rewrite all apps from sctatch...lol |
|
Back to top |
|
|
Godsmacker777 Apprentice
Joined: 04 May 2004 Posts: 205 Location: Fenway area, Boston Massachusetts :O)
|
Posted: Wed Mar 29, 2006 3:25 am Post subject: |
|
|
While I don't have any direct ideas to *fix* this issue, I found myself getting annoyed seeing people say the "proper" solution might require too much work.
If there is something wrong with the way other distros deal with the games group, cool..but why exactly do we fork from the standard?
One other thought..adding a group only obfuscates matters. Aren't we about simplicity? Adding another group (scores) is a quick fix to an issue; one would think we'd spend a little more time coming up with a solid solution.
/end rant
I only mean this to promote discussion, and it came to mind in reading through the post. _________________ Why must we hear what system you're running gentoo on, especially if all you've got is a measly gig of ram or 3gHz processor?
I want to see signatures boasting 25 cpu clusters and blade severs, or a big 'ole onyx..anyone running gentoo on an onxy?? |
|
Back to top |
|
|
dingo n00b
Joined: 18 Aug 2002 Posts: 58
|
Posted: Mon Apr 03, 2006 4:47 pm Post subject: |
|
|
new_to_non_X86 wrote: | PaulBredbury wrote: | the bug is obviously in the nethack code |
wolf31o2 wrote: | This *is* 100% a bug in nethack |
nethack code or not the way gentoo handle games must be fixed
but we can temporaly patch nethack.while working on resloving this issue
it's like if there were a bug inside selinux,pax or something equivalent...of course the problem is ALSO in the aplication that isn't well written...
but what if you run binary games? i don't only mean commercial games but certain games such as cube use binaries in order to prevent cheating(or if not why gentoo also install the default binary?)
genericaly protecting gentoo against this problem is not a bad idea...because we won't be able to search(and find) bugs and fix all games
*mabe we should be able to do the folowing(not very usefull because high risk still exist):
knowin that sudo is not safe we won't use it
we could instead use su and a hack that permit us to have an environement such as when we are loged natively(that means that we must be able to run things un /usr/bin and give acess to $HOME to all programs running inside this environement) and run games from that environement
but we must be carefull and look if it can compromise or not the normal user acount(for the hack giving acess to /usr/* )
mabe also chroot or jail?
the problem is that the atacker WILL be able to control this system...so it's a bad idea(usefull only for a quick and dirty fix) |
This proposed solution is far too complicated, and I doubt you are ready to contribute code or patches for this idea.
It is also unnecessary. The solution is already in place; gentoo took the liberty of removing it.
The way BSD does it works fine, it has been in place since the 80's. A small explanation:
Games are granted setgid permissions of the games group. This means that when somebody executes the game, they are temporarily a part of the games group during the execution of the game, allowing them to modify the scorefile, or place saved games in the save/ directories.
The result is, the user can only modify the scorefile and saved games through the program itself. The program itself has checks to limit the user to modifying only her savefile, and the scorefile only when appropriate (win, death).
The savefile cannot be created by the user outside of the game, as it only has +w permissions for the games group.
The scorefile can only be modified by the game, during the game.
The way gentoo does this is ridiculous. A small explanation:
All of the games are +x only for the games group. The games are not setgid, and are run under the user's normal permissions. This means that to allow the user to write to the scoreboard and save games directory, she must have +rw access to these.
The result in gentoo:
You can save a nethack game, uncompress it, hexedit it to increase your stats, place it back into the directory (that you have rw access to), and re-load the saved game. Complete the game until you win or die, and receive a very high score.
But why go through the trouble? Just edit the scorefile, you have the permissions to.
So now the scorefile is no longer authoritative. But it can get much, much worse.
Edit the scorefile, or somebody else's saved game, or make a saved game for somebody else (though nethack and most others will verify that the saved game has the player's attributes). Find a buffer with bad bounds checking, and insert a small snippet of code that will make a copy of /bin/sh somewhere sneaky and setuid for the user executing the code.
The user will see nethack crash, shrug it off, thinking that the saved game was corrupt, and start a new game. The attacker will run the copy of /bin/sh the victim created and be the effective user of the victim
and go on reading her mail, stealing ssh keys, etc. etc.
In Gentoo, the game is being executed in the context of the user who played it, even root may take a load off with a quick game of nethack, with severe repercussions.
The _only_ reasoning I can see for gentoo doing this is the purpose of selectively allowing particular users to run games.
On non-gentoo/BSD:
You cannot modify even your own saved game. You can make a copy of it and hexedit it, but only replace it using sudo or root access. Nobody (as in !everybody) is in the games group. The same attack could not happen unless you found a way to overflow a buffer in-game. Making a corrupt save file outside of the game will do you no good, as you will not be able to load it. Making a corrupt savefile in-game will also not do you any good, because it is loaded only for you. Corrupting the scorefile in-game would be QUITE the feat, and I would be even more difficult. In fact, it is nearly impossible as the avenues of input in-game are very limited.
The games do not need to be fixed; gentoo's non-standard handling of the games do. Buffer overflows are non-issue outside of gentoo. |
|
Back to top |
|
|
Godsmacker777 Apprentice
Joined: 04 May 2004 Posts: 205 Location: Fenway area, Boston Massachusetts :O)
|
Posted: Tue Apr 04, 2006 1:26 am Post subject: |
|
|
that was quite the explanation!
thank you :O) _________________ Why must we hear what system you're running gentoo on, especially if all you've got is a measly gig of ram or 3gHz processor?
I want to see signatures boasting 25 cpu clusters and blade severs, or a big 'ole onyx..anyone running gentoo on an onxy?? |
|
Back to top |
|
|
chris.c.hogan Apprentice
Joined: 02 Oct 2005 Posts: 189
|
Posted: Tue Apr 04, 2006 6:57 pm Post subject: Gentoo's unusual use of the games group? |
|
|
I keep seeing references in this thread, and in the bug report, that say this problem is unique to Gentoo. I'm a bit confused on this statement. For years I ran SuSE, up to about 9.3. Users had to be a member of the games group to save games in Falcon's Eye. When I set up the security restrictions for my kids, I used the example that comes with PAM in limiting membership to the games group to certain times of the day. In group.conf, you have:
Quote: | #
# another example: running 'xsh' on tty* (any ttyXXX device),
# the user 'sword' is given access to games (through membership of
# the floppy group) after work hours
#
#xsh; tty* ;sword;!Wk0900-1800;games, sound
#xsh; tty* ;*;Al0900-1800;floppy
|
Granted, the same configuration file does come with security warnings. However, if PAM uses it as an example, and PAM is used by most distributions, then I would think this is fairly standard usage of the games group and goes far beyond Gentoo. |
|
Back to top |
|
|
mikeyd n00b
Joined: 30 Nov 2004 Posts: 4
|
Posted: Tue Apr 04, 2006 8:51 pm Post subject: |
|
|
wolf31o2 wrote: | People seem to forget something...
This *is* 100% a bug in nethack. It is only Gentoo's unique way of handling games that has *exposed* it. If a user were to manage to get himself into the "games" group on *any other distribution* then he would be able to make changes to the save games for nethack and still cause *other users* on the system to run *arbitrary code* or *overwrite any file* that they have write access to.
|
And if a user were to manage to get himself into the "disk" group on any distribution then he would be able to change system binaries and cause other users to run arbitrary code or overwrite any file that they have write access to. |
|
Back to top |
|
|
-Smooth- n00b
Joined: 23 Jul 2005 Posts: 7
|
Posted: Thu Apr 06, 2006 1:53 am Post subject: |
|
|
Linux won't allow setuid/setgid shell scripts for obvious security reasons. A common way to doge this though is to create a setuid/setgid executable who's sole purpose is to "wrap" the script and call it directly with the new permissions. Perhaps a similar approach could be applied in a security patch. You wouldn't even have to break compatibility with the original paths. (which would conflict with existing ebuilds) What if you create a new group, let's call it "ingame", and change the ownership/permissions of the game executables to setgid ingame. Now the users of the original "games" group won't be able to run them. But if you put all the setgid wrappers in some directory like "/usr/bin/wrappers" and add that directory to the users' paths, they'll never know the difference. Tab-completion should work and everything. New ebuilds could gradually be brought up to date, and the wrapper scripts could be removed as they're no longer necessary.
For the record I think there are security pros and cons to be found with both Gentoo and non-Gentoo methods, but Gentoo should adopt a mixed approach instead of the current system.
----------------
Revision to the suggestion above:
It would actually be a more workable solution to leave the original game executables alone completely, create a new group "gamers", and have the wrappers be setgid "games". (even less conflict with existing ebuilds) Am I the only one still interested in this? _________________ No mail. No Plan. |
|
Back to top |
|
|
bssteph l33t
Joined: 26 Feb 2003 Posts: 652 Location: Wisconsin
|
Posted: Mon Apr 10, 2006 8:35 pm Post subject: |
|
|
Is it sufficiently secure to just to make the nethack files/directories world-readable (and executable, where appropriate) and the binaries setgid? I have a box I wanted just nethack on (so nuts to putting users in the games group if it's a vuln) and this seems to work. Starting/saving/reloading/ending games works, anyway... |
|
Back to top |
|
|
Wispy n00b
Joined: 10 Apr 2006 Posts: 2
|
Posted: Mon Apr 10, 2006 10:22 pm Post subject: |
|
|
wolf31o2 wrote: | People seem to forget something...
This *is* 100% a bug in nethack. It is only Gentoo's unique way of handling games that has *exposed* it. If a user were to manage to get himself into the "games" group on *any other distribution* then he would be able to make changes to the save games for nethack and still cause *other users* on the system to run *arbitrary code* or *overwrite any file* that they have write access to. |
I don't think I got you clearly. One can always write and compile his own code and run it. And as long as the gid and uid are set correctly a program can also do whatever it wants. Your arguments seem to me as `What if a user were to manage to get himself into the "root" group on *any other distribution* then he would be able to do blah blah blah....' So there *is* 100% a bug in our Linux distro?
wolf31o2 wrote: | The proper solution is a *twofold* solution. First, nethack itself *must* be patched to not allow the code execution. Second, we need to rethink our games policy. Don't think we're going to drop the games group requirement, simply because of the enormous workload it would cause simply to get anything accomplished on this (think about having to revbump every game in the tree). Anyway, we're currently leaning towards using a "scores" group that nobody is a member of with nethack running setgid scores. This still *requires* that the game is patched, as anyone in the new scores group would still be able to perform the same actions as users currently in the games group.
The whole point of the GLSA is bunk, in my opinion. We use the games group to limit who has access to these games. Changing that to being some other group doesn't mitigate this, but only changes the attack vector. We also cannot simply drop the games group requirement and make things setgid games, as that doesn't resolve the issue as there are thousands of boxes out there with users already in the games group. |
I don't see any benifits of our Gentoo's games group policy. Violating FHS and being not compatible with other distros are not reasonable behavior of our mighty Gentoo Linux. IMO, if most of the users think it is useless, change it and change it right now. I bet you don't want to change it after there are 3000 ebuilds in our games. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|