Bug 12442 - rpc.statd runs as root
Summary: rpc.statd runs as root
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: nfs-utils
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
Whiteboard: Winston should-fix
Keywords: Security
Depends On:
TreeView+ depends on / blocked
Reported: 2000-06-18 19:27 UTC by Matthew Kirkwood
Modified: 2014-03-17 02:14 UTC (History)
7 users (show)

Clone Of:
Last Closed: 2000-10-25 14:08:13 UTC

Attachments (Terms of Use)
Runs rpc.statd under its own user, and chroot()'ed. Very untested!!!! (5.36 KB, patch)
2000-07-17 23:45 UTC, Chris Evans
no flags Details | Diff
ltrace -f /sbin/rpc.statd (2.75 KB, text/plain)
2000-08-17 08:10 UTC, Tim Waugh
no flags Details
ltrace output of statd failing to monitor a client (119.91 KB, text/plain)
2000-09-26 16:14 UTC, Stephen Tweedie
no flags Details

Description Matthew Kirkwood 2000-06-18 19:27:56 UTC
And it doesn't really need to.  Chris Evans <chris@ferret.lmh.ox.ac.uk> has
a patch to fix this.

If it's considered overkill for it to have its own account, perhaps it
could share a generic "rpc" userid with portmap and others?

Comment 1 Chris Evans 2000-07-17 23:41:34 UTC
Eww.. well Daniel J has finally posted to Bugtraq confirming that it is
remote-root exploitable. Debian have issued a security update.
I'll attach my chroot(), non-root patch for rpc.statd. However it is almost
certainly too high a risk to use in a security update. Maybe Rawhide! (next on
the depriv list is telnetd, incidentally)

Comment 2 Chris Evans 2000-07-17 23:45:09 UTC
Created attachment 1248 [details]
Runs rpc.statd under its own user, and chroot()'ed. Very untested!!!!

Comment 3 Chris Evans 2000-07-17 23:52:07 UTC
Patch makes future rpc.statd holes much much much less useful to attackers.
Because of the chroot(), the non-root shell is very hard to upgrade to a root
Issues with patch
- Very untested. rpc.statd starts up (with correct security credentials and raw
socket) but I haven't verified correct operation. I'm not too familair with
NFS/lockd/statd interactions.
- Requires new user/group"rpcstatd"
- Requires new directory /var/lib/nfs/rpcstatd, which must be owned by rpcstatd
- Maybe more. Needs review.
I consider the best way to progress Linux security is in the form of damage
limitation patches like this one (things like capabilities and even MAC are just
a form of containment/damage limitation). Because of this, consider this patch
actively supported if any issues are found with it ;-)

Comment 4 Glen Foster 2000-07-18 18:48:07 UTC
This defect is considered MUST-FIX for Winston Beta-5

Comment 5 Glen Foster 2000-07-21 21:46:46 UTC
Changed responsibility for  this defect, per Erik's request (and Bill's

Comment 6 Bill Nottingham 2000-07-22 22:15:46 UTC
Will be fixed in nfs-utils-1.9.1-3.

Comment 7 Bill Nottingham 2000-07-22 22:31:17 UTC
(make that 1.9.1-4)

Comment 8 Chris Evans 2000-07-31 23:26:50 UTC
Patch seems to have been lost in BETA5 version, :-(
This is a shame - the patch is "high risk" so it would have been nice to make
the public beta.
Is it wise to delay this patch until RH7.1, or could it still receive adequate
testing in time for RH7.0? I guess I'd rather play safe than be responsible for
breaking a package in RH7.0!

Comment 9 Bill Nottingham 2000-08-01 00:03:18 UTC
Oh, crud, forgot to apply the patch. I'm all in favor
of leaving it in; what actually uses statd anyways?

Comment 10 Chris Evans 2000-08-01 19:14:08 UTC
Hmm.. I think statd is used to monitor nfs file locks. When an NFS client
reboots (perhaps due to a crash), it contacts statd which then clears out the
stale locks. Or something like that.
statd and lockd on the local machine communicate. Also, remote clients contact
Disclaimer: all the above might be complete BS ;-)
Anyway onto the issue of "to patch or not to patch". Are you in a position to
reapply the patch and check new S(RPMS) into RawHide? I bet if you asked nicely
on testers-list, you could find a volunteer who knows they actively use statd
and would be willing to test a new package. What do you think?

Comment 11 Bill Nottingham 2000-08-01 23:22:07 UTC
Added in nfs-utils- Really. I had to
move the initgroups() before the chroot(); or else
it segfaulted. It worked to the extent that I could
lock a file over NFS. Dunno how much more testing you
can do.

