From owner-freebsd-security Thu Oct 10 15: 8:32 2002 Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B33CD37B404 for ; Thu, 10 Oct 2002 15:08:29 -0700 (PDT) Received: from 042.dsl6660142.ftth.surewest.net (042.dsl6660142.ftth.surewest.net [66.60.142.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10BDF43EB1 for ; Thu, 10 Oct 2002 15:08:29 -0700 (PDT) (envelope-from anguiano@codesourcery.com) Received: (from anguiano@localhost) by 042.dsl6660142.ftth.surewest.net (8.11.6/8.11.6) id g9AM8LV29029; Thu, 10 Oct 2002 15:08:21 -0700 To: The Anarcat Cc: freebsd-security@freebsd.org Subject: Re: access() is a security hole? References: <20021008183227.GC309@lenny.anarcat.ath.cx> From: Ricardo Anguiano In-Reply-To: <20021008183227.GC309@lenny.anarcat.ath.cx> Date: 10 Oct 2002 15:08:21 -0700 Message-ID: Lines: 44 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The Anarcat writes: > The access(2) manpage mentions an obscure security hole in > access(2). How so? > > " > CAVEAT > Access() is a potential security hole and should never be used. > " > > This seems to have been part of the manpage forever, or so to speak, > so I really wonder what it's talking about. :) In a nutshell, access(2) takes a string parameter, which indicates the path to a file being checked. If after the user is found to have sufficient permission, but before the program acts on this information, the user my change the filesystem. By replacing the original file with another file which that user does not have access(2) to, a setuid program may be tricked into "using" a file on behalf of the original user who does not have permission. if (access("file")); // "file" changes after this line from myfile // to myfile -> /var/spool/mail/boss fd = open("file"); ... The problem is that there is no guarantee that the string "file" refers to the same filesystem object for both system calls. File descriptors don't suffer from this binding problem, but there is no common file descriptor equivalent for access(2). One way to get around this problem is to do the work of access(2) using file descriptors instead: fd = open("file"); fdstat(fd, buf); // fd still refers to same object even // after filesystem change if (access_check(buf)) ... HTH, -- Ricardo Anguiano CodeSourcery, LLC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message