Lots and lots of fun with rpc.statd

[drow () FALSE ORG (Daniel Jacobowitz)]

Last week was a little quiet, so I thought I'd throw some kindling on the
fire.  Here's another prime example of a format string bug: our old friend
rpc.statd.

Attached is an exploit.  The offsets are for Linux/PowerPC, Debian 2.2.  It
isn't functional, though - and it's more than just kiddy-proofed.  You'll
need three things:
 (A) shellcode.  There's two or three published; mine isn't quite ready
     for public consumption (meaning it's so ugly it embarrasses me).
     I think it's better than any of the other PPC shellcodes currently
     available, though.  I'll publish it eventually.
 (B) sm_inter.x from the nfs-utils source
 (C) A way to flush the cache before running code.
     PowerPC (recent CPUs, at least) has a separate data and instruction
     cache.  If you use this exploit as is, with gdb attached to the
     process, single stepping, it will work.  If you run it on a remote
     machine, it won't.  Why not?  Because the code is on the stack, which
     remains in the data cache, and then the icache loads the old contents
     of the stack when you branch there!
     There are several solutions to this.

You may also need to change the offsets.  I think the exploit says all it
needs to say without hand-holding - questions about using it WILL go
directly to /dev/null.  I do have a fully function version of this, and I
have verified that it works as promised.

The current version of statd does not have these problems, for at least the
past two weeks (I believe the current version is 0.1.9.1).  Fixed Debian
packages are available for alpha, sparc, powerpc, and i386.

And a rant about the bug, from Chris Evans:
===========================================
- The severity of this hole, i.e. remote root, is much greater than it
should be. All the stupid daemon does is listen to requests on a network,
and manage a few files.

Call the UNIX security model non-granular, and poor, but there's no way
you need root to do that.

It's true that it requires a low-port (i.e. privileged) socket to send
data on, as a way of gaining the trust of the remote (where remote is
often the localhost). However, since it's a connectionless UDP socket, you
can launch the daemon as root, grab the socket, and drop root.

Furthermore, the daemon is a prime candidate for chroot()'ing, but this is
not done. The above plus a chroot() would limit the severity of this hole
to a non-root shell without the ability to raise privilege by exec()'ing
any suid-root binaries.

Finally note that rpc.statd is by no means the only daemon guilty of
overprivilege like this. The neanderthal "use root" approach of most
ftpd's is just asking for remote root trouble. Has no-one heard of
distrusting privileged helpers?
===========================================

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan () debian org         |  |       dmj+ () andrew cmu edu      |
\--------------------------------/  \--------------------------------/

<HR NOSHADE>
<UL>
<LI>text/x-csrc attachment: statd-toy.c
</UL>

<HR NOSHADE>
<UL>
<LI>application/pgp-signature attachment: stored
</UL>