Comment 12 Chris Evans 2000-08-01 23:53:11 UTC
Sorry about the segfault! That sounds like a glibc-2.2 bug to me, though,
glibc-2.1 coped.
Note that I now favour not bothering with initgroups(), and using setgroups(0,
NULL) instead. In fact you'll be receiving the telnetd patch soon which uses
this ;-)

Comment 13 Tim Waugh 2000-08-16 15:21:30 UTC
rpc.statd from nfs-utils- is still segfaulting:

open("/usr/lib/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or
stat("/usr/lib", 0xbffff000)            = -1 ENOENT (No such file or directory)
--- SIGSEGV (Segmentation fault) ---

Backing out the drop-privs patch makes the segfault goes away but obviously has
other bad effects. ;-)

Comment 14 Bill Nottingham 2000-08-16 19:40:56 UTC
Really?  Does it do this repeatedly for you?
(It works OK here...)

Comment 15 Glen Foster 2000-08-16 22:39:37 UTC
This defect has been re-classified as SHOULD-FIX for Winston Gold-release

Comment 16 Chris Evans 2000-08-16 23:32:34 UTC
Rats. Tim, got a reproducable testcase?
What versions of glibc are involved here?
In fact, is the segfault occuring within statd or glibc?
Could be another glibc segfault - glibc 2.1.9x is very non-robust in a chroot()
environment compared with 2.1.2.

Comment 17 Tim Waugh 2000-08-17 08:09:13 UTC
This happens every time.


I'll attach the ltrace output.  It's happening in the C library..

Comment 18 Tim Waugh 2000-08-17 08:10:02 UTC
Created attachment 2585 [details]
ltrace -f /sbin/rpc.statd

Comment 19 Bill Nottingham 2000-08-17 14:46:03 UTC
What are you using for NSS (normal? NIS? ldap? kerberos?)?

Comment 20 Tim Waugh 2000-08-17 15:14:56 UTC
With 'hosts: files' it works fine.  With 'hosts: files dns' it segfaults. 
/etc/hosts just has localhost.

Comment 21 Tim Waugh 2000-08-18 09:37:59 UTC
Can anyone but me reproduce this?

Comment 22 Bill Nottingham 2000-08-18 15:25:44 UTC
Haven't had a chance to check yet. :(

Comment 23 Bernhard Rosenkraenzer 2000-08-23 14:42:25 UTC
Works for me (glibc-2.1.92-8, nfs-utils-

Comment 24 Stephen Tweedie 2000-09-05 19:43:34 UTC
Fails for me too.  So far, I have tried the following combinations at the NFS
server (the client that counts in this case is still running 6.2):

nfs-utils-, glibc-2.1.92-5: rpc.statd SEGVs.
nfs-utils-0.2-2, glibc-2.1.92-5: rpc.statd SEGVs.
nfs-utils-0.2-2, glibc-2.1.92-14: rpc.statd appears to run but doesn't actually
do anything; I get "lockd: cannot monitor" when a client
attempts to lock anything.
nfs-utils- with the drop-privs patch backed out, either glibc: WORKS.

So I'm back to a statd without the fix, since non-working NFS locking means my
mail folders don't work --- it's a bit of a showstopper.

Comment 25 Chris Evans 2000-09-26 00:15:35 UTC
Whats the RH7.0 released versions status?
If it's still bust, give me a localhost-only test case (if possible) and it'll
get fixed.

Comment 26 Chris Evans 2000-09-26 00:19:09 UTC
Hmm - the tendency for glibc-2.2 to segfault in a chroot() environment is
worrying. glibc-2.1 didn't use to do that for me.

Comment 27 Stephen Tweedie 2000-09-26 16:13:35 UTC
The RH7.0 shipped versions (nfs-utils-, glibc-2.1.92-14) still fails.  

One thing I found which easily reproduced the "rpc.statd just doesn't run" is
having /var/lib/nfs/statd not owned by rpcuser.rpcuser, but even with that
working, it Just Doesn't Work, giving the above message "lockd: cannot monitor
xxx.." on any remote locking attempt.

I'll attach an ltrace output of the broken rpc.statd failing to permit a lock. 
"odo.scot.redhat.com" is the server concerned, and "" is the
client trying to obtain the lock.  The rpc.statd tries to gethostbyname() on
both the server's full hostname and the client's IP address, fails on both
(because /etc is missing --- no surprise there), and bombs with a syslog of

syslog(5, "%s", "STAT_FAIL to odo.scot.redhat.com for SM_MON of")
= <void>

If rpc.statd is relying on hostname conversions, then it's hardly something that
can legally run in a chrooted environment.  Looking at the source in
utils/statd/monitor.c, if RESTRICTED_STATD isn't defined (and I can't see it
defined anywhere) then we have

	 * Check hostnames.  If I can't look them up, I won't monitor.  This
	 * might not be legal, but it adds a little bit of safety and sanity.

