If audacity is started with an already existing /tmp/audacity1.2-$LOGNAME, with another owner than the current uid audacity will deadlock upon stopping a recording. Reproducible: Always Steps to Reproduce: 1. create the directory /tmp/audacity1.2-$LOGNAME using some different user, and change ownership of that directory 2. start audacity 3. hit the record button 4. hit stop Actual Results: Audacity will stop redrawing. (can be terminated by SIGINT} Expected Results: The recording should be completed, and possible to play back. I've not checked for related vulnerabilities (symlink attacks / data injection) # emerge --info Portage 2.1.3.19 (default-linux/x86/2006.1/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.20.7 i686) ================================================================= System uname: 2.6.20.7 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz Timestamp of tree: Sun, 18 Nov 2007 20:30:02 +0000 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.4 [enabled] app-shells/bash: 3.2_p17 dev-java/java-config: 1.3.7, 2.1.2-r1 dev-lang/python: 2.3.5-r3, 2.4.4-r6 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 sys-apps/baselayout: 1.12.9-r2 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.22-r2 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-march=pentium4 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://mirror.gentoo.no/ http://ds.thn.htu.se/linux/gentoo" LANG="sv_SE" LC_ALL="sv_SE" LINGUAS="sv_SE sv en_GB en_US us en" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acpi alsa apache2 bash/completion bitmap-fonts bzip2 cairo cdr cli cracklib crypt dbus divx4linux dri dvb dvd dvdr dvdread eds emacs encode esd fam firefox fortran gdbm gif gpm gtk hal iconv imagemagick isdnlog ithreads java javascript jpeg lcms mad midi mmx mng mp3 mpeg mudflap ncurses nls nptl nptlonly ogg opengl openmp pam pcre perl php plotutils png ppds pppd python qt3 qt4 quicktime readline reflection sdl session sockets socks5 spell spl sse sse2 ssl svg tcpd tetex theora tiff truetype truetype-fonts type1-fonts unicode usb userlocales v4l v4l2 vcd videos vorbis win32codecs wmf x86 xface xine xml xml2 xorg xosd xsl xv xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="evdev keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="sv_SE sv en_GB en_US us en" USERLAND="GNU" VIDEO_CARDS="fglrx radeon vga vesa" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
I've done some tests and the bug is also a symlink vulnerablilty that can be used to empty a directory structure of the user of all non hidden files. Steps to Reproduce: <attacking $LOGNAME, emptying $DIR_TO_EMPTY> 1. mkdir /tmp/audacity1.2-$LOGNAME 2. chmod 0777 /tmp/audacity1.2-$LOGNAME 3. ln -s $DIR_TO_EMPTY /tmp/audacity1.2-$LOGNAME/project 4. as $LOGNAME: start and exit audacity 5. watch the progress as audacity cleans up "temporary files" Audacity will recursively (following symlinks, but ignoring hidden files) remove any file or folder matching /tmp/audacity1.2-$LOGNAME/project* on exit.
Proaudio herd, please advise.
(In reply to comment #2) > Proaudio herd, please advise. > usual question: has this been reported upstream ? If yes, could you please point me where ? If no, what would be the solution ? I'd suggest using ~/.audacity/tmp or something like that for temporary files rather than /tmp; but perhaps security experts have better proposals ;)
(In reply to comment #3) > usual question: has this been reported upstream ? the issue in the description has been reported upstream, but not acknowledged. The particular exploit in comment #1 has not been reported. > If yes, could you please point me where ? http://sourceforge.net/mailarchive/forum.php?thread_name=Pine.LNX.4.63.0711162007530.24246%40t-4009-01.studat.chalmers.se&forum_name=audacity-users http://sourceforge.net/mailarchive/forum.php?thread_name=d08.220e2918.3472d3de%40aol.com&forum_name=audacity-users > If no, what would be the solution ? I'd suggest using ~/.audacity/tmp or > something like that for temporary files rather than /tmp; but perhaps security > experts have better proposals ;) I'm not a security expert, but I would suggest adding checks to see that the directory is created with the right permissions, and is no symlink, Currently audacity asks the user to input another directory if no directory could be created and none existed (i.e it was a file) that should be extended to happen also when the directory doesn't have the right permissions (0700). Users with network file systems for their home directories would not want their temporary files in there.
CVE-2007-6061 was assigned to this issue. Has there been any movement upstream yet?
(In reply to comment #5) > CVE-2007-6061 was assigned to this issue. > > Has there been any movement upstream yet? No, because most of the developers aren't on audacity-users, so it never made it to anyone likely to patch it. The snag trying to implement the suggested solution is that there isn't a wx function for the job, so it means writing more platform-specific code to do the permissions check. It's doable, but won't get itself tackled without a bug report reaching developers.
Sent a message to audacity-devel mailing list with a reference to this bug.
Ping, do you have more information that I've not been able to grab ? The thread on -devel ml seems to have ended in the middle of december without any implementation; debian patched audacity yesterday to use the home directory as temp dir. Again, what should we do here ?
If upstream doesn't react, using Debian's patch is probably the best way to go.
Created attachment 141581 [details] Patch applied byu
Ok hit enter too fast, attached patch applied by Debian and now Pardus too. It puts temporary files in user's home directory.
(In reply to comment #11) > Ok hit enter too fast, attached patch applied by Debian and now Pardus too. It > puts temporary files in user's home directory. There is one / too much in front of %s in the copied patch. This is not really important and should work to but home will already contain the leading slash. cheers nion
oh and do you guys have a method to notify the user about that change? Otherwise you should modify the code to modify the user configuration file otherwise people who already installed audacity stay vulnerable.
Proaudio please advise.
Thanks Ismail for the patch, and thanks Nico for the info about it being kept in preferences. I've modified a bit the patch to also discard the temp. directory from preferences if it is in /tmp because I dont trust users to take care about this, esp. I dont trust any user of a system to read the warning in the ebuild and/or the glsa. So, here is the plan: 1.3.4-r1 fixes this. This one is a target for stable; it depends optionally on media-libs/vamp-plugin-sdk which I added some time ago and received no bug report so far, so it's good to go. It would be cool if media-plugins/vamp-aubio-plugins and media-plugins/vamp-libxtract-plugins could go stable aswell, this is not a strict requirement here but if you only have the sdk you'll only have the example plugins shipped with it.
Arches, please test and mark stable: =media-sound/audacity-1.3.4-r1 =media-libs/vamp-plugin-sdk-1.1b-r1 =media-plugins/vamp-aubio-plugins-0.3.2b (at your discretion) =media-plugins/vamp-libxtract-plugins-0.4.2.20071019 (at your discretion) Target keywords : "amd64 ppc ppc64 sparc x86"
ppc64 stable I needed to mark these stable, too: media-sound/lash-0.5.4 media-libs/aubio-0.3.2 media-libs/libsoundtouch-1.3.1-r1 media-libs/libxtract-0.4.7
x86 stable
sparc stable
ppc stable
media-libs/aubio wasnt multilib-strict, so I fixed it, but I guess we will have to wait a bit more before stabilizing it, the rest is stable on amd64.
(In reply to comment #21) > media-libs/aubio wasnt multilib-strict, so I fixed it, but I guess we will have > to wait a bit more before stabilizing it, the rest is stable on amd64. which version I'm gonna remove. This is bug #187826 and I dont want to workaround python bugs in my packages. If you want this fixed, you'd better fix your stable python. Especially since: - the ebuild adds obvious warnings due to variables not being quoted - it calls eautomake when it should call eautoreconf - last but not least: may I suggest you running " python -c 'import aubio.median'" as root with your 0.3.2-r1 version ? then unmerge aubio and have a look at /usr/lib64/python2.4/site-packages/aubio/... stray files.. thanks but no thanks, I dont want this. Ho and as an example: # python -V Python 2.4.4 # python -c "from distutils import sysconfig; print sysconfig.get_python_lib(0,0,prefix='$PYTHON_PREFIX')" lib/python2.4/site-packages # python -V Python 2.5.1 # python -c "from distutils import sysconfig; print sysconfig.get_python_lib(0,0,prefix='$PYTHON_PREFIX')" lib64/python2.5/site-packages and yes, this is the path that is being used... For others, sorry for the noise.
(In reply to comment #22) > which version I'm gonna remove. This is bug #187826 and I dont want to > workaround python bugs in my packages. If you want this fixed, you'd better fix your stable python. I commented on bug #187826, I'm still convinced that my patch here is right (its upstream now too). And I'm not convinced at all that the default behavior of python (in our 2.4 ebuild) is wrong and that the patch to 2.5 is right. > Especially since: > - the ebuild adds obvious warnings due to variables not being quoted Fixed > - it calls eautomake when it should call eautoreconf Only the makefile.am is modifed, I forced automake 1.8 and its fine now > - last but not least: may I suggest you running " python -c 'import > aubio.median'" as root with your 0.3.2-r1 version ? then unmerge aubio and have > a look at /usr/lib64/python2.4/site-packages/aubio/... stray files.. thanks but > no thanks, I dont want this. This seems like some kind of problem with automake-1.10, forcing 1.8 fixes this (or maybe with the python.m4 we install?).
(In reply to comment #23) > I commented on bug #187826, I'm still convinced that my patch here is right > (its upstream now too). And I'm not convinced at all that the default behavior > of python (in our 2.4 ebuild) is wrong and that the patch to 2.5 is right. Hmmm you convinced me, automake's info page and python's help about this seem to go in that direction. > > Especially since: > > - the ebuild adds obvious warnings due to variables not being quoted > > Fixed Thanks > This seems like some kind of problem with automake-1.10, forcing 1.8 fixes this > (or maybe with the python.m4 we install?). This is annoying, but well, you're right using 1.8 fixed this too. The problem doesn't seem to be in python.m4 as the diff is rather small and will probably need further investigation. (Or perhaps it is now needed to manually run python_mod_optimize/cleanup ?)
request filed
Fixed in release snapshot.
GLSA 200803-03