Re: QA needed for insecure LD_LIBRARY_PATH in many wrapper scripts

On Fri, Nov 16, 2007 at 10:01:34PM +0100, Stefan Fritsch wrote:
> Hi,
>
> many wrapper scripts contain things like
>
> export LD_LIBRARY_PATH=foo:$LD_LIBRARY_PATH
>
> This is bad because if LD_LIBRARY_PATH is unset, it will expand to
>
> LD_LIBRARY_PATH=foo:
>
> which is interpreted as
>
> LD_LIBRARY_PATH=foo:.
>
> This means that the current directory is searched for libraries before
> /lib and /usr/lib, which can have security implications.
>
> The fix is to use "${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}" instead of
> ":$LD_LIBRARY_PATH". This will get rid of the colon if LD_LIBRARY_PATH
> is unset. (Actually, some scripts use "${LD_LIBRARY_PATH+:
> $LD_LIBRARY_PATH}", which seems to work, too. But this is not
> documented in the bash man page, at least I can't find it.)
>
> This is not a new issue: CVE-2005-4790 and CVE-2005-4791 have been
> found two years ago. Unfortunately, they were first announced as SuSE
> specific packaging errors and were missed by the security teams.
>
> I filed #451548 for liferea, but many more packages are affected. I
> intend to file a wishlist bug for lintian to check for this. But
> since this will take some time to get implemented, if someone has a
> local mirror and wants to do some QA work, a complete check of the
> archive would be good.
>
> Of course "$LD_LIBRARY_PATH:" is just as bad as ":$LD_LIBRARY_PATH".
> Maybe there are other environment variables that could be affected by
> the same problem. For $PATH it is not a problem, because it should
> always be set. More ideas?

Are there real use cases for having ":something" or "something:" as $LD_LIBRARY_PATH ? Are there applications relying on LD_LIBRARY_PATH taking empty parts and acting as if they were '.' ? Wouldn't it be just better to change the dynamic loader so that it ignores empty parts of the LD_LIBRARY_PATH ? That would solve the problem once and for all, and avoid people to shoot themselves in the foot by writing "$LD_LIBRARY_PATH:foo" (which they shouldn't, but reality is not everyone is aware of the problem).

Mike

-- 
To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org