From owner-freebsd-security Sun Nov 25 3:15:47 2001 Delivered-To: freebsd-security@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 8527837B405 for ; Sun, 25 Nov 2001 03:15:42 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id WAA12744; Sun, 25 Nov 2001 22:15:05 +1100 Date: Sun, 25 Nov 2001 22:13:44 +1100 (EST) From: Bruce Evans X-X-Sender: To: Cc: Subject: Re: fts_print bug? In-Reply-To: <20011123015505.A5165@c7.campus.utcluj.ro> Message-ID: <20011125220611.U5577-100000@delplex.bde.org> 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 On Fri, 23 Nov 2001 veedee@c7.campus.utcluj.ro wrote: > Does anyone know anything about this? > > It didn't worked on my box (4.3-RELEASE), but it did make some directories > which I can't erase anymore... > > [#] rm -r 4965/ > rm: fts_read: File name too long > ... > Sorry for the messy output. A friend of mine found the "exploit" (see > attachement) on BUGTRAQ. I think the security holes in fts were fixed soon after they turned up (this is an old exploit). I fixed the bug in rm (rm was using FTS_NOCHDIR, wich prevents fts handling deep directory). The fix is in 4.3. It still works for me. cp, pax and pkg_install are the only applications in /usr/src that use FTS_NOCHDIR. It breaks at least cp in the same way as it breaks rm. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message