Crusty Blaa

Of course, Ulrich did know. The
System V ABI specification's ELF section contains the requirement
that \$LD_LIBRARY_PATH have those semantics

   a string that holds a list of directories, separated by colons
   (:). For example, the string /home/dir/lib:/home/dir2/lib: tells the
   dynamic linker to search first the directory /home/dir/lib, then
   /home/dir2/lib, and then the current directory to find dependencies.

  export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/some/other/dir

Do this instead

  if [ -n $LD_LIBRARY_PATH ]; then
    export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/some/other/dir
  else
    export LD_LIBRARY_PATH=/some/other/dir
  fi

Or even

  export LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}/some/other/dir

Kjartan pointed out a report of a gnome-session security vulnerability
to me earlier today. Now, it turns out to actually only be a
vulnerability in a script supplied with certain distributors' packages,
but that's not the interesting part.

The script contained something like this:

  export LD_LIBRARY_PATH=/opt/gnome/lib:$LD_LIBRARY_PATH

and the "vulnerability" was apparently that if \$LD_LIBRARY_PATH
was originally unset, then you get
LD_LIBRARY_PATH="/opt/gnome/lib:".

I couldn't for the life of me understand why it was actually a
vulnerability in the first place. It gnawed at me all day. After a bit
of poking at the runtime linker code in glibc though I realized that
setting \$LD_LIBRARY_PATH like that is effectively the same as
setting it to LD_LIBRARY_PATH="/opt/gnome/lib:./". The problem is
clear then - an attacker can use it to force a rogue, untrusted
library to be loaded that could do nasty things.

So, this whole LD_LIBRARY_PATH=":" causing "./" to be added to
the runtime linker's search path thing came as a big suprise to me and
to some others. I'd never heard of before, but it seems known to at
least some people and is "expected behavior". What worries me here is
that its likely most attackers know to look out for this and most
developers don't.

My long search for a normative reference for this behaviour failed. If
anyone knows where it comes from, I'm dead curious. I expect Ulrich
knows, though :-)

Another interesting thing to play with:

$> LD_DEBUG=help /lib/ld-linux.so.2
Valid options for the LD_DEBUG environment variable are:

  libs        display library search paths
  reloc       display relocation processing
  files       display progress for input file
  symbols     display symbol table processing
  bindings    display information about symbol binding
  versions    display version dependencies
  all         all previous options combined
  statistics  display relocation statistics
  help        display this help message and exit

I read a paper
from Ulrich some time ago that gave lots of details on how to write
shared libraries such that the runtime linker can more efficiently
resolve symbols etc. LD_DEBUG=statistics, among other things,
is useful there. I'd love to see someone with the time and interest
looking into this and analyzing GNOME libraries to see where we can
make improvements.

Its been a fun week completely focused on Fedora packaging and
bugzilla work. Had a nice wake up call on how huge a time sink
fixing non x86 builds can be. A day and a half debugging an ABI
mismatch on pcc breaking the gtk2 build! Sheesh.

Its nice to finish up a week with the feeling that you've got
a good handle on things, though.