<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
This issue has been patched in the debian source, it was done a few weeks ago<br>now with a case on sf.net to cover it. The problem relates to a user being able <br>to reconfigure their own LD_LIBRARY_PATH, get their own version of any of the<br>library to load pretty easily and then do whatever they want from those libraries.<br>The issue is that administration is required to prevent users of the application<br>(which might have been installed without user write capabilities) from getting<br>this level of access.<br><br>There are some other issues with the default configuration, it opens up a listener<br>on a TCP port which could also have some potential abuses made of it although<br>the obvious one, a buffer overflow situation, has never been reported. A buffer<br>overflow can give access permissions to the system although only with the uid<br>of the engine (typically this is 'user' rather than root). Concerned users may <br>want to use '-host unix:' to use unix domain rather than TCP domain sockets to<br>avoid the possibility and the colon is required, it's not a typo. This capability<br>post-dates 0.40 though, it was a 0.60 feature.<br><br>I am out on whether unix: should be the bristol default, the answer is probably<br>yes as TCP is only required for distributed processing where people assumably<br>know what they are doing but perhaps I might leave it there until somebody <br>from debian finds it, this is a potentially greater risk than the library path. As<br>of the latest 0.60 releases the TCP port number, per default, is randomised to<br>reduce the potential exploits.<br><br>Kind regards, nick.<br><br>"we have to make sure the old choice [Windows] doesn't disappear”.<br>Jim Wong, president of IT products, Acer<br><br><br><br><br>> Date: Mon, 15 Nov 2010 09:39:08 -0800<br>> From: nielsmayer@gmail.com<br>> To: linux-audio-dev@lists.linuxaudio.org; planetccrma@ccrma.stanford.edu; fedora-music-list@redhat.com<br>> Subject: [LAD] interesting security update to bristol just came out<br>> <br>> I noticed that bristol-0.40.7-7 updated due to the following security<br>> update. What got me curious is what kind of security issue could<br>> running bristol possibly pose?? -- none on it's own, but another rogue<br>> package could exploit this issue ...<br>> <br>> https://bugzilla.redhat.com/show_bug.cgi?id=638376<br>> .................<br>> Raphael Geissert conducted a review of various packages in Debian and found<br>> that bristol contained a script that could be abused by an attacker to execute<br>> arbitrary code [1].<br>> <br>> The vulnerability is due to an insecure change to LD_LIBRARY_PATH, and<br>> environment variable used by ld.so(8) to look for libraries in directories<br>> other than the standard paths. When there is an empty item in the<br>> colon-separated list of directories in LD_LIBRARY_PATH, ld.so(8) treats it as a<br>> '.' (current working directory). If the given script is executed from a<br>> directory where a local attacker could write files, there is a chance for<br>> exploitation.<br>> <br>> In Fedora, /usr/bin/startBristol re-sets LD_LIBRARY_PATH insecurely:<br>> <br>> declare -x<br>> LD_LIBRARY_PATH=/usr/lib:/usr/local/lib:${LD_LIBRARY_PATH}:${BRISTOL}/lib<br>> <br>> A solution is to patch the script to test if $LD_LIBRARY_PATH is set first<br>> before attempting to modify it:<br>> <br>> if [ -z ${LD_LIBRARY_PATH} ]; then<br>> export LD_LIBRARY_PATH=/usr/lib/foo<br>> else<br>> export LD_LIBRARY_PATH=/usr/lib/foo:${LD_LIBRARY_PATH}<br>> fi<br>> <br>> This issue has been assigned the name CVE-2010-3351.<br>> <br>> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598285<br>> ...........................<br>> <br>> Niels<br>> http://nielsmayer.com<br>> _______________________________________________<br>> Linux-audio-dev mailing list<br>> Linux-audio-dev@lists.linuxaudio.org<br>> http://lists.linuxaudio.org/listinfo/linux-audio-dev<br> </body>
</html>