Date: Tue, 30 Jul 2002 13:36:48 -0700 (PDT) From: Lee Brotherston <lee@nerds.org.uk> To: freebsd-gnats-submit@FreeBSD.org Subject: misc/41179: LD_LIBRARY_PATH security checks Message-ID: <200207302036.g6UKamu9051791@www.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 41179
>Category: misc
>Synopsis: LD_LIBRARY_PATH security checks
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Tue Jul 30 13:40:01 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator: Lee Brotherston
>Release: FreeBSD 4.6-RC #3
>Organization:
>Environment:
FreeBSD cybergimp.nerds.org.uk 4.6-RC FreeBSD 4.6-RC #3: Sat Jun 15 21:56:30 BST 2002 lee@cybergimp.nerds.org.uk:/usr/src/sys/compile/NEWGIMPYKERN i386
>Description:
LD_LIBRARY_PATH does not perform suitable security checks (in my opinion) when being used by the root user. With this environment variable set root will use alternative shared libraries which it will dynamically load, which is the intended use (I believe). However it does not perform the same basic checks which would be applied when using ldconfig, that being (from ldconfig(8)):
"For security reasons, directories which are world or group-writable
or which are not owned by root produce warning messages and are
skipped, unless the -i option is present."
A normal users LD_LIBRARY_PATH will be ignored if it is a setuid binary that is being executed (again from ldconfig(8)):
"Special care must be taken when loading shared libraries into the
address space of set-user-Id programs. Whenever such a program is
run, the dynamic linker will only load shared libraries from the hints
file. In particular, the LD_LIBRARY_PATH is not used to search for
libraries."
So elsewhere in the OS the trend seems to be not to use this varible where malicious code might be run with escalated privilages...
However you can use this variable as root, on a setuid binary (ok so you're already root, just mentioning it :>), anywhere.. say /var/tmp, which is owned by nobody and world writable!
The scope for inserting a malicious library is quite high there, especially when you consider that when you su (from su(1)) "By default, the environment is unmodified with the exception of USER, HOME, and SHELL.", so you do not even need to get root to set this variable, but some user in wheel that may later su. If you want a full example I can provide one, I'll just leave it out now to keep this short (yeah, that's worked so far).
>How-To-Repeat:
It's probably easiest just to give this as an example:
$ export LD_LIBRARY_PATH="/var/tmp"
$ cp /usr/lib/libcrypt.so.2 /var/tmp/libcrypt.so.2
$ chmod 666 /var/tmp/libcrypt.so.2
(you can set pretty much any permissions, ownership, etc you want depending on location)
$ su
Password:
# ldd /usr/bin/passwd
/usr/bin/passwd:
libcrypt.so.2 => /var/tmp/libcrypt.so.2 (0x2806c000)
librpcsvc.so.2 => /usr/lib/librpcsvc.so.2 (0x28085000)
libutil.so.3 => /usr/lib/libutil.so.3 (0x2808d000)
libc.so.4 => /usr/lib/libc.so.4 (0x28096000)
>Fix:
I don't have any patch code, but...
I would suggest that the same checks are applied when root uses LD_LIBRARY_PATH as when ldconfig is used to generate hints files. That is "directories which are world or group-writable or which are not owned by root produce warning messages and are skipped", or perhaps a simpler (although probably not as elegant) route might be to add LD_LIBRARY_PATH to the list of environment variables which su modifies.
>Release-Note:
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200207302036.g6UKamu9051791>