15 Nov
2010
15 Nov
'10
6:39 p.m.
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
15 Nov
15 Nov
7:57 p.m.
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(a)gmail.com
To: linux-audio-dev(a)lists.linuxaudio.org; planetccrma(a)ccrma.stanford.edu;
fedora-music-list(a)redhat.com
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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
8:46 p.m.
On Mon, Nov 15, 2010 at 5:39 PM, Niels Mayer <nielsmayer(a)gmail.com> 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}
4911
days inactive
4911
days old
linux-audio-dev@lists.linuxaudio.org
2 comments
3 participants
participants (3)
-
Nick Copeland -
Niels Mayer -
Paul Davis