Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Apr 1998 15:53:24 +1000 (EST)
From:      Peter Jeremy <Peter.Jeremy@alcatel.com.au>
To:        freebsd-security@FreeBSD.ORG
Subject:   Re: Using MD5 insted of DES for passwd ecnryption
Message-ID:  <199804220553.PAA03826@gsms01.alcatel.com.au>

next in thread | raw e-mail | index | archive | help
On Wed, 22 Apr 1998 13:04:35 +0800, Peter Wemm <peter@netplex.com.au> wrote:
>Distributing statically linked binaries has to be strongly discouraged
Agreed in general.

>Anyway, static linking should be supported still,
Also agreed.

>FWIW, I'm a little amazed at the paranoia about dynamic linking.  I have
>*never* *ever* "lost" or damaged ld.so except through stupidity
Given that this is security-related, there are some _security_ reasons
for avoiding dynamic linking - dynamic linking substantially increases
the number of inodes involved in performing a specific function.

For a statically-linked binary, hacking the functionality means replacing
(or patching) the actual binary.

With dynamic linking, the shared libraries associated with the binary also
become targets.  Thus, given a dynamically linked binary, you can subvert
it by subverting the dynamic link editor (ld.so) or any of the associated
shared libraries.  This can be done either by patching the existing system
shared library, or by placing a new shared library at a point in the shared
library search path before the system one.

As an example, consider /bin/sh: For a statically linked executable,
subverting /bin/sh means obtaining write access to /bin/sh, or any of
its parent directories (/bin and /).  On my SS20 running Solaris 2.5,
without any LD_LIBRARY_PATH environment variable, /bin/sh is
dynamically linked and running /bin/sh additionally references the
following files: /usr/lib/libw.so.1, /usr/lib/libdl.so.1,
/usr/lib/libintl.so.1, /usr/lib/libc.so.1, /usr/lib/ld.so and
/usr/platform/SUNW,SPARCstation-20/lib/libc_psr.so.1[+].  Each of
these files (and parent directories) must therefore be protected.

A statically linked /bin/sh relies on the security of 3 inodes and 2
directories.  A dynamically linked /bin/sh relies on 14 inodes, 7
directories and 1 symbolic link[#] - and this gets worse if you have
LD_LIBRARY_PATH defined.

The more objects that need protecting, the more likely one is overlooked,
allowing the system to subverted.

[+] This file (potentially) contains platform-dependent shared libraries.
    This is something that I have (elsewhere) suggested as a useful
    performance enhancing feature for FreeBSD.  This file does not
    actually exist in this case, but is searched for.
[#] /usr/platform/SUNW,SPARCstation-20 is a symbolic link, making the
    directories /, /bin, /usr, /usr/lib, /usr/platform, /usr/platform/sun4m
    and /usr/platform/sun4m/lib.

Peter
--
Peter Jeremy (VK2PJ)                    peter.jeremy@alcatel.com.au
Alcatel Australia Limited
41 Mandible St                          Phone: +61 2 9690 5019
ALEXANDRIA  NSW  2015                   Fax:   +61 2 9690 5247

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe security" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804220553.PAA03826>