Tavis Ormandy and Julien Tinnes, Google Security Team, discovered a flaw in the pulseaudio, that allows local users to escalate their privileges to root, if pulseaudio is installed as setuid. When pulseaudio is built on Linux system with compiler optimization enabled, it tries to re-exec itself with LD_BIND_NOW environment variable set to 1. http://git.0pointer.de/?p=pulseaudio.git;a=blob;f=src/daemon/main.c;h=b58bb379#l403 This happens before root privileges are dropped. Command to execute is extracted from /proc. This way is prone to race condition and can allow local user to execute different command with root privileges.
Some vendors wanted an embargo date of Jul9, please do not make public commits before that date.
This issue does not seem to affect current Fedora pulseaudio packages. Due to the bug (feature?) in .spec file, compilation of pulseaudio packages does not use standard RPM CFLAGS, rather only sets them to '-ggdb'. From build.log: + CFLAGS=-ggdb + export CFLAGS + CXXFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables' + export CXXFLAGS + FFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -I/usr/lib/gfortran/modules' + export FFLAGS Therefore, the affected code is not compiled in. I've verified with F10 that pulseaudio does not try to re-exec itself, F11 build.log shows that standard RPM CFLAGS are not use there as well. I've not checked EPEL-5 packages yet, though the .spec file there does not override CFLAGS.
EPEL-5 packages are affected, as they do try to re-exec pulseaudio.
Created attachment 350952 [details] Proposed patch from Diego E. Pettenò Removes unsafe re-exec, forces non-lazy runtime binding via build options.
Public now via Julien's blog post: http://blog.cr0.org/2009/07/old-school-local-root-vulnerability-in.html
pulseaudio-0.9.10-1.el5.2 has been submitted as an update for Fedora EPEL 5. http://admin.fedoraproject.org/updates/pulseaudio-0.9.10-1.el5.2
pulseaudio-0.9.10-1.el5.2 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.
MITRE's CVE-2009-1894 entry: Race condition in PulseAudio 0.9.9, 0.9.10, and 0.9.14 allows local users to gain privileges via vectors involving creation of a hard link, related to the application setting LD_BIND_NOW to 1, and then calling execv on the target of the /proc/self/exe symlink. References: ---------- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1894 http://blog.cr0.org/2009/07/old-school-local-root-vulnerability-in.html http://taviso.decsystem.org/research.html https://admin.fedoraproject.org/updates/pulseaudio-0.9.10-1.el5.2 http://security.gentoo.org/glsa/glsa-200907-13.xml http://www.ubuntu.com/usn/usn-804-1 http://www.securityfocus.com/bid/35721
Advisory with PoC from Yorick Koster (Akita Security): http://www.akitasecurity.nl/advisory.php?id=AK20090602
Hmm, not sure what the workflow here is for dealing with security fixes. The version in Rawhide is fixed now, and I guess there's not much to do in that area. I've also prepped an updated package for F11, which is in koji now, but I didn't push it yet, since I didn't really know which workflow to follow. http://koji.fedoraproject.org/koji/taskinfo?taskID=1553720
Lennart, is my assessment of Fedora packages not being affected by this issue incorrect? (see comment #3) In general, process for security updates does not differ much from other updates. Just create bodhi update request, using type 'security' and adding all relevant bug report to references.
Hmm, yes, you seem to be right, Fedora isn't affected. That -ggdb Mathias added, I wonder what that's good for. Here's the commit that introduced that: http://cvs.fedoraproject.org/viewvc/devel/pulseaudio/pulseaudio.spec?r1=1.59&r2=1.60 /me goes and asks mclasen about that.
Apparently Mathias accidently commited debug stuff, so I have removed that now for Rwhide. I this bug report can be closed now since everything's fixed.
Yup, with just warning. If -ggdb is dropped in F10 in some future package update, it should not be done without extra patch for this being added. I see the patch in F11 CVS, so F11 should be safe even if CFLAGS are updates in the future.