Gentoo games group leads to security hole - big surprise(!)

[makomk]

So, it looks like Gentoo's unusual use of the games group has [glsa=200603-23]lead to a security hole[/glsa] - 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?

[BlackEdder]

You'd better open a bugreport about this at bugs.gentoo.org

[makomk]

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...

[PaulBredbury]

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?

[asiobob]

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)

[GenKreton]

More information can be found at the actual bug report http://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.

[Q-collective]

Maybe someone should write a patch for nethack then?

[mrsteven]

The problem has two sides:

1. 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.
2. 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.

[bobobo]

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...

[Q-collective]

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?

[IntergalacticWalrus]

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.

[bobobo]

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 ?).

[wolf31o2]

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.

[Houdini]

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.

[doyster]

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.

[GNUtoo]

the bug is obviously in the nethack code

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)

[GNUtoo]

So, it looks like Gentoo's unusual use of the games group has [glsa=200603-23]lead to a security hole[/glsa] - 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

[Godsmacker777]

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.

[dingo]

the bug is obviously in the nethack code

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.

[Godsmacker777]

that was quite the explanation!

thank you :O)

[chris.c.hogan]

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:

#
# 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.

[mikeyd]

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.

[-Smooth-]

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?

[bssteph]

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...

[Wispy]

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?

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.