[ltt-dev] [geissert at debian.org: Bug#598309: ust-bin: CVE-2010-3386: insecure library loading]

[Mathieu Desnoyers]

* Alexandre Montplaisir (alexandre.montplaisir at polymtl.ca) wrote:
>
>
> On 10-09-29 09:47 AM, Mathieu Desnoyers wrote:
>> * Jon Bernard (jbernard at debian.org) wrote:
>>> I just received this bug report and wanted to forward it here to get any
>>> thoughts and/or opinions.
>>>
>>> -- 
>>> Jon
>>>
>>> ----- Forwarded message from Raphael Geissert<geissert at debian.org>  -----
>>>
>>> Date: Tue, 28 Sep 2010 04:23:22 +0000
>>> From: Raphael Geissert<geissert at debian.org>
>>> To: submit at bugs.debian.org
>>> Subject: Bug#598309: ust-bin: CVE-2010-3386: insecure library loading
>>> Reply-To: Raphael Geissert<geissert at debian.org>, 598309 at bugs.debian.org
>>>
>>> Package: ust-bin
>>> Version: 0.7-1
>>> Severity: grave
>>> Tags: security
>>> User: team at security.debian.org
>>> Usertags: ldpath
>>>
>>> Hello,
>>>
>>> During a review of the Debian archive, I've found your package to
>>> contain a script that can be abused by an attacker to execute arbitrary
>>> code.
>>>
>>> The vulnerability is introduced by an insecure change to
>>> LD_LIBRARY_PATH, and environment variable used by ld.so(8) to look for
>>> libraries on a directory other than the standard paths.
>>>
>>> Vulnerable code follows:
>>>
>>> /usr/bin/usttrace line 136:
>>> 	    export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:${LIBUST_PATH%libust.so}"
>>> /usr/bin/usttrace line 144:
>>> 	    export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:${LIBUST_PATH%libust.so}"
>> Changing this for something like the following should do the trick:
>>
>> if [ "x${LD_LIBRARY_PATH}" != "x" ]; then
>> 	export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:${LIBUST_PATH%libust.so}"
>> else
>> 	export LD_LIBRARY_PATH="${LIBUST_PATH%libust.so}"
>> fi
>>
>
> Don't we still have the same problem, that if LD_LIBRARY_PATH *already*  
> contains a " " in the list, it will still be there after we append  
> LIBUST_PATH?

I think these "constrained" shells will disallow setting LD_LIBRARY_PATH
altogether from the shell, so we should not have to deal with a
LD_LIBRARY_PATH=" "

The problem comes when LD_LIBRARY_PATH is unset: in this case, usttrace
sets the new variable to   ":otherpath", where the ": part acts as if
the "./" path was in the path, which is the security issue.

> libust.so gets installed in /usr/lib for those who install the package.  
> For the others, don't we add an entry in ld.so.cache?

Not sure, this will require more discussion involving other usttrace
developers. For now, my job of patching the security issue is done. ;)

Thanks,

Mathieu

>
> Alexandre
>
>
>> (untested, but should do the trick)
>>
>> Note that I added extra braces ( ${} ) to delimit the variable more
>> clearly.
>>
>> Thanks,
>>
>> Mathieu
>>
>>
>>> When there's an empty item on the colon-separated list of
>>> LD_LIBRARY_PATH, ld.so treats it as '.' (i.e. CWD/$PWD.)
>>> If the given script is executed from a directory where a potential,
>>> local, attacker can write files to, there's a chance to exploit this
>>> bug.
>>>
>>> This vulnerability has been assigned the CVE id CVE-2010-3386. Please make sure
>>> you mention it when forwarding this report to upstream and when fixing
>>> this bug (everywhere: upstream and here at Debian.)
>>>
>>> [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3386
>>> [1] http://security-tracker.debian.org/tracker/CVE-2010-3386
>>>
>>> Sincerely,
>>> Raphael Geissert
>>>
>>>
>>>
>>> ----- End forwarded message -----
>>>
>>> _______________________________________________
>>> ltt-dev mailing list
>>> ltt-dev at lists.casi.polymtl.ca
>>> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>>>
>

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com