From owner-freebsd-security@FreeBSD.ORG Mon Oct 1 10:31:20 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC0451065675 for ; Mon, 1 Oct 2012 10:31:20 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp2.one.com (csmtp2.one.com [91.198.169.22]) by mx1.freebsd.org (Postfix) with ESMTP id 7E7F28FC16 for ; Mon, 1 Oct 2012 10:31:20 +0000 (UTC) Received: from [192.168.1.18] (unknown [217.157.7.221]) by csmtp2.one.com (Postfix) with ESMTPA id 2C6C43018816 for ; Mon, 1 Oct 2012 10:31:13 +0000 (UTC) From: Erik Cederstrand Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9DD86238-51C8-4F38-B7EB-BD773039888B@cederstrand.dk> Date: Mon, 1 Oct 2012 12:31:21 +0200 To: "freebsd-security@freebsd.org" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) X-Mailer: Apple Mail (2.1486) Subject: Opinion on checking return value of setuid(getuid())? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 10:31:20 -0000 I'm looking through the clang analyzer reports and found this one: = http://scan.freebsd.your.org/freebsd-head/sbin.ping/2012-09-30-amd64/repor= t-R9ZgC6.html#EndPath It's complaining that, if setuid() fails for some reason, the process = will continue with root privileges because the process is suid root. At first glance, it seems unnecessary to check the return value of = "setuid(getuid())" since the user should always be able to drop = privileges to itself. So I filed this bug with LLVM: = http://llvm.org/bugs/show_bug.cgi?id=3D13979 It turns out that setuid() *may* fail if the user hits its process = limit. Apparently FreeBSD doesn't check the limit in the specific = setuid(getuid()) case (I can't find the code anywhere right now) so this = is not an issue, but Linux does. However, if FreeBSD decides to change = the setuid() implementation at some point, the issue may surface again. A simple fix would be something like: Index: /freebsd/repos/head_scratch/src/sbin/ping/ping.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /freebsd/repos/head_scratch/src/sbin/ping/ping.c (revision = 240960) +++ /freebsd/repos/head_scratch/src/sbin/ping/ping.c (working copy) @@ -255,7 +255,8 @@ s =3D socket(AF_INET, SOCK_RAW, IPPROTO_ICMP); sockerrno =3D errno; =20 - setuid(getuid()); + if (setuid(getuid()) !=3D 0) + err(EX_NOPERM, "setuid() failed"); uid =3D getuid(); =20 alarmtimeout =3D df =3D preload =3D tos =3D 0; There's an alternative approach for NetBSD with a patch to kern_exec.c = here: = http://mail-index.netbsd.org/tech-security/2008/01/12/msg000026.html but = I have no idea if this applies to FreeBSD. I'd like an opinion on which way to go before filing PRs because we have = around 200 of these warnings in the FreeBSD repo. Thanks, Erik=