Bug 187353 - (CVE-2006-1390) CVE-2006-1390 nethack: Local privilege escalation via crafted score file
CVE-2006-1390 nethack: Local privilege escalation via crafted score file
Status: CLOSED WONTFIX
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
:
Depends On:
Blocks: 187382
  Show dependency treegraph
 
Reported: 2006-03-30 06:56 EST by Hans de Goede
Modified: 2015-03-02 05:30 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-01 12:42:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Hans de Goede 2006-03-30 06:56:45 EST
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/
Comment 1 Karen Pease 2006-03-30 13:00:47 EST
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. 
   
Comment 2 Luke Macken 2006-03-30 14:22:33 EST
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.
Comment 3 Hans de Goede 2006-05-11 08:34:06 EDT
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.
Comment 4 Luke Macken 2006-06-05 13:53:24 EDT
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.
Comment 5 Bug Zapper 2008-04-03 13:11:10 EDT
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.
Comment 6 Hans de Goede 2008-04-04 05:33:37 EDT
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.
Comment 7 Luke Macken 2008-04-04 07:23:48 EDT
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."
Comment 8 Hans de Goede 2008-04-04 07:30:27 EDT
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.
Comment 9 Jon Stanley 2008-04-04 08:16:16 EDT
Changing product to Security Response
Comment 10 Luke Macken 2008-04-04 09:44:40 EDT
(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 ?
Comment 11 Hans de Goede 2008-04-04 10:19:01 EDT
(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.
Comment 12 Greg Metcalfe 2008-04-04 13:44:34 EDT
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.
Comment 13 Luke Macken 2008-04-04 14:15:17 EDT
(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.
Comment 14 Greg Metcalfe 2008-04-04 15:09:23 EDT
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. 
Comment 15 Luke Macken 2009-03-15 16:42:19 EDT
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 :)
Comment 16 Hans de Goede 2009-03-16 05:46:03 EDT
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.
Comment 17 Luke Macken 2009-07-01 12:42:35 EDT
Closing per mutual agreement.

Note You need to log in before you can comment on or make changes to this bug.