The LD_DEBUG environment variable is one of those obscure, useful features
found in glibc. By setting LD_DEBUG to one of a few specific values (use
to get the full list), you can get a great deal of
information on just how the dynamic library loader is resolving symbols and
performing relocation. This information can be most useful for tracking
down certain kinds of obscure shareable library problems.
LD_DEBUG can be verbose; it can also provide information about
security-critical programs - especially those running setuid - which
perhaps should not be made available to just anybody. The large amount of
output created by LD_DEBUG can also be used as a sort of poor-man's
single-stepping mechanism. If you can control when the standard output
will block, you can stop a setuid program at almost any library call. This
capability can be most useful if you are trying to exploit a difficult race
condition, such as a temporary file vulnerability. 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.
Thus, it would make sense to disallow LD_DEBUG for setuid binaries.
Unfortunately, this didn't occur to the glibc implementors, who did not add
any checks for setuid operation in the LD_DEBUG code. Gentoo has recently
issued an update fixing the problem; no other
distributors have followed suit as of this writing.
As it turns out, some distributors do not need to. OpenWall fixed this problem over three years ago; ALT
Linux also patched glibc in its distribution. Somehow, however, the fixes
applied by these distributors never got into wider distribution.
This is not the first time that somebody has discovered a security problem
for which a fix had been available for years. These incidents are, at
best, a missed opportunity: known holes with available fixes remain
unpatched for long periods of time. A less pleasant possibility is that
crackers can look at the patches applied by security-conscious
distributions (such as OpenWall) in search of holes which have not been
fixed elsewhere. Security fixes are best applied universally.
The obvious way to ensure widespread diffusion of security fixes is to
submit them back to the package's maintainer. Such patches should almost
always be accepted - or the maintainer should come up with a better way to
fix the problem. If the maintainer refuses to fix the problem, there is
always the time-honored technique of posting an advisory to Bugtraq. What
should not be an option is keeping security fixes to ones self.
to post comments)