From owner-freebsd-current@FreeBSD.ORG Thu May 23 22:02:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1BFFE787 for ; Thu, 23 May 2013 22:02:19 +0000 (UTC) (envelope-from dt71@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by mx1.freebsd.org (Postfix) with ESMTP id 9825E345 for ; Thu, 23 May 2013 22:02:18 +0000 (UTC) Received: from [192.168.1.80] ([78.92.214.29]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Luajs-1UWnph0z7w-00zjY9 for ; Fri, 24 May 2013 00:02:17 +0200 Message-ID: <519E91E1.2050905@gmx.com> Date: Fri, 24 May 2013 00:02:09 +0200 From: dt71@gmx.com User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Bug in BSD patch References: <519DBC27.9030600@gmx.com> <519DF73E.40307@freebsd.org> In-Reply-To: <519DF73E.40307@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:fROQ38AKMkCe/nRCwDf5/hEC0mo8yi3qApR9N+ursrEKNVSpugH r5NIRkILSe0KM/J6BSZtCiT8CNsh5W5llasaoHsEeMXEvF/CvFRWcSV9FCNwTcLWLVAuyJv 07UJn/iODRH7M4g1tECQF0HY39r7EpVUK6UV5f90Tht8O+GiggfpR1L4yVSLcGOo2kaDfp4 c5EtNVLH+VCUc1Kj22E2g== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 22:02:19 -0000 On 05/23/2013 13:02, Stefan Esser wrote: > Quoting from the patch(1) man page: > [...] >patch will examine either the “old” and > “new” file names or, for a non-context diff, the “index” file name, > and choose the file name with the fewest path components, the short- > est basename, and the shortest total file name length (in that > order). I did read that, got confused, and decided to put off further attempts to understand the program--manpage connection. > Your patch file example has the following file information: > > --- texi2html.pl 2012-07-09 10:54:41.000000000 +0200 > +++ /usr/local/bin/texi2html 2012-07-09 10:53:16.000000000 +0200 > > Patch will modify "texi2html.pl" in the work directory. The > other file name (/usr/local/bin/texi2html) is ignored. > > So, there is no problem with this patch, if patch works as > advertised. In that case, I see no security issues (assuming I didn't miss anything): all patch files (containing at least 1 absolute path, excluding /dev/null) would point the patch program to the work directory, provided that a manpage-conforming program is used. >> Some patch files refer to target files in the /tmp directory. >> Theoretically, this means that malicious regular users are able to >> fiddle with the patching process: by creating the target files in the >> /tmp directory, they are able to silently cause patches to apply to >> bogus files in the /tmp directory instead of the intended files in the >> port's work directory. In the extreme case, a malicious user could cause >> ports to be built without certain security patches. The user could also >> try a symlink attack. > > But it is highly unlikely, that the chunk will apply cleanly, and > thus patch will abort without changing the bogus target file, in > most cases. In which case a reject file will be written to /tmp/.rej, which will be -- perhaps only at the right time, as a race condition -- a symlink to /etc/. Unfortunately, my brief attempt at making this work failed.