* Alexandre Montplaisir ([email protected]) wrote:
>
>
> On 10-09-29 09:47 AM, Mathieu Desnoyers wrote:
>> * Jon Bernard ([email protected]) 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<[email protected]> -----
>>>
>>> Date: Tue, 28 Sep 2010 04:23:22 +0000
>>> From: Raphael Geissert<[email protected]>
>>> To: [email protected]
>>> Subject: Bug#598309: ust-bin: CVE-2010-3386: insecure library loading
>>> Reply-To: Raphael Geissert<[email protected]>, [email protected]
>>>
>>> Package: ust-bin
>>> Version: 0.7-1
>>> Severity: grave
>>> Tags: security
>>> User: [email protected]
>>> 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
>>> [email protected]
>>> 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
_______________________________________________
ltt-dev mailing list
[email protected]
http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
