From owner-freebsd-hackers Mon Jul 26 10:13: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 080F914D78; Mon, 26 Jul 1999 10:13:04 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA47502; Mon, 26 Jul 1999 10:12:25 -0700 (PDT) (envelope-from dillon) Date: Mon, 26 Jul 1999 10:12:25 -0700 (PDT) From: Matthew Dillon Message-Id: <199907261712.KAA47502@apollo.backplane.com> To: Chris Costello Cc: Nate Williams , Dominic Mitchell , jkoshy@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: yet more ways to attack executing binaries (was Re: deny ktrace without read permissions? ) References: <19990726054037.D79022@holly.dyndns.org> <199907261116.EAA43920@freefall.freebsd.org> <19990726132132.B78403@voodoo.pandhm.co.uk> <199907261652.KAA19121@mt.sri.com> <19990726120144.E85663@holly.dyndns.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :On Mon, Jul 26, 1999, Nate Williams wrote: :> > > LD_LIBRARY_PATH, LD_PRELOAD and LD_DEBUG are ignored for setuid executables :> > > in FreeBSD. :> > :> > But the point being made is that they are not ignored for executables :> > which have no read access. And from there, read access can be gained, :> > because at that point, you have code running in the process's address :> > space. :> :> That's right. In other words, there really is no way of protecting :> executable files from being read if someone is motivated enough. :> :> And, in an open-source OS like FreeBSD, it's not a viable solution in :> any case.... : : The only option, as I've mentined previously in this thread, :that I can think of, would be to have an option when building :various linker code to disable searching in $LD_LIBRARY_PATH if :the library being looked for is in the standard library paths. : :-- :|Chris Costello LD_LIBRARY_PATH was a huge security hole when it was first introduced and you know what? It STILL IS! We are opening up a can of worms here. It's one of those things where we either have to make the decision to try to protect the binary that the owner decided to make execute-only, or to give up. * LD_LIBRARY_PATH? * core dumps for execute-only binaries? * ktrace for execute-only binaries? If I were to put my foot down I would say off with their heads! i.e. disallow all three if the non-root-run binary is execute-only. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message