Date: Mon, 2 Jun 2003 16:00:32 -0700 (PDT) From: Ceri Davies <ceri@FreeBSD.org> To: freebsd-bugs@FreeBSD.org Subject: Re: misc/41179: LD_LIBRARY_PATH security checks Message-ID: <200306022300.h52N0WLg030673@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR misc/41179; it has been noted by GNATS.
From: Ceri Davies <ceri@FreeBSD.org>
To: FreeBSD Gnats Submit <freebsd-gnats-submit@FreeBSD.org>
Cc:
Subject: Re: misc/41179: LD_LIBRARY_PATH security checks
Date: Mon, 2 Jun 2003 23:59:56 +0100
Adding to audit trail, from misfiled PR misc/52869:
From: Lee Brotherston <lee@nerds.org.uk>
Date: Mon, 2 Jun 2003 17:16:07 +0100
Message-Id: <20030602161606.GA26694@nerds.org.uk>
References: <200207302036.g6UKamu9051791@www.freebsd.org> <20030601181850.GA946@HAL9000.homeunix.com>
On Sun, Jun 01, 2003 at 11:18:50AM -0700, David Schultz wrote:
> The passage you quote in the manual applies to ldconfig(8), not to
> LD_LIBRARY_PATH. There are no such checks for LD_LIBRARY_PATH for
> root or otherwise. ldconfig(8) makes the checks as documented.
Sorry if I didn't explain what I meant there. I realise that this
pertains to ldconfig, I was trying to illustrate what checks were used
elsewhere in the OS for shared libs.
> Your proposal would add a large amount of overhead to program
> execution time, and to what end? If someone with root privileges
> adds an untrusted directory to his LD_LIBRARY_PATH for some odd
> reason, how are we to stop him?
...
> The root user is implicitly trusted and has the privileges of all
> the other users anyway, so you're ...um...preventing root from
> breaking root.
I see what you're saying (again I probably wasn't clear enough in what
I meant). I realise that compromising the LD_LIBRARY_PATH of root as
root would accomplish nothing. I was thinking more along the lines of
a scenario whereby a user (admitedly in the wheel group for this
example) has their account compromised and then su's to root. During
su'ing only USER, HOME & SHELL are modified and so the potentially
tainted LD_LIBRARY_PATH is now used by root. i.e. gaining access to
the user account could potentially lead to escalating this to root.
I take on board your comments about increasing execution time, perhaps
if this was a configurable/optional feature?
> If you su to root from the account of an untrusted user, you're
> asking for trouble anyway. There are many documented cases of
> people breaking root this way, and you don't even need to fiddle
> with LD_LIBRARY_PATH. The untrusted user just sets his PATH to
> include a fake version of su(1) that records root's password,
> prints ``Sorry'', and spawns the real su(1). The correct thing to
> do is to use su(1) only from trusted accounts.
True, it was this sort of thinking that made me ponder this in the
first place. My thinking was that although this can be achieved as
described, LD_LIBRARY_PATH is less checked than PATH and so is a little
stealthier, maybe I'm wrong.
I suspect that not implementing a security feature because there's
already a similar, easier way to compromise the machine isn't the best
reason not to do it ;)
Seriously I understand what you're saying, I just thought I'd mention
this as a potentially helpful feature.
Thanks
Lee
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200306022300.h52N0WLg030673>