Re: [Fedora-music-list] [PlanetCCRMA] [LAD] interesting security update to bristol just came out
by Orcan Ogetbil
On Mon, Nov 15, 2010 at 2:46 PM, Paul Davis wrote:
> On Mon, Nov 15, 2010 at 5:39 PM, Niels Mayer wrote:
>> I noticed that bristol-0.40.7-7 updated due to the following security
>> update. What got me curious is what kind of security issue could
>> running bristol possibly pose?? -- none on it's own, but another rogue
>> package could exploit this issue ...
>
> for whatever its worth, ardour had the same issue.
>
> there's a more elegant fix than the one shown in that bug report
> though. the general form is:
>
> LD_LIBRARY_PATH=StuffToAddToLdLibraryPath${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
>
Shorter? Yes. More elegant? That's debatable since it is a confusing syntax.
For the ardour package in Fedora, I used your fix though, since you
are the upstream.
Orcan
13 years
interesting security update to bristol just came out
by Niels Mayer
I noticed that bristol-0.40.7-7 updated due to the following security
update. What got me curious is what kind of security issue could
running bristol possibly pose?? -- none on it's own, but another rogue
package could exploit this issue ...
https://bugzilla.redhat.com/show_bug.cgi?id=638376
.................
Raphael Geissert conducted a review of various packages in Debian and found
that bristol contained a script that could be abused by an attacker to execute
arbitrary code [1].
The vulnerability is due to an insecure change to LD_LIBRARY_PATH, and
environment variable used by ld.so(8) to look for libraries in directories
other than the standard paths. When there is an empty item in the
colon-separated list of directories in LD_LIBRARY_PATH, ld.so(8) treats it as a
'.' (current working directory). If the given script is executed from a
directory where a local attacker could write files, there is a chance for
exploitation.
In Fedora, /usr/bin/startBristol re-sets LD_LIBRARY_PATH insecurely:
declare -x
LD_LIBRARY_PATH=/usr/lib:/usr/local/lib:${LD_LIBRARY_PATH}:${BRISTOL}/lib
A solution is to patch the script to test if $LD_LIBRARY_PATH is set first
before attempting to modify it:
if [ -z ${LD_LIBRARY_PATH} ]; then
export LD_LIBRARY_PATH=/usr/lib/foo
else
export LD_LIBRARY_PATH=/usr/lib/foo:${LD_LIBRARY_PATH}
fi
This issue has been assigned the name CVE-2010-3351.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598285
...........................
Niels
http://nielsmayer.com
13 years