From owner-freebsd-security@FreeBSD.ORG Wed May 18 08:41:13 2005 Return-Path: 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 D051216A4CE; Wed, 18 May 2005 08:41:13 +0000 (GMT) Received: from postal.sdsc.edu (postal.sdsc.edu [132.249.20.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61CAD43D2F; Wed, 18 May 2005 08:41:13 +0000 (GMT) (envelope-from okumoto@ucsd.edu) Received: from multivac.sdsc.edu (IDENT:1INUxEfBkv9cAo0Wx/bp6GE4Z0nI0kuA@multivac.sdsc.edu [132.249.20.57]) j4I8fCP18257; Wed, 18 May 2005 01:41:12 -0700 (PDT) Received: (from okumoto@localhost)j4I8fCg5011006; Wed, 18 May 2005 01:41:12 -0700 (PDT) X-Authentication-Warning: multivac.sdsc.edu: okumoto set sender to okumoto@ucsd.edu using -f To: Alexander Leidinger References: <200505121545.j4CFjENu078768@repoman.freebsd.org> <20050512180743.6z1h22fldwksgw4w@netchild.homeip.net> <42897003.2090005@ucsd.edu> <20050517144446.gibxprydoosokw0k@netchild.homeip.net> <428A23A2.5080108@ucsd.edu> <20050518100548.h8r4qc59c08swoog@netchild.homeip.net> From: Max Okumoto In-Reply-To: <20050518100548.h8r4qc59c08swoog@netchild.homeip.net> (Alexander Leidinger's message of "Wed, 18 May 2005 10:05:48 +0200") User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (usg-unix-v) Date: Wed, 18 May 2005 01:41:12 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Wed, 18 May 2005 13:18:06 +0000 cc: freebsd-security@FreeBSD.org Subject: Re: cvs commit: src/usr.bin/make job.c X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2005 08:41:14 -0000 Alexander Leidinger writes: > Max Okumoto wrote: > > [CC changed to freebsd-security instead of the cvs list] > > We're talking about replacing the home-grown mkfifo() funktion in make (a > modified copy of mkstemp()) with mkdtemp() and creating the fifo in this new > directory. > > Max worries about a possible race with this new approach. > >> Its not a race between two nice programs :-) The function mkdtmp() >> creates a uniq directory, but make would then need to create a fifo >> in it. (This is two steps, and thus can allow a race) >> >> Assume badmake has same uid, so it can create a file in the uniq >> directory. (Of course this means that the bad guy already has >> your account.) > >> Normal pattern: >> --------------------- >> make0: uses mkdtmp() to create dir /tmp/4321 >> make0: tries to create fifo /tmp/4321 >> make1: uses mkdtmp() to create dir /tmp/4321 but fails >> make1: mkdtmp() next tries to create /tmp/4322 successs >> make1: tries to create fifo /tmp/4322 >> >> >> Sort of DOS: >> --------------------- >> make: uses mkdtmp() to create /tmp/1234/ >> >> badmake: watches for creation of /tmp/1234/ and >> creates /tmp/1234/fifo. >> >> make: tries to create /tmp/1234/fifo fails. > > Right. But if your account is owned you have to worry about other things than > a DOS of make (e.g. your ssh keys or access to your banking account or > whatever). And there are more possibilities for a DOS in the case of an > owned account (fork-bomb, allocating all memory, generating as much files as > possible, ...; some of them can be limited with resource limits, but not > all), so hardening make would be a nice goal, but in my opinion not a goal > we need to persuade today since it wouldn't buy us much. But feel free to > come up with some good arguments which I haven' thought of. > > Bye, > Alexander. Yup, like I said, should I even be worried about this at all? Your idea of using mkdtemp() can be fixed by putting a loop around the code. Each time around the loop would be expensive but we wouldn't be doing that to often anyway. loop: mkdtemp(template) mkfifo(tempalte + "/fifo") if error remove temp directory, restore template and loop. Or better yet, if someone could create an equiv function in libc so I don't have to maintain it in make(1) :-) Do any other programs need the ability to make a temp fifo? Personally, I don't think it is a risk, but I wanted other peoples opinions, before I tried to fix a non-issue. :-) Max