Distribution of security fixes

Disabling such a check is early on malware's list of things to do, and it is easy: for instance, replace one conditional branch instruction with a NOP. If security really is an important goal, then SUID executables deserve their own separate libraries, or no libraries at all. And there should be a kernel flag option to mmap()/mprotect() which says, "No changes allowed to this vma, except deletion at exit()."

What should not be an option is keeping security fixes to ones self.

That depends on the economy-of-the-day. Sometimes exclusive knowledge of a vulnerability, how to exploit it, and/or how to fix it, is worth much more than what is available in the "gift economy," particularly in the short term.

For example, for the longest time, having an empty path in LD_LIBRARY_PATH means that the current directory is searched for libraries. eg. If LD_LIBRARY_PATH accidentally contains :/usr/local/lib then the current directory is always checked for libraries before any other directory.

This happens because sys admins do things like:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib

and put it in the system-wide profile scripts (note what happens if LD_LIBRARY_PATH is empty to begin with). If you have a sysadmin who's made this simple mistake, then it's trivial to take over the system - create a library like libtermcap.so containing trojan code, drop it into /tmp, and just wait. As soon as anyone types 'ls' in /tmp, they're running your code.

There's a simple and obvious fix - ignore empty elements in LD_LIBRARY_PATH. If the sysadmin is stupid enough to want the current directory searched, let them specify a library path of "." explicitly.

The maintainer of glibc does not see this bug as a bug which requires fixing. Instead he would prefer all sysadmins in the world to vet their profile scripts carefully.

Rich.

    export PATH=$PATH:/usr/local/bin

# Add a directory to PATH if it exists and is not already in PATH.
# PATH is $1, Directory is $2.  If PATH does not exist, don't prepend
# a ":" since that adds the current directory to it.  If optional $3
# is equal to "atstart", add the new component to the start of PATH,
# otherwise add it at end.
function add_to_path
{
    if [ -d "$2" ]; then
        p=`eval echo \"\\$$1\"`
        echo "$p" | grep -- "$2" > /dev/null
        if [ "$?" -ne 0 ]; then
            if [ -z "$p" ]; then
                eval $1=\""$2"\"
            else
                if [ "$3" = "atstart" ]; then
                    eval $1=\""$2:\$$1"\"
                else
                    eval $1=\""\$$1:$2"\"
                fi
            fi
        fi
    fi
}

    add_to_path PATH /usr/local/bin
    add_to_path LD_LIBRARY_PATH /usr/local/lib
    add_to_path MANPATH /usr/local/man

add_to_path() {
if [ "$PATH"x == x ]; then PATH=$1; fi
if [ "$2" == atstart ]; then PATH=$1:$PATH
else; PATH=$PATH:$1; fi
}

The ability to stop a program at an arbitrary point can turn a small, difficult window into a wide-open one which can be exploited at leisure.

I can't see how this is supposed to happen - as far as I can tell LD_DEBUG generates all its output in the dynamic linking stage of program execution, which is not intermingled with the normal program execution. The symbols don't get resolved one by one as they get used. If a program dynamically loads additional shared libraries at runtime, that's where you could cause a delay, but that doesn't appear to result in anything exploitable other than perhaps a denial of service attack.

Also, the original advisory claimed that the address information printed could be used to replace and subvert library functions, something that LD_DEBUG doesn't offer any mechanism for.

In general, the entire LD_DEBUG issue doesn't appear to be an exploitable security hole, and is only a harmless information leak about information that's likely to be public anyway. If you want to know how a specific SUID binary works, you can usually find out by trying it yourself by running it on your own system, using the same Linux distribution.

All "exploits" mentioned so far require a completely separate security hole that would be sufficient in itself to subvert security, even without using LD_DEBUG.

    -Klaus