Re: [LAD] interesting security update to bristol just came out

This issue has been patched in the debian source, it was done a few weeks ago
now with a case on sf.net to cover it. The problem relates to a user being able
to reconfigure their own LD_LIBRARY_PATH, get their own version of any of the
library to load pretty easily and then do whatever they want from those libraries.
The issue is that administration is required to prevent users of the application
(which might have been installed without user write capabilities) from getting
this level of access.

There are some other issues with the default configuration, it opens up a listener
on a TCP port which could also have some potential abuses made of it although
the obvious one, a buffer overflow situation, has never been reported. A buffer
overflow can give access permissions to the system although only with the uid
of the engine (typically this is 'user' rather than root). Concerned users may
want to use '-host unix:' to use unix domain rather than TCP domain sockets to
avoid the possibility and the colon is required, it's not a typo. This capability
post-dates 0.40 though, it was a 0.60 feature.

I am out on whether unix: should be the bristol default, the answer is probably
yes as TCP is only required for distributed processing where people assumably
know what they are doing but perhaps I might leave it there until somebody
from debian finds it, this is a potentially greater risk than the library path. As
of the latest 0.60 releases the TCP port number, per default, is randomised to
reduce the potential exploits.

Kind regards, nick.

"we have to make sure the old choice [Windows] doesn't disappear”.
Jim Wong, president of IT products, Acer

> Date: Mon, 15 Nov 2010 09:39:08 -0800
> From: nielsmayer@email-addr-hidden
> To: linux-audio-dev@email-addr-hidden; planetccrma@email-addr-hiddenu; fedora-music-list@email-addr-hidden
> Subject: [LAD] interesting security update to bristol just came out
>
> 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
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@email-addr-hidden
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
                                               

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Nov 16 00:15:01 2010