This probably isn't an issue under FE non the less this should be fixed since even though we use sgid games and don't add users to the games group a user who manages to get games group rights by exploiting (another?) game could still use this as an attack vector. Unlikely I know. See: http://lwn.net/Alerts/177009/
I'm not quite understanding that security alert. Where is the execution of arbitrary code coming into play here? Is there a buffer overflow or something? The alert doesn't say. If anything, it sounds like an issue with the nethack and slash'em cores, which we have no control over.
This is an issue concerning Gentoo's game policy, and not nethack itself: http://bugs.gentoo.org/show_bug.cgi?id=125902 Sure, if somehow a user joins the games group, then there is potential for arbitrary code execution with the privileges of the user playing nethack. The default installation of Fedora and our Nethack package are not vulnerable to this issue. Smells like WONTFIX to me.
Although users are not in the games group on Fedora this is still a problem, this hole allows the following scenario: - find a sgid game which is exploitable to get games gid rights - use the games gid rights to drop a crafted file which will exploit nethack when opened by nethack. - once another users runs nethack and opens the crafted file unwanted things get done with the rights of the other user. So although low priority this needs fixing never the less.
I agree that this is an issue with NetHack and needs to be fixed. After quickly looking around, I don't believe a patch for this has been written yet (I could be wrong). CC'ing fedora-security-list.
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
AFAIK (might have get fixed through upstream) this bug is still present in rawhide, gentoo has a patch for this here: http://bugs.gentoo.org/attachment.cgi?id=139487&action=view Worth fixing, not sure if its worth marking the fix security though IMHO.
From upstream: " We could probably extract the relevant changes, but I don't think that you actually need them. The real security bug is being caused by gentoo's policy of giving users full access to the same group as nethack's setgid setting. They shot themselves in the foot here, by allowing users to modify the score file outside of nethack. The lax buffer handling has been (or will be, from a 3.4.3 perspective...) fixed, but it is not exploitable in a standard installation where nethack runs in a group whose files can't be manipulated by arbitrary users. I assume that redhat/fedora doesn't have the same config issue as gentoo. If I'm wrong, then you should change nethack to run in a distinct group rather than--or in addition to-- patching its score file parsing code."
From me (repeating myself from comment #3): Although users are not in the games group on Fedora this is still a problem, this hole allows the following scenario: - find a sgid game which is exploitable to get games gid rights - use the games gid rights to drop a crafted file which will exploit nethack when opened by nethack. - once another users runs nethack and opens the crafted file unwanted things get done with the rights of the other user. So although low priority this needs fixing never the less.
Changing product to Security Response
(In reply to comment #8) > From me (repeating myself from comment #3): > > Although users are not in the games group on Fedora this is still a problem, > this hole allows the following scenario: > - find a sgid game which is exploitable to get games gid rights > - use the games gid rights to drop a crafted file which will > exploit nethack when opened by nethack. > - once another users runs nethack and opens the crafted file > unwanted things get done with the rights of the other user. > > So although low priority this needs fixing never the less. So, do you think we should try and get the patch from upstream, or do the same thing that you did with vultures eye and create a separate 'nethack' group ?
(In reply to comment #10) > (In reply to comment #8) > > From me (repeating myself from comment #3): > > > > Although users are not in the games group on Fedora this is still a problem, > > this hole allows the following scenario: > > - find a sgid game which is exploitable to get games gid rights > > - use the games gid rights to drop a crafted file which will > > exploit nethack when opened by nethack. > > - once another users runs nethack and opens the crafted file > > unwanted things get done with the rights of the other user. > > > > So although low priority this needs fixing never the less. > > So, do you think we should try and get the patch from upstream, or do the same > thing that you did with vultures eye and create a separate 'nethack' group ? I vote for creating a seperate group, because AFAIK nethack needs several files under /var/games and opens / close these several times during one run of the game, making early sgid dropping, as we do with other games impossible (or atleast quite hard todo), so putting it in its own group probably is best. For more on the early sgid dropping we do, see: http://fedoraproject.org/wiki/SIGs/Games/Packaging#head-193b9a502a42098e62591d036ad9f428bb5e3474 The idea here is that if even if one manages to subvert a sgid games game, one does still not have access to gid games rights, as those have been dropt, so the damaged for a subverted game is limited to write access to that games highscore file.
My group count is already up to 60, with one user. IMHO, adding another for some random game is not optimal. It only life makes life harder for people writing system profiling/hardening/management tools, and systems administrators that would like to use them to manage groups of machines. A best practice for *writing* SUID/SGID programs is to use those privileges as early as possible, then revoke them. If nethack isn't doing that, I have to wonder what other problems it might have, and whether I should allow it on the system at all. I just installed it, and got this error, as I have no /etc/X11/fontpath.d/: ln: creating symbolic link `/etc/X11/fontpath.d/nethack': No such file or directory error: %post(nethack-3.4.3-16.fc7.i386) scriptlet failed, exit status 1 Installed: nethack.i386 0:3.4.3-16.fc7 Complete! So, another problem. I started it, and find the following files in var/games/nethack: -rw-rw-r-- 1 root games 0 2008-01-23 12:48 logfile -rw-rw-r-- 1 root games 0 2008-01-23 12:48 perm -rw-rw-r-- 1 root games 0 2008-01-23 12:48 record drwxrwxr-x 2 root games 4096 2008-01-23 12:48 save I quit, and logfile contains: 3.4.3 0 0 1 1 14 14 0 20080404 20080404 500 Pri Hum Fem Cha gregm,quit So it does have to write into /var/log, as current designed. Some other characteristics of the executable: $ eu-readelf -l /usr/games/nethack-3.4.3/nethack | fgrep STACK | awk '{ print $7 }' RW eu-readelf -d /usr/games/nethack-3.4.3/nethack | fgrep -q TEXTREL exits with 1, so the program contains no text relocations. So at least those bits are OK. But I wonder if this program couldn't have been better written, to use /tmp, then call a logger before exit. I just don't like the idea of adding yet another group for some random game.
(In reply to comment #12) > I just installed it, and got this error, as I have no /etc/X11/fontpath.d/: > ln: creating symbolic link `/etc/X11/fontpath.d/nethack': No such file or directory > error: %post(nethack-3.4.3-16.fc7.i386) scriptlet failed, exit status 1 > Installed: nethack.i386 0:3.4.3-16.fc7 > Complete! Oops! I fixed this a couple of months ago, but never pushed an update out. http://admin.fedoraproject.org/updates/F7/pending/nethack-3.4.3-17.fc7 Should fix that issue.
yum localinstall failed w/ "Package nethack-3.4.3-17.fc7.i386.rpm is not signed", but it went in via rpm. Link problem fixed.
Reply from nethack upstream about this issue, and the potential rumour that it has been fixed upstream. """ > Someone in the Gentoo community mentioned a while back that the > dev team had patched the buffer overflow. We could probably extract the relevant changes, but I don't think that you actually need them. The real security bug is being caused by gentoo's policy of giving users full access to the same group as nethack's setgid setting. They shot themselves in the foot here, by allowing users to modify the score file outside of nethack. The lax buffer handling has been (or will be, from a 3.4.3 perspective...) fixed, but it is not exploitable in a standard installation where nethack runs in a group whose files can't be manipulated by arbitrary users. I assume that redhat/fedora doesn't have the same config issue as gentoo. If I'm wrong, then you should change nethack to run in a distinct group rather than--or in addition to-- patching its score file parsing code. """ +1 for closing this bug :)
As explained in Comment #3, we could still be (indirectly) vulnerable, with that said since clearly no-one seems to have the time to work on this and it is very minor I'm fine with closing it.
Closing per mutual agreement.