NetBSD Problem Report #45005

From dholland@netbsd.org  Mon May 30 20:58:43 2011
Return-Path: <dholland@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id 93C7163BA4F
	for <gnats-bugs@gnats.NetBSD.org>; Mon, 30 May 2011 20:58:43 +0000 (UTC)
Message-Id: <20110530205843.7FCB314A225@mail.netbsd.org>
Date: Mon, 30 May 2011 20:58:43 +0000 (UTC)
From: dholland@netbsd.org
Reply-To: dholland@netbsd.org
To: gnats-bugs@gnats.NetBSD.org
Subject: rpc.rquotad does no access checks
X-Send-Pr-Version: 3.95

>Number:         45005
>Category:       bin
>Synopsis:       rpc.rquotad does no access checks
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon May 30 21:00:00 +0000 2011
>Last-Modified:  Mon Sep 01 01:25:01 +0000 2025
>Originator:     David A. Holland
>Release:        NetBSD 5.99.52 (20110530)
>Organization:
>Environment:
n/a
>Description:

rpc.rquotad does no access checks, either (AFAICT) on the source IP
address of requests or for the pathname sent by the network to do a
quota inquiry on.

Since rpc.rquotad runs as root if enabled in inetd.conf, this means
that if it's running anyone anywhere can call quotactl on any file on
the system, which means that at least on volumes with quota enabled,
anyone anywhere can determine which filenames exist and which don't.

This is a fairly serious security problem.

Note that in -5 the effect is mostly (but not entirely) mitigated
because it will call quotactl only on mountpoints listed in
/etc/fstab; however, there's still no check of whether those volumes
are exported or not, or if the source IP address is supposed to be
allowed to access them.

>How-To-Repeat:

code reading

>Fix:

Read the exports file and use it to explicitly filter requests?
Inspect the export data stored in the kernel for the provided path and
use that? This will be a pain either way. Especially since mountd is
bozotic. :-/

>Release-Note:

>Audit-Trail:
From: Taylor R Campbell <riastradh@NetBSD.org>
To: "David A. Holland" <dholland@netbsd.org>
Cc: gnats-bugs@NetBSD.org
Subject: Re: bin/45005: rpc.rquotad does no access checks
Date: Sun, 1 Oct 2023 14:23:26 +0000

 Does it really make sense to keep this PR confidential?  We're doing
 users a disservice by trying to keep this secret instead of just
 documenting the behaviour so users can make informed decisions about
 using rpc.rquotad.

From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/45005 CVS commit: src/libexec/rpc.rquotad
Date: Mon, 1 Sep 2025 01:21:06 +0000

 Module Name:	src
 Committed By:	riastradh
 Date:		Mon Sep  1 01:21:06 UTC 2025

 Modified Files:
 	src/libexec/rpc.rquotad: rpc.rquotad.8

 Log Message:
 rpc.rquotad(8): Document security limitation.

 Obviously nobody wants to fix this so it hurts users more to keep it
 secret than to just document the information and let users make
 informed decisions based on that.

 PR bin/45005: rpc.rquotad does no access checks


 To generate a diff of this commit:
 cvs rdiff -u -r1.9 -r1.10 src/libexec/rpc.rquotad/rpc.rquotad.8

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

>Unformatted:

Home	PR Database Search