D'oh.  I think I see the problem.  Just *where* are we expecting to see these
hostnames from in the chrooted environment?

Comment 28 Stephen Tweedie 2000-09-26 16:14:54 UTC
Created attachment 3566 [details]
ltrace output of statd failing to monitor a client

Comment 29 Chris Evans 2000-09-26 22:52:03 UTC
In glibc-2.1, (RH6.2), the call
would initialize the resolver system and cache filehandles to /etc/host.conf,
/etc/hosts, open a network connection to the name server, etc.
This would leave the resolver happy within a chroot().
I'll get the glibc update (in case it makes any difference) and see what's up.

Comment 30 Chris Evans 2000-10-16 18:40:23 UTC
I haven't downloaded the glibc update yet, but I see the release notes claim
that a segfault
in gethostbyname() under certain conditions is fixed. Can anyone with the glibc
update installed
still get rpc.statd to segfault?

Comment 31 Tim Waugh 2000-10-16 22:07:57 UTC
I can't any more.

Comment 32 Bill Nottingham 2000-10-17 04:51:42 UTC
OK, closing as fixed in the glibc errata.

Comment 33 Chris Evans 2000-10-17 15:48:58 UTC
Stephen - does statd now Work For You (tm) with the glibc update?
If not please re-open.

Comment 34 Chris Evans 2000-10-24 21:53:24 UTC
Well, my statd seems happy to resolve hostnames. And that's _without_ the glibc

If anyone can still reproduce non-working NFS locking, please let me know, and
- strace() of failure (to highlight which files we need to open/cache before the
- details of name resolution, e.g. /etc/nsswitch.conf, /etc/resolv.conf,
- (especially details of any of these files which are not stock RH7.0)

Comment 35 Chris Evans 2000-10-24 23:02:56 UTC
Ah, one more comment
the sethostent(1) call seems to read in
/etc/resolv.conf, /etc/hosts, /etc/nsswitch.conf
but it fails to look at

If anyone can reproduce failure, I'd be grateful if they could try this patch
It forces a gethostbyaddr() call which makes sure all resolver files are opened.
As a minor bonus extra, tzset() is called to make sure the chroot() environment
has the correct time locale set up, for e.g. syslog() messages.

--- statd.c.old Mon Oct 23 07:16:52 2000
+++ statd.c     Mon Oct 23 07:17:24 2000
@@ -162,6 +162,9 @@
    * trying to open /etc/* for the dozenth time
+  gethostbyname("localhost");
+  tzset();
   /* Drop privs */

Comment 36 Stephen Tweedie 2000-10-25 13:33:05 UTC
OK, the new glibc seems to work, but the more I think about it, the more I am
convinced that the whole thing is still broken.  I'm reopening this bug to get
some feedback on it.  Can we please back-out the chroot environment altogether?

Face it, hostname resolution inside a chroot sandbox DOES NOT WORK.

You can cache the initial resolver state at first, sure, but what happens if:

	/etc/hosts, /etc/resolv.conf or /etc/host.conf

get overwritten?  What about the NIS server binding in


being updated?  The NIS binding files are dynamic --- ypbind deletes them on
loss of contact with the server and recreates them on rebind, so just having a
handle on the old file descriptor does NOT work.

The chroot environment passes the "OK, it boots" test but will result in an
unreliable service if you start adding hosts to the network and connecting new
hostnames to a running NFS server.

Comment 37 Chris Evans 2000-10-25 14:08:10 UTC
Eww. Damn hostname resolution.
Well, if we do decide to revert the chroot(), we should _definitely_ keep the rest of
the patch, which runs rpc.statd as non-root.

Note that the YP argument is probably valid, assuming the nis code opens
files dynamically.
The /etc/hosts, /etc/resolv.conf, /etc/host.conf agument would seem bogus
though, because glibc AFAIK caches the contents _once_. I don't believe
changing them will affect running processes, regardless of whether they are
chroot()'ed or not.

Comment 38 Bill Nottingham 2001-01-11 21:07:23 UTC
This is currently resolved with statd running as non-root, non-chrooted()
(too many problems with the chroot.)

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