nethack doesnt expect users to be able to set their own high scores or manipulate state files, on most UNIX-like systems this is true, but for some reason not on gentoo, where users are added to group games, rather than having group games reserved as a special group to prevent tampering with high scores and so on. from readentry() in topten.c: ... static const char fmt33[] = "%s %s %s %s %[^,],%[^\n]%*c"; ... else if (fscanf(rfile, fmt33, tt->plrole, tt->plrace, tt->plgend, tt->plalign, tt->name, tt->death) != 6) tt->points = 0; ... unchecked fscanf() from the group games writable record file in /var/games/nethack. I could create a record entry that will overflow a heap buffer and execute arbitrary code with the rights of any users who play nethack. Also note that there are most likely many more of these bugs, and as I can create save games as any user, that are automatically read when those users play nethack. reproduce: perl -e 'print "3.4.3 0 0 0 0 0 0 0 0 0 0 FOO BAR FOO BAR FOO,","A"x"50000","\n"' > /var/games/nethack/record then when you die (or use nethack -s), nethack reads the file. Note this is not a bug in nethack, it's due to gentoo's group games policy.
games team: please advise how you want to proceed.
Regrouping issues, same cause for two bugs : ========================= As gentoo doesnt follow the standard of setting games to setgid a low privileged group, any user in group games can create symlinks in /var/games/nethack/save, allowing them to trick other users to overwriting or creating files. reproduce: cd /var/games/nethack/save ln -s /any/file/victim/owns <uid><username>.bz2 now get victim to run nethack, when they save their game target file will be overwritten or created. This only affects gentoo, and is not a bug in nethack. ====================================
*** Bug 122376 has been marked as a duplicate of this bug. ***
games team give permission to mask until a fix is available
masked pending resolution of this issue, do we want a maskglsa?
This is a B2 issue, so unless games is planning to fix this fast we need a masking glsa.
The problem with us taking any quick action on this is fairly simple. The Gentoo games team has a policy where we restrict who can run games based on the games group. This is similar to how performing raw reads on cdrom devices is limited to the cdrom group, or how running vmware-workstation is limited to the vmware group. This has been in place for a long time and is well-received by our users. To revert this behavior is not something that we wish to do, nor something that can be accomplished overnight as *all* games ebuilds rely on this behavior. Our thinking has always been that the system's administrator puts only trusted people in the games group and that he understands that they will be able to run these games. While I do see the points brought up in these recent bugs, they seem to completely ignore that the way the Gentoo games team does this is what is wanted by our users. Now, we don't have a better solution just yet, but we are working on it. Feel free to mask the games that are showing problems such as these until we can come up with a proper solution that is acceptable to us without removing current functionality, nor being vulnerable to these issues.
Restricting who can access specific hardware and potentially dangerous applications is quite different from restricting who can access games. Nobody would expect granting permission to play games would allow them to compromise other users accounts or disrupt other users legitimate use of the games, but this is exactly what can happen. what functionality is it that you dont want to remove, the ability to limit who can execute games? I've already suggested how this can be achieved in an email to vapier without breaking high scores, security, etc. I never received any reply though, if you'd like me to bounce you a copy just ping me on irc.
please send email like that to games@gentoo.org
Is this an issue for games-roguelike/slashem as well? If so it should also be masked.
Thanks Raymond, you are correct, slashem is also affected, filed as bug 127167
I agree with jaervosz, we need a mask glsa if there is no change coming soon, which is probably not the case according to comment #7
Yup, we'll need a masking GLSA if there's no fix soon. Games team, could you please comment when you expect to have this fixed?
As I stated before, for this to be "fixed" requires a complete rethinking of how we do games on Gentoo, requiring us to make modifications to our eclasses which affect ~750 packages, along with determining how to come up with a clean upgrade path for our users which already have games installed and established on their systems. Needless to say, there's no expectation on this happening any time soon. If you want my opinion on it, I would say we simply mask the packages and let the users decide on their own if the risk is worth it, but I know that this is definitely not the optimal solution, but until we have another workable solution that is agreeable to our members, this will be our current course of action.
What is the reason for having the ability for only certain users to able to run games (ie. the existence of a games group). It would seem that one could start creating groups for all sorts of applications. Is there are group called "office"? Is there a group called "graphics"? Why I need to be in a group called games to play games is a mystery to me. If a sysadmin wanted to restrict the use of "office" applications to certain users, he would have to do some extra work, no? Why not make them do the same thing for games? Chris said: "This has been in place for a long time and is well-received by our users." Why is it well-received? What is so great about it? Tavis said: "what functionality is it that you dont want to remove, the ability to limit who can execute games? I've already suggested how this can be achieved in an email to vapier without breaking high scores, security, etc. I never received any reply though, if you'd like me to bounce you a copy just ping me on irc." Tavis: Why not post this email here?
(In reply to comment #15) > What is the reason for having the ability for only certain users to able to run > games (ie. the existence of a games group). It would seem that one could start > creating groups for all sorts of applications. Is there are group called > "office"? Is there a group called "graphics"? Why I need to be in a group > called games to play games is a mystery to me. If a sysadmin wanted to restrict > the use of "office" applications to certain users, he would have to do some > extra work, no? Why not make them do the same thing for games? Except that I don't care about "office" stuff, since I'm on the games team. Quite frankly, I'm a bit put off by the fact that our policies are under attack like this. Nobody has made any complaints about this policy until this bug came about, and even those people seem to be complaining just to complain. Want a reason why we restrict games to a specific group? How about limiting who can run games that are extremely resource intensive? How about keeping your kids from playing doom3? Need any more reasons? Well, I'm sure you can think of some on your own. The point here is that no matter how much anyone wants our policy to be under fire here, we don't have any intentions on changing it because a few packages behave poorly. > Chris said: "This has been in place for a long time and is well-received by our > users." > > Why is it well-received? What is so great about it? Wow. I just don't even know what to say. Maybe there are people that have a differing opinion than yourself? What's so great about allowing anyone on the system to run as many copies of ut2004-ded out of the box just because you happen to want to run *one* on your server? My point is that any argument you make can have another side to it. Why bother? Also, we are getting *way* off the topic of security here and moving into policy, which is not the point of this bug, at all. Were I to take nethack and patch it to no longer have these vulnerabilities, I would be 100% satisfying the requirements of this bug, so policy changes are not necessarily dictated. We also could remove the insecure package. Again, policy changes are not dictated by this move. > Tavis said: "what functionality is it that you dont want to remove, the ability > to limit who can execute games? I've already suggested how this can be achieved > in an email to vapier without breaking high scores, security, etc. I never > received any reply though, if you'd like me to bounce you a copy just ping me > on irc." > > Tavis: Why not post this email here? Here's the quick and skinny... Add a new group to limit who can play games. Quite simply, it is unworkable, as it would require a revision bump to *every* games package in the tree to ensure they all get the new permissions. I've already stated this, but it seems to be ignored. Now, a *workable* solution would be to create a *new* group and have the games setgid to *that* group, but it would still require locating the games that are affected, and ensuring that the game runs with that gid, while still restricting usage to members of the games group. Again, we have not come to a consensus on what to do abotu this, so continued prodding isn't helping the situation and quite frankly is frustrating us to no end. Please let us come up with a solution on our own time. The game is now masked.
just FYI: two other packages have been masked cause of dependencies... [from package.mask cvs log:] revision 1.5122 date: 2006-03-22 23:30:14 +0100; author: wolf31o2; state: Exp; lines: +2 -1; commitid: 5a584421cff54567; Added games-roguelike/noegnud-nethack due to nethack masking. ---------------------------- revision 1.5121 date: 2006-03-22 23:23:07 +0100; author: wolf31o2; state: Exp; lines: +2 -1; commitid: 63a14421ce4b4567; Masking games-util/hearse since it depends on nethack, which was masked by secur ity.
1) The way to fix this IMO is to make nethack and all it's clones/interfaces setgid to a group called nethack of which nothing else in in particular no users are members (for security), while making the datafiles (leveldescriptions etc) owned by games, without read-permission for others. That way NetHack will fail to start for people who aren't in games, without compromising security. 2) Falconseye is also an interface for nethack (it comes with it's own internal copy of NetHack 3.4.1), but it isn't masked. (Rather offtopic...) Actually I wouln't mind terribly if it were marked for removal: It's been unmaintained for years and there is a successor called vultureseye (of which I am a developer :-). Vultureseye will be releasing 2.0 within the next week or 2 after which I'll be submitting an ebuild for it...
And another: noegnud-slashem is a nethack variant too and no doubt has the same problem...
falconseye is bug 127319
Masking GLSA 200603-23 sent. Moving to enhancement scope pending resolution.
(In reply to comment #16) >Quite frankly, I'm a bit put off by the fact that our policies are under >attack like this. Nobody has made any complaints about this policy until this >bug came about, and even those people seem to be complaining just to complain. No one had reason to complain until the policy broke things. I always felt it was a bit odd, but as long as it didn't inconvenience me I saw no reason to complain. Now it is, so I do. >How about limiting who can run games that are extremely resource intensive? If your problem is resource usage, limiting what resources users have is a better solution. >How about keeping your kids from playing doom3? You could just as well want to stop them watching some movies. And you would implement that yourself, you wouldn't expect the system to do it for you. >The point here is that no matter how much anyone wants our policy to be under >fire here, we don't have any intentions on changing it because a few packages >behave poorly. Then you fix the packages. It's an unusual policy, not done by any other distro afaik, with no noticeable benefits for the vast majority of users, and it's breaking some pretty important (as games go) packages. > Wow. I just don't even know what to say. Maybe there are people that have a > differing opinion than yourself? What's so great about allowing anyone on the > system to run as many copies of ut2004-ded out of the box just because you > happen to want to run *one* on your server? Nothing. But there's nothing particularly wrong with it either - we do it with lots of programs all the time. What's great is being able to play nethack. For me, and I think for the majority of users, the benefits of your policy are not worth making it impossible to (securely) play nethack. > Also, we are getting *way* off the topic of security here and moving into > policy, which is not the point of this bug, at all. Were I to take nethack and > patch it to no longer have these vulnerabilities, I would be 100% satisfying > the requirements of this bug, so policy changes are not necessarily dictated. I suspect if you do that it will be an issue that keeps cropping up. It's not a bug with nethack, it's a bug with your policy. Anyway, changing the policy is an obvious solution - if you think patching it is easier, then by all means go ahead. > We also could remove the insecure package. Again, policy changes are not > dictated by this move. I feel that from a user's point of view, changing the policy would be preferable to removing the package. I repeat, it's not the package that's responsible for the insecurity, it's the policy. > > Here's the quick and skinny... Add a new group to limit who can play games. > > Quite simply, it is unworkable, as it would require a revision bump to *every* > games package in the tree to ensure they all get the new permissions. I don't see how, all it would mean is that users would have to remain in the games group (with the security issues this causes, but we would be no worse off than we are now) until all games had been updated. How was the policy first implemented? Because it seems to me changing the group would be no different. > Please let us come up with a solution on our own > time. The game is now masked. > As a user, that's not an acceptable situation. Why not remove the policy of having games not runnable by those not in the games group until you can figure out a way to reimplement it without causing security issues?
"It's not a bug with nethack...." It absolutely *is* a bug in nethack. Nethack shouldn't write to symlinks and shouldn't blindly read the record file.
(In reply to comment #23) > It absolutely *is* a bug in nethack. Nethack shouldn't write to /sys and > shouldn't blindly read the record file. > How is blindly reading the records file any different from blindly reading its own executable or the libraries it's linked against? In both cases you're just relying on the permissions to ensure it hasn't been maliciously modified.
(In reply to comment #8) >I've already suggested how this can be achieved in an email > to vapier without breaking high scores, security, etc. I never received any > reply though, if you'd like me to bounce you a copy just ping me on irc. > please post your suggestion to this bug, so people can decide if they want to implement this or follow gentoo policy.
I wonder if this policy is maintained, shouldn't we test all games to make sure that all games that overwrite or create files via a symlink are security masked?
(In reply to comment #22) > (In reply to comment #16) > >Quite frankly, I'm a bit put off by the fact that our policies are under >attack like this. Nobody has made any complaints about this policy until this >bug came about, and even those people seem to be complaining just to complain. > > No one had reason to complain until the policy broke things. I always felt it > was a bit odd, but as long as it didn't inconvenience me I saw no reason to > complain. Now it is, so I do. I have to admit that I've always wondered how many people actually prefer the current system. Do we have anything other than anecdotal evidence? > As a user, that's not an acceptable situation. Why not remove the policy of > having games not runnable by those not in the games group until you can figure > out a way to reimplement it without causing security issues? Chris actually did answer this question. Such a change would involve changing every single game in portage, and that's a _lot_ of games (and thus a _lot_ of work). As such, the games team would like to consider alternative solutions before trying to implement sweeping changes.
(In reply to comment #22) > (In reply to comment #16) > >Quite frankly, I'm a bit put off by the fact that our policies are under >attack like this. Nobody has made any complaints about this policy until this >bug came about, and even those people seem to be complaining just to complain. Until a bug came about - people may have been hesitant to complain. > No one had reason to complain until the policy broke things. I always felt it > was a bit odd, but as long as it didn't inconvenience me I saw no reason to > complain. Now it is, so I do. There has been some discussion about this on the forums. The reason games aparently have not heard of it is that we who were discussing realize what a large amount of work is required to fix this - and so have not filed bugs until real bugs were aparent. The gentoo policy causes another related problem: For games that share state or highscore among many player in the fashion of nethack, it is common to share that state over a lan. This breaks in an environment with mixed distros (eg a school). The nethack-group solution will not fix this - because I can still forge the same attack against any other linux/unix flavour (or any other distro) on the same lan. Gentoo's policy also causes problems for people who have nis/ldap enabled on a lan with more than one distro. Ergo, don't mix gentoo with other distros. To say that this policy is well recieved should mean that it has seen praise IMHO. Has it? Here's some earlier discussion: http://forums.gentoo.org/viewtopic-t-346526.html In short, doesn't gentoo break expected behaviour here?
FWIw, I've wondered about the grouping, too. And in the end, if you're trying to restrict access to games, using a games group is the wrong way to do it - there's nothing to stop a user from compiling their own version in their home directory, especially since the toolchain doesn't use a group of its own.
I've always disliked Gentoo's system requiring users to be in games as well, but haven't felt it was a big enough thorn to actively complain. A user can compile a game on their own (there's no 'gcc' group to restrict toolchain use, of course), so it seems like a needless waste of the sysadmin's attention. If we need to limit what our users are doing we can do it via resource limits, quotas, etc.
Guys, please keep in mind that this is a security bug in the first place, not really a discussion board. Also, please have some faith in gentoo: of course the games and security team are currently discussing possible solutions to address this issues. Unfortunately, the said discussion is not very transparent to the community at the moment to make things easier for us, but I expect that this will change after things are well discussed internally. Any further attacking of the gentoo games policy really makes no sense right now, it only sets up the games team. Keep in mind that they introduced the policy with good intentions, so please dont flame them right away if things aren't working like expected. > To say that this policy is well recieved should mean that it has seen praise > IMHO. Has it? Heh, praise is pretty rare. I'd say that usually no complaints are enough to indicate that things are "well received".
After all the flames, I'd like to say I really like the idea that users have to be in a games group before they can play games. This way I can easily allow and disallow certain users to use my computer for games. Unfortunately, it has not been very good implemented: 1. All users in the games group can fiddle with the scores 2. Users not in the games group can still run e.g. gnometris but they have to do some research why their highscores are never saved (yes, I've been there) So I think it would be great if 1. the security bug could be fixed, 2. the scores-issue could be fixed, 3. the mixed distro problem could be fixed and 4. if still possible, the games group would stay.
This bug has a thread in the forums. It's at: http://forums.gentoo.org/viewtopic-t-446415.html It might be best to use the forum for further discussion.
(In reply to comment #16) > Here's the quick and skinny... Add a new group to limit who can play games. > > Quite simply, it is unworkable, as it would require a revision bump to *every* > games package in the tree to ensure they all get the new permissions. I've > already stated this, but it seems to be ignored. Now, a *workable* solution > would be to create a *new* group and have the games setgid to *that* group, but > it would still require locating the games that are affected, and ensuring that > the game runs with that gid, while still restricting usage to members of the > games group. I think a two-group system might be the most workable, where there is one group users must be in to play games, and another group that the games run sgid as to modify saves and score files and such. As per filip's comment (#28), it would be best if we used the games group the same way other linux/unix distros do so as not to break inter-distro compatability. So perhaps we could have the games group be used in the normal way, and create a second group (gamers?) for users to be able to run the games. Now I understand that this would not be the easiest policy to impliment, but it might be worth doing as a long term solution. Furthermore, it might not be as hard as version-bumping every package in the tree. Why not write a helper script that people can run to make the changes? Similar to the way the python team has python-updater for sweeping changes that break things, perhaps there could be a games-update script that would change the permissions on things in /usr/games/bin and take users out of the games group and put them in the gamers group. The games eclass could perhaps then be modified print an enotice to run this script if it hasn't already been run. (I realize it would not be quite that simple, but perhaps it could be a starting point. -Nate
*** Bug 129954 has been marked as a duplicate of this bug. ***
(In reply to comment #34) > As per filip's comment (#28), it would be best if we used the games group the > same way other linux/unix distros do so as not to break inter-distro > compatability. So perhaps we could have the games group be used in the normal > way, and create a second group (gamers?) for users to be able to run the > games. That would have also minimize the changes, as all files installed and accessed by games would stay in the games group. Of course, as the filesystem just changes IDs and does not really store names, the name does not matter that much, but still it makes things somewhat easier. And it has the added benefit that in the worst case, after the change (to the group file) no user will have access to games that were not already updated, as the game is accessible only to games and not to gamers. So the admin would have to install the new revision or run some updater to make the games available again, but until then the system is on the safe side and the admin will learn rather soon that some action is required. The game has to run as one group (requiring gid of file and sgid bit) while access needs to be restricted to another group (at least if we keep that policy). Maybe this can be done by restricting access on the directory instead of the executable? /usr/games is already restricted to the games group (at least on my system), so that should be enough for any game placing its binaries in this tree, as long as you change games to gamers. Perhaps the same technique could be used for other games as well. Almost all games will reside in /usr/games, or in a directory by themselves that can be restricted as well. Only problem are games that have their binaries in the same dir as non-gaming binaries, like games bundled with some desktop environment or the likes (e.g. kdegames). Those would need some work, probably be placed in a games subdir by themselves and for consistency symlinks placed in the main bin dir. Maybe the eclass could provide some check ensuring access restriction. (In reply to comment #16) > Nobody has made any complaints about this policy until this > bug came about, Like comment #22 said, it was not annoying enough to complain, till this bug. Given the choice, I'd drop this group restriction and leave the sysadmin to worry about caging his/her users. > How about keeping your kids from playing doom3? What is going to prevent them from installing things locally, in their home dir, owned by themselves? As long as you have access to the net and even a compiler available, there are easy ways to circumvent the current games permissions.
(In reply to comment #27) > Chris actually did answer this question. Such a change would involve changing > every single game in portage, and that's a _lot_ of games (and thus a _lot_ of > work). As such, the games team would like to consider alternative solutions > before trying to implement sweeping changes. Maybe a lot of work, but must be done, if this is the best solution. Now with the new "Modular X", gentoo devs needed to update many, many ebuilds. I would say at least half of portage had some update regarding of Modular X. With OpenAL splitted to OpenAL and Alut, then many other ebuilds were also updated. Please, don't avoid doing a big change (if it would be the best change) just because it would need a lot of ebuilds to be changed. If this was the case, then we would not have modular X. If Gentoo Games staff is small, then ask help when such big change is needed. I'm sure people can help.
(In reply to comment #36) > What is going to prevent them from installing > things locally, in their home dir, owned by > themselves? noexec?
From how "lively" the discussion has gone so far in this bug, I'm probably risking my neck right now, but here it goes: After half a year of status quo being a hardmasked ebuild, is there any progress on the solution of making nethack and nethack-based games work safely? I'm no coder, but the two groups idea sounds the most logical to me as well.
two groups isn't good enough. we need to fix the games.eclass to create a new user for every game that we want to support in this regard and run the game binaries setuid for that user. The games team has talked about how to fix it but no coding yet. That's not totally accurate, since we *had* code and spanky lost it. ;-)
Thanks for the explanation. It's good to know a bug isn't just forgotten. Hmm, I thought it would be enough to make a new global group (e.g. games-su) instead of making a new group or user for just about every game. I'm pretty sure someone sugested it already. ...but then again, I'm no coder. I better shut my yap before a new flame war comes up and leave you guys to what you do well enough.
What kind of work is being done to fix this, and has any discussion covered the policy and a possible change in the future? I know it was said that some code had been done and lost (out of curiousity, how?), but I'm just curious.
I write a mail to devteam at nethack.org and they replied me the following: We've modified the development code so that future versions of nethack won't be vulnerable to string buffer overflows while reading in the scores file. As far as using the default setup of ``setgid games'' and also making untrusted users be members of the games group, I don't think there's anything we can do about that. NetHack's "playground" directory shouldn't be writable by users, or by programs other than nethack if those programs let users modify arbitrary files. If `games' doesn't meet that requirement, some other group only used by nethack could/should be created and used. ___
so, mm, what are we doing with this bug? Games team, please comment, is it possible to provide a version that would not be vulnerable? thanks
it's on our list.
(In reply to comment #45) > it's on our list. > Must be some pretty long list... it's been over a year and a half. This is getting ridiculous.
Feel free to submit a patch to get it done sooner.
Created attachment 139487 [details, diff] Add bounds checking to fscanf() format strings Well, that took all of half an hour...
Created attachment 139490 [details, diff] Ebuild patch to protect state directory from modification by users And here's a patch to the ebuild to take care of the permissions issue. (Far be it from me to terminate discussion on Gentoo's games policy, though.)
Created attachment 139499 [details, diff] Revised, policy-agnostic version of ebuild patch ...So, to that end, here's a cleaned-up and revised version of the ebuild patch, which can install the game either using the current Gentoo games policy (of putting users into the games group) or the policy followed by other distributions (of treating the games group as privileged). It turns out there are only a couple of changes needed: creating a separate "nethack" group under the Gentoo policy, and selecting the proper group name for file installation. This version of the patch also runs chgrp/chmod on the data and state directories during postinst to fix permissions from any previous install. That part can be dropped if you tell people to unmerge old versions first. (Or is there a way to tell emerge to copy permissions from ${D} to ${ROOT}?)
Thanks Andrew. Games herd, okay to make a revbump including the patches? please advise.
Andrew submitted patches for this almost three months ago. Are there other problems preventing this from being unmasked? The bug has been out there for two years (and one day) now. Additionally, how is this only classified as an "Enhancement" bug? If this is a big enough problem to have the game masked for two years, shouldn't that be "Major," according to the description "major loss of function?"
(In reply to comment #52) > Andrew submitted patches for this almost three months ago. Are there other > problems preventing this from being unmasked? The bug has been out there for > two years (and one day) now. > > Additionally, how is this only classified as an "Enhancement" bug? If this is a > big enough problem to have the game masked for two years, shouldn't that be > "Major," according to the description "major loss of function?" > It's not only a question of the bug itself, it's that we didn't have a proper fix. Since a GLSA was released and the game was masked, but we couldn't just close the bug because it is not fixed. Therefore, it was left open but severity was decreased to "enhancement", which pretty much means "no stable package is vulnerable, so this is not a priority anymore, maybe it could be fixed when someone cares enough to write a patch". Now, someone actually wrote a patch. Games herd, are you ok to include it? please advise.
Being masked isn't a "major loss of function" but rather an intentional change made to specify the current state of the ebuild. Also, I *really* dislike the idea of putting out an ebuild that violates the policy we've put in place, and can pretty much guarantee that this wouldn't be accepted, as is. Rather, a more generalized solution should likely be used and put in the games.eclass, instead of in individual ebuilds. Otherwise, this whole thing comes crashing down as soon as someone installs any other game from the tree. Also, not running prepgamesdirs isn't really acceptable. Either change prepgamesdirs or do the chmods after, don't drop it.
Created attachment 146573 [details, diff] Revised ebuild patch that runs prepgamesdirs I don't currently have time to dig into games.eclass due to work obligations, but here's a revised version of the patch that runs prepgamesdirs as requested (overriding file ownership/permissions afterwards). For when I do have time, what sort of generalized solution would you be looking for? Setting policy issues aside for the moment, perhaps a variable that indicates whether a game needs its own group? Something like # For games that need their own groups GAME_PRIVATE_GROUP="nethack" pkg_setup() { games_pkg_setup # runs enewgroup ${GAME_PRIVATE_GROUP} } src_install() { prepgamesdirs # does chgrp ${GAME_PRIVATE_GROUP} on relevant directories } # For games that don't need a private group GAME_PRIVATE_GROUP="" pkg_setup() { games_pkg_setup # does nothing special } src_install() { prepgamesdirs # does chgrp ${GAMES_GROUP} on relevant directories }
I just submitted Andrew's scanf format checking fix to the patches area of Nethack's sourceforge page: <http://sourceforge.net/tracker/index.php?func=detail&aid=1949698&group_id=196&atid=300196>
Not one to moan, but this has been state of play for over two years now, little things like this are waht gives the bad reputation. So rather than moaning, whats needs to be done to get this out onto the tree properly
Looking for some clarification as to the currently considered "correct" fix for this. As it stands now, the sgid proposal (make a private group for games such as nethack which control shared files) clashes with the normal use of the games group (well, normal for Gentoo at least) since only one group can be assigned to the executable. Bones mentioned creating a privileged USER instead of group... which makes sense, but only if nethack doesn't make decisions based on the effective-user (e.g. saved games need to be tied to the "actual" user instead of the suid user, somehow). If we can get an official say at this point about the right fix, there may be some people in the woodwork annoyed enough about not getting their shot of roguelike to do the actual coding (Andrew's code will probably help, but he's already said he doesn't have the cycles to rewrite games.eclass).
(In reply to comment #58) > As it stands now, the sgid proposal (make a private group for games such > as nethack which control shared files) clashes with the normal use of the > games group (well, normal for Gentoo at least) since only one group can be > assigned to the executable. As an alternativ to switching from sgid to suid, as you proposed and as would probably involve lots of changes, there is still my suggestion from comment #36 to have different groups assigned to directory and binary, so that the binary can be sgid games in the nethack sense, while a suitable parent directory like /usr/games can be access restricted to games in the Gentoo sense. Of course one of these groups needs a different name.
Out of curiosity, it's been another year since the last comment was posted here, and the packages are /still/ masked. What is the status of this bug and/or the policy? Has any headway been made toward a full solution, or is there somewhere users can find out the status, or volunteer to help on solving this bug?
Sorry to add nothing more than another "me too," but please could we get an update on the status of this? Thanks.
Hi, I hate to add gasoline to the fire, but it's been a long time since this bug was opened, I want to help getting it fixed. I agree with others here that the policy Gentoo uses for games is incompatible with all other distros and with what games expect. Gentoo has always assumed that the user/sysadmin is the guy that actually knows what's best for his system, and I think that the current games policy clashes with this idea. I love the fact that Gentoo gives me the power, and I think most users like Gentoo for exactly that reason. So, in the current case, I think that actually a policy change would be the best solution. We can add a 'gaming' group for restricting access to games. I don't mean to criticize the games devs, I know that they did this with the best intentions, but I think that following the standard behavior of other distros will benefit Gentoo in the long run. It sure is a lot of work to do, and I am volunteering myself to help, but it can also be spread in time, and, as suggested earlier, we could have a script to execute changes for the users. NetHack being masked has annoyed me a bit, especially because probably in most cases, like mine, there is only one user in the system anyway.
(In reply to comment #18) > 1) The way to fix this IMO is to make nethack and all it's clones/interfaces > setgid to a group called nethack of which nothing else in in particular no > users are members (for security Why isn't this solution discussed or used? This stupid bug has been here since four years. If nethack had a way to specify the save/highscore groups name at compile time we would just use that because all there really is to this issue is a naming conflict, right?
Seeing as "the games and security team [have been] discussing possible solutions" (comment #31) for four years without a fix, let me ask the following. Is there any reason why: 1) my patches (attached to this bug) cannot be applied? 2a) At least one of the general solutions mentioned in comment #36 and comment #40 cannot be applied? -or- 2b) A second bug cannot be opened for discussion of games policy, and this one closed as resolved? I have a bit of free time at the moment, so I can investigate what changes would be required for a general solution, but with all due respect, I'm reluctant to make such a time investment without some indication that the results would actually be used.
Hi all, Is there still anyone in the gentoo security or game team? It seems not. Is there still any maintener ? Unfortunatly I will never know the answer because there is nobody to answer it. It's too pity, there are some volunteers to get the work done but nobody to answer us after 4 years. Fine example of maintaining the distro.
(In reply to comment #65) > Hi all, > > Is there still anyone in the gentoo security or game team? It seems not. There are, but we have higher priorities than fixing games. The sort of message you have posted does everything but making things go faster.
(In reply to comment #66) > > There are, but we have higher priorities than fixing games. > The sort of message you have posted does everything but making things go > faster. I agree the sentiment from the previous poster is not exactly helpful, but it's perfectly understandable. This bug /has been open for three years plus/ /with patches to fix the problem/ and yet /no action has been taken/ by either the security or games teams in that entire time. Now on to more constructive statements: may I sincerely and politely ask what other "higher priorities" the games team have other than maintaining games? If they are short on manpower, I would gladly donate my time to help issues such as this. If there is no one available to fix the issue on the team, perhaps one of us (yes, I'm volunteering if necessary) could be given privileges to fix the package/packages ourselves? A bug like this being left open for so long is a bit beyond silly -- especially when there's a patch ready in the wings to fix the problem.
(In reply to comment #66) > The sort of message you have posted does everything but making things go > faster. > Oh, I'm not agree with you. This message brought out a maintainer after 2 years of silence :) Nothing makes me happier than you make me lie Ok, I'am not very nice with you and my favorite distro but I'm a volunteer to help by all means.
(In reply to comment #67) > Now on to more constructive statements: may I sincerely and politely ask what > other "higher priorities" the games team have other than maintaining games? I am obviously not with the games team. > If they are short on manpower, I would gladly donate my time to help issues such > as this. If there is no one available to fix the issue on the team, perhaps one > of us (yes, I'm volunteering if necessary) could be given privileges to fix the > package/packages ourselves? The Games team has a project page, an email address (games@gentoo.org) and an IRC channel. Please concact these people and ask about recruiting. Another option might be proxy maintenance (http://dev.gentoo.org/~antarus/projects/proxy-maint/) for the package.
This bug has launched a great debate. It continues and it is desirable that a maximum of one vote on the matter to unlock the topic. Post your vote on : http://forums.gentoo.org/viewtopic-t-822175.html
This bug will soon celebrate its 5th birthday! Any news from the games herd?
Here's an idea: Why not set the statedir to something like ~/.nethack/state/? I doubt a lot of people would mind loosing locally shared scores and bones…
Part of the fun of bones on a multi-user system is stumbling onto the bones file of one of the other users of that system. However, I think most people are on single-user systems, so your suggestion has merit.
So what about a (masked) useflag that would restore the old behavior then?
(In reply to comment #74) > So what about a (masked) useflag that would restore the old behavior then? Why not, we already have flags like SECURITY_HAZARD. Could someone from the games or security herd comment on my suggestion?
Ping…
Hmm, maybe I should start thinking about a 5th birthday present for this bug...
What's wrong with "set the statedir to something like ~/.nethack/state/?" It seems very easy to do and I think it should works!
(In reply to comment #78) > What's wrong with "set the statedir to something like ~/.nethack/state/?" > It seems very easy to do and I think it should works! Because then you wouldn't be sharing your bones/stats files.
Who cares if the alternative is keeping this masked forever.
(In reply to comment #79) > (In reply to comment #78) > > What's wrong with "set the statedir to something like ~/.nethack/state/?" > > It seems very easy to do and I think it should works! > > Because then you wouldn't be sharing your bones/stats files. There wasn't found better solutions in last 5+ years... So, it can be easily fixed now. Then we can open bug about security&games in gentoo (it seems, that all games that saves high-scores(or some thing else) not in user folders are possible vulnerable).
Happy (belated) 6th birthday!
Happy 8th birthday!
Not as long as I thought. In that case we still have 2 years to make up something to celebrate ;)
Can we get rid of the games group now? It's broken and pointless. And I would like to see this bug fixed in my lifetime.
I'd say: 1. rename the games group to gamers 2. introduce a (new) games group which behaves like in other distros. This may be simply said, but if we like to solve this issue and still be able to authorize people (gamers) to play games, this might be the way to go...
I was under the impression that, given the forum post linked to in comment 70, the community voted for a solution incompatible with Nethack’s design, thus ensuring this bug would never be fixed.
I missed that forum, so +1 to option 3 :) I think this bug really is about gamers (not admins) being able to tamper with scores etc. The nethack issue is just a nasty side effect with serious security implications. People voting for option 1 & 3 are voting for keeping the authorization for playing games which is 44+23=67%. People voting for option 2 & 3 are voting for handling the games group like in other distros which is 20+23=43% People voting for option 1 are not bothered by handling the games group like in other distros as long as the authorization for playing games persists. So clearly, option 3 is the best way to go, starting with renaming the games group to gamers. Handling the new games group like in other distros would be the second phase. However, I don't think Gentoo developers are motivated enough to organize the renaming of the games group in the first place (no offence, but prove me wrong), since this implies: - updating all ebuilds which use the games group *at once* - creating a news item instructing how to rename the games group
(In reply to Evert from comment #88) > - updating all ebuilds which use the games group *at once* Modifying the ebuild should go a long way here. So far games binaries were installed as group games and mode -rwxr-x---. This should change to -rwxr-xr-x for most games but to -rwxr-sr-x for those which need to maintain highscores. So a first step would be modifying gamesperms() to include execute permission for everybody. Of course, doing this before the user did the migration will open a window where the games become available to everybody. You could add an additional check in that function, see whether the migration has already happened (e.g. whether the gamers group does exist, or the existence of some marker ) and issue a warning and revert to old behavior otherwise. There might be ebuilds which don't use gamesperms(). Those will install their files with restricted privileges, so users can file bug reports about those we missed but there shouldn't be much of a security problem there. Of course some testing up front to see which packages are likely to be affected wouldn't go amiss. > - creating a news item instructing how to rename the games group I guess there should be a script to do the work here: 1. Create gamers group. 2. Change permissions on /usr/games to only allow gamers. 3. Move all members of games group to gamers group, at least on standard shadow auth systems. Users of LDAP and the likes will need manual intervention here. 4. Mass chmod files in /usr/games which belong to games group to become executable by everybody; this avoids having to rebuild everything. Sure, there should be a news item, but for most people the essence of that should be “run that script and everything will be fine”. Note that there should imo be no renaming of the group: the GID for the games group should stay the same, since otherwise we'd have to also change the group of all installed games to match the new GID.
(In reply to Martin von Gagern from comment #89) > > - updating all ebuilds which use the games group *at once* > Modifying the ebuild should go a long way here. ECLASS is what I meant here, sorry.
(In reply to Jeroen Roovers from comment #79) > (In reply to comment #78) > > What's wrong with "set the statedir to something like ~/.nethack/state/?" > > It seems very easy to do and I think it should works! > > Because then you wouldn't be sharing your bones/stats files. From what I read users care more about security than they care about sharing bones/stats files. Since any other solution will take more time and manpower and there was no action since quite a few years, I will apply the suggestion from comment #78 in 2 weeks, unless someone can come up with a better solution.
https://github.com/hasufell/games-overlay/commit/852cec4e0be6b639717c9db2646881ea7be9d5dd https://github.com/hasufell/games-overlay/commit/887e22964aafd494d35137e23a6ad40d2763b9d8
(In reply to Jeroen Roovers from comment #79) > (In reply to comment #78) > > What's wrong with "set the statedir to something like ~/.nethack/state/?" > > It seems very easy to do and I think it should works! > > Because then you wouldn't be sharing your bones/stats files. Given that this is a security bug and your concern about this proposal is user experience related, it is not relevant to this bug. Proposal: Fix the security bug (e.g. comment 78 and 92) so that this bug can be closed and nethack unmasked. This will result in impaired UX (sharing bones/stats) and a new non-hardmasking bug can be opened against nethack to find a way to restore that functionality. Yes, that means for a period of time people wont be able to share bones/stats files, but that has been the status quo for 9 years now (you can't have bones/stats files to share if you cannot install the game in the first place).
With the pending package removal, Luis has offered to take up proxy maintenance and fix the security issue. A new version (3.4.3-r2) is pushed to the tree which should resolve this issue. I'd like someone to verify if this is indeed the case. The package uses its own GID and does not use the games eclass anymore. If so, then I'll adjust the p.mask to only refer to previous versions.
I've confirmed that 3.4.3-r2 installs under group nethack and appears to run correctly (including storing user data under the group-owned directory /var/lib/nethack). One issue to note is that any data which was saved under /var/games/nethack will get deleted as part of the upgrade (unless put under CONFIG_PROTECT, presumably).
Belatedly (sorry for spam), it does _not_ appear that this bug is fixed -- the new ebuild does not add any new patches, and the patch attached to this bug still applies cleanly to the unpacked source.
(In reply to Andrew Church from comment #95) > One issue to note is that any data which was saved under /var/games/nethack > will get deleted as part of the upgrade (unless put under CONFIG_PROTECT, > presumably). Good catch. I'll see if I can fix this.
(In reply to Andrew Church from comment #96) > Belatedly (sorry for spam), it does _not_ appear that this bug is fixed -- > the new ebuild does not add any new patches, and the patch attached to this > bug still applies cleanly to the unpacked source. The savegame parser is still insecure, yes. It might be a good idea to apply the patch. I'll check if and how upstream dealt with this problem. However, the vulnerability *has* been fixed by my ebuild bump -- it requires the creation of specially-crafted save files in /var/lib/nethack, and this directory is only writeable by root and the nethack group (which is supposed to be empty). The only way for users to create save files is by executing nethack and saving a game.
(In reply to Luis Ressel from comment #98) > However, the vulnerability *has* been fixed by my ebuild bump -- it requires > the creation of specially-crafted save files in /var/lib/nethack, and this > directory is only writeable by root and the nethack group (which is supposed > to be empty). > > The only way for users to create save files is by executing nethack and > saving a game. Fair enough. I can confirm the shared directory and the record file are not user-writable (assuming the user is not in the nethack group): $ ls -ld /var/lib/nethack drwxrwx--- 3 root nethack 4096 Feb 20 02:18 /var/lib/nethack $ sudo ls -l /var/lib/nethack/record -rw-rw---- 1 root nethack 0 Feb 20 00:59 record
I can confirm this bump fixes the security issue. The group nethack has no members, the game runs as group nethack and can read and write save and no user can list,edit,create,etc files within /var/lib/nethack. While this may not change nethacks internal behavior, it does fix the vulnerability as described in the CVE: "The configuration of NetHack 3.4.3-r1 [...] and earlier on Gentoo Linux allows local users in the games group to modify saved games files to execute arbitrary code via buffer overflows and overwrite arbitrary files via symlink attacks." Local users can no longer modify saved games and cannot create symlinks in sensitive locations, making the buffer overflow unavailable for exploitation. As this CVE is addressed, this bug should be well on its way to be closed as resolved.
Luis, thank you for taking over proxy maintenance for this package. Also, thank you to all the developers and contributors for your coordination and feedback. Maintainers: if the intention is to unmask nethack, please drop the vulnerable version from the tree.
(In reply to Luis Ressel from comment #98) > However, the vulnerability *has* been fixed by my ebuild bump -- it requires > the creation of specially-crafted save files in /var/lib/nethack, and this > directory is only writeable by root and the nethack group (which is supposed > to be empty). I am surprised that one day after the QA team has adopted a new policy, a solution that disregards it is installed. Please create the savegame files in /var/games/nethack and use the "gamestat" group, gid 36 for them. QA policy reference: https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#Games
More QA violations in -r2: - The "nethack" binary is installed in /usr/share/. - chgrp/chmod used in src_install, instead of fowners/fperms. - Several "|| die" missing.
(In reply to Ulrich Müller from comment #103) > More QA violations in -r2: > - The "nethack" binary is installed in /usr/share/. I'm aware of this issue and will fix it. > - chgrp/chmod used in src_install, instead of fowners/fperms. > - Several "|| die" missing. I'll have a look.
(In reply to Ulrich Müller from comment #102) > (In reply to Luis Ressel from comment #98) > > However, the vulnerability *has* been fixed by my ebuild bump -- it requires > > the creation of specially-crafted save files in /var/lib/nethack, and this > > directory is only writeable by root and the nethack group (which is supposed > > to be empty). > > I am surprised that one day after the QA team has adopted a new policy, a > solution that disregards it is installed. Please create the savegame files > in /var/games/nethack and use the "gamestat" group, gid 36 for them. > > QA policy reference: > https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#Games This shouldn't come as a surprise. First of all, as you might not have noticed, I've created the new ebuild revision a month ago -- the referenced policy wasn't in place back then. Secondly, I don't see any announcement of said policy on gentoo-dev. How is anyone supposed to know about new QA policies if they aren't announced? However, the new policy makes sense to me. I'll adapt the ebuild accordingly.
(In reply to Luis Ressel from comment #105) > This shouldn't come as a surprise. First of all, as you might not have > noticed, I've created the new ebuild revision a month ago -- the referenced > policy wasn't in place back then. > Secondly, I don't see any announcement of said policy on gentoo-dev. How is > anyone supposed to know about new QA policies if they aren't announced? I had sent the announcement to gentoo-dev-announce and gentoo-dev mailing lists yesterday (and a followup today), but unfortunately lists are currently down. > However, the new policy makes sense to me. I'll adapt the ebuild accordingly. Thank you. Please note that for the time being I've double-masked -r2 by removing its KEYWORDS, so that users don't get the nethack group created on their systems. (Because removing it again would require manual intervention.)
(In reply to Ulrich Müller from comment #106) > Thank you. Please note that for the time being I've double-masked -r2 by > removing its KEYWORDS, so that users don't get the nethack group created on > their systems. (Because removing it again would require manual intervention.) Thanks.
Luis provided an updated ebuild that takes care of the mentioned remarks. It's committed as -r3. The older ebuilds have been removed from the tree. If there are no objections, I'll remove the p.mask for nethack as well with reference to this bug in the commit message.
I can confirm that nethack-3.4.3-r3 installs correctly under group "gamestat", shared data is not writable by users (like -r2), and any shared data previously stored in /var/games/nethack with <=3.4.3-r1 (using group "games") is properly migrated to the new gamestat group. Thanks to all involved in updating the ebuild!
nethack is removed from package.mask.
(In reply to Sven Vermeulen from comment #110) > nethack is removed from package.mask. games-util/hearse is still masked. However, from comment #17 I conclude that it has no security issues of its own, but was only masked as a reverse dependency: > revision 1.5121 > date: 2006-03-22 23:23:07 +0100; author: wolf31o2; state: Exp; lines: +2 > -1; > commitid: 63a14421ce4b4567; > Masking games-util/hearse since it depends on nethack, which was masked by > security. Could someone please confirm that this package can be unmasked?
(In reply to Ulrich Müller from comment #111) > (In reply to Sven Vermeulen from comment #110) > > nethack is removed from package.mask. > > games-util/hearse is still masked. However, from comment #17 I conclude that > it has no security issues of its own, but was only masked as a reverse > dependency: > > > revision 1.5121 > > date: 2006-03-22 23:23:07 +0100; author: wolf31o2; state: Exp; lines: +2 > > -1; > > commitid: 63a14421ce4b4567; > > Masking games-util/hearse since it depends on nethack, which was masked by > > security. > > Could someone please confirm that this package can be unmasked? I'm not sure if hearse should be unmasked. For those of you who don't know Nethack: Nethack keeps two kinds of save files: Normal save files and so called "bones" files. Both are basically memory dumps with an highly unstable format. The CVE-2006-1390 vulnerability is about achieving buffer overflows by tampering with save files, so it's not directly applicable to hearse (which is downloading "bones" files from the internet). However, considering the nethack codebase is quite old and wasn't written with security in mind, it's quite imaginable that similar attacks can be carried out by tampering with bones files. If that's the case, hearse users would be extremly exposed to such attacks. Even if hearse is unmasked, I'd strongly recommend not to use it. If you want bones sharing, use a public nethack server.
Several people who are quite knowledgeable about the nethack sources confirmed that the bones parser probably contains dozens of vulnerabilities. I could provide examples if someone's interested. Hearse definitly shouldn't be unmasked.
(In reply to Luis Ressel from comment #113) > Hearse definitly shouldn't be unmasked. I have filed bug 541272 for games-util/hearse, so the security team can proceed here with nethack only.
