Bugzilla Bug 199751

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 an attachment (id=141581) [edit]
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