music November 2010

music@lists.fedoraproject.org

2 participants
2 discussions

Re: [Fedora-music-list] [PlanetCCRMA] [LAD] interesting security update to bristol just came out
by Orcan Ogetbil 15 Nov '10

15 Nov '10

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

1 0

interesting security update to bristol just came out
by Niels Mayer 15 Nov '10

15 Nov '10

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

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

music November 2010