|Summary:||media-sound/audacity < 1.3.4-r1: temporary file vulnerablilty (CVE-2007-6061)|
|Product:||Gentoo Security||Reporter:||Viktor Griph <gentoo>|
|Component:||Vulnerabilities||Assignee:||Gentoo Security <security>|
|Severity:||minor||CC:||ismail, proaudio, richard, tester|
|Package list:||Runtime testing required:||---|
Description Viktor Griph 2007-11-20 10:25:37 UTC
Comment 1 Viktor Griph 2007-11-20 11:28:54 UTC
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.
Comment 2 Robert Buchholz (RETIRED) 2007-11-20 15:17:14 UTC
Proaudio herd, please advise.
Comment 3 Alexis Ballier 2007-11-20 15:28:08 UTC
(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 ;)
Comment 4 Viktor Griph 2007-11-20 18:14:58 UTC
(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.
Comment 5 Robert Buchholz (RETIRED) 2007-11-25 15:27:40 UTC
CVE-2007-6061 was assigned to this issue. Has there been any movement upstream yet?
Comment 6 Richard Ash 2007-11-30 22:32:06 UTC
(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.
Comment 7 İsmail Dönmez 2007-12-03 09:45:17 UTC
Sent a message to audacity-devel mailing list with a reference to this bug.
Comment 8 Alexis Ballier 2008-01-22 12:59:42 UTC
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 ?
Comment 9 Pierre-Yves Rofes (RETIRED) 2008-01-22 13:20:05 UTC
If upstream doesn't react, using Debian's patch is probably the best way to go.
Comment 10 İsmail Dönmez 2008-01-22 14:19:33 UTC
Created attachment 141581 [details] Patch applied byu
Comment 11 İsmail Dönmez 2008-01-22 14:20:20 UTC
Ok hit enter too fast, attached patch applied by Debian and now Pardus too. It puts temporary files in user's home directory.
Comment 12 nion 2008-01-23 00:43:59 UTC
(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
Comment 13 nion 2008-01-23 00:45:03 UTC
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.
Comment 14 Sune Kloppenborg Jeppesen 2008-01-23 09:00:58 UTC
Proaudio please advise.
Comment 15 Alexis Ballier 2008-01-26 10:42:16 UTC
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.
Comment 16 Robert Buchholz (RETIRED) 2008-01-29 03:27:27 UTC
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"
Comment 17 Markus Rothe (RETIRED) 2008-01-29 08:49:42 UTC
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
Comment 18 Christian Faulhammer (RETIRED) 2008-01-29 11:57:52 UTC
Comment 19 Raúl Porcel (RETIRED) 2008-01-30 17:45:10 UTC
Comment 20 Tobias Scherbaum (RETIRED) 2008-01-31 20:48:18 UTC
Comment 21 Olivier Crete (RETIRED) 2008-02-11 00:12:19 UTC
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.
Comment 22 Alexis Ballier 2008-02-11 14:29:27 UTC
(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.
Comment 23 Olivier Crete (RETIRED) 2008-02-11 15:36:22 UTC
(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?).
Comment 24 Alexis Ballier 2008-02-11 20:00:04 UTC
(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 ?)
Comment 25 Robert Buchholz (RETIRED) 2008-02-20 00:55:32 UTC
Comment 26 Peter Volkov (RETIRED) 2008-02-23 18:22:47 UTC
Fixed in release snapshot.
Comment 27 Robert Buchholz (RETIRED) 2008-03-03 00:11:41 UTC