Bug 24339 - Multiple xconq vulnerabilities
Summary: Multiple xconq vulnerabilities
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Powertools
Classification: Retired
Component: xconq
Version: 7.0
Hardware: All
OS: Linux
high
medium
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-01-19 06:26 UTC by Stan Bubrouski
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2001-01-19 07:52:06 UTC
Embargoed:


Attachments (Terms of Use)

Description Stan Bubrouski 2001-01-19 06:26:08 UTC
I've documented this before back in May or June of last year on Bugtraq
and I thought I reported problems here as well, but I guess not.  Since
time someone who saw my post to Bugtraq wrote an exploit which yeilds
egid games.

    xconq is sgid games and it was never meant to be, the code only checks
    assumes that xconq is being run as user games, and never considers
    being run as group games.  From xconq-7.3.3/x11/xconq.c:
-----------------------------------------------------
int
main(int argc, char *argv[])
{
    extern uid_t games_uid;

    use_stdio = TRUE;
    /* Dummy reference to get libraries pulled in */
    if (argc == -1)
      cmd_error(NULL, NULL);
    /* Shift to being the user that started the game. */
    games_uid = geteuid();
    setuid(getuid());

-----------------------------------------------------
    So xconq never drops it's sgid privilages, leaving endless holes due to
    numerous buffer overflows etc...Example overflow:
-----------------------------------------------------
[stan@linux stan]# export XCONQLIB=`perl -e'print "A" x 20000;'`
[root@linux stan]# gdb /usr/games/xconq
...
(gdb) run
Starting program: /usr/games/xconq
[New Thread 1024 (LWP 14721)]
[New Thread 2049 (LWP 14726)]
[New Thread 1026 (LWP 14728)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 14721)]
0x804bbd2 in tk_library_paths ()
(gdb) bt
#0  0x804bbd2 in tk_library_paths ()
#1  0x41414141 in ?? ()
Cannot access memory at address 0x41414141
(gdb)
-----------------------------------------------------
And a look at tk_library_paths() reveals:


tk_library_paths(ClientData cldata, Tcl_Interp *interp, int argc, char *argv[])
{
    char buf[500];
    LibraryPath *path;

    strcpy(buf, "");
    for_all_library_paths(path) {
        /* Use semicolons as separators, for the benefit of split. */
        /* (It would be clever to to use a char known not to be in any
           of the paths, but only do that much work when it proves
           necessary). */
        if (!empty_string(buf))
          strcat(buf, ";");
        strcat(buf, path->path);
    }
    sprintf(interp->result, "%s", buf);
    return TCL_OK;
}


That code itself isn't safe but there are several other places I've found
in the past which lacked bounds checking and allowed overflows

And what's more there is a symlink vulnerability in xconq as well:
------------------------------------------------------------------

[stan@linux stan]$ touch /tmp/smashme
[stan@linux stan]$ ls -al /tmp/smashme
-rw-r--r--    1 stan     stan            0 Jan 18 23:34 /tmp/smashme

[stan@linux stan]$ ln -s /tmp/smashme Xconq.Warnings
[stan@linux stan]$ /usr/games/xconq -host `perl -e'print "A" x 10000;'`
-host is currently broken, use interactive setup for network games

              Welcome to X11 Xconq version 7.3.3 (Jun 2000)

Xconq is free software and you are welcome to distribute copies of it
under certain conditions; type "o copying" to see the conditions.
There is absolutely no warranty for Xconq; type "o warranty" for details.
Warning: Can't find module "standard" anywhere.
Error: no unit types have been defined.
[stan@linux stan]$ ls -al /tmp/smashme
-rw-r--r--    1 stan     stan           88 Jan 18 23:35 /tmp/smashme
[stan@linux stan]$ cat /tmp/smashme
INIT: Can't find module "standard" anywhere
INIT ERROR: no unit types have been defined
[stan@linux stan]$
----------------------------------------------------------------------

    Notice not only the symlink is followed but the group of the file is
    games because xconq never drops it's privilages.  The symlink problem
    is limited by the fact the file is created in the directory xconq was
    executed from, so as long as it's not being executed in a world
    writable directory, it's not too dangerous.  But it does however give
    users the ability to overwrite files writable by user games.

    Command line arguments too suffer from overflows:
----------------------------------------------------------------------

[stan@linux stan]$ /usr/games/xconq -g `perl -e'print "A" x 100000;'`

              Welcome to X11 Xconq version 7.3.3 (Jun 2000)

Xconq is free software and you are welcome to distribute copies of it
under certain conditions; type "o copying" to see the conditions.
There is absolutely no warranty for Xconq; type "o warranty" for details.
Segmentation fault

----------------------------------------------------------------------

    Beyond the above vulnerabilities there remains the fact the game allows
    users to define what dir to look for the game's library in, config
    files, and even lets users define game files.  It does all this and
    never drops privilages.  This in and of itself opens up many potential
    problems as of yet undiscovered.


With this information I would recommend that the sgid bit be removed from
the xconq binary until the software is properly audited or improved.  I'll
attach a patch for the source that came with RH7 to drop privilages, but
other problems will still remain, such as symlink vulnerability.  I suppose
one could link it to libsafe or something, but seeing as it's a game it
hardly seems worth it to me.

-Stan Bubrouski <stan.edu>

Comment 1 Stan Bubrouski 2001-01-19 07:52:02 UTC
Looked more at the code, looks like possible string format vulnerabilities
possible, no telling if any are remotely exploitable though.

Comment 2 Bernhard Rosenkraenzer 2001-01-20 22:55:29 UTC
Fixed in 2.4.1-1 - I've changed the setuid checks to handle setgid.



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