|Summary:||<media-libs/libsndfile-1.0.19 CAF Processing Integer Overflow Vulnerability (CVE-2009-0186)|
|Product:||Gentoo Security||Reporter:||Robert Buchholz (RETIRED) <rbu>|
|Component:||Vulnerabilities||Assignee:||Gentoo Security <security>|
|Package list:||Runtime testing required:||---|
Description Robert Buchholz (RETIRED) 2009-03-04 14:56:02 UTC
Secunia wrote: Secunia Research has discovered a vulnerability in libsndfile, which can be exploited by malicious people to compromise an application using the library. The vulnerability is caused due to an integer overflow error in the processing of CAF description chunks. This can be exploited to cause a heap-based buffer overflow by tricking the user into processing a specially crafted CAF audio file. Successful exploitation may allow execution of arbitrary code. The vulnerability is confirmed in version 1.0.18. Prior versions may also be affected. SOLUTION: Update to version 1.0.19. PROVIDED AND/OR DISCOVERED BY: Alin Rad Pop, Secunia Research ORIGINAL ADVISORY: Secunia Research: http://secunia.com/secunia_research/2009-7/ libsndfile: http://www.mega-nerd.com/libsndfile/ChangeLog
Comment 1 Richard Ash 2009-03-04 15:40:08 UTC
Created attachment 183894 [details, diff] Patch to libsndfile-1.0.18-r1.ebuild to create libsndfile-1.0.19.ebuild Rename of 1.0.18-r1 ebuild almost works, but the m4 macro patch has been applied upstream and so has to be removed from the ebuild. Attached patch makes the necessary change, which then builds correctly on x86.
Comment 2 Alexis Ballier 2009-03-08 16:02:32 UTC
(In reply to comment #1) > Created an attachment (id=183894)  > Patch to libsndfile-1.0.18-r1.ebuild to create libsndfile-1.0.19.ebuild > > Rename of 1.0.18-r1 ebuild almost works, but the m4 macro patch has been > applied upstream and so has to be removed from the ebuild. Attached patch makes > the necessary change, which then builds correctly on x86. bumped, thanks
Comment 3 Robert Buchholz (RETIRED) 2009-03-08 16:27:29 UTC
Arches, please test and mark stable: =media-libs/libsndfile-1.0.19 Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 sh sparc x86"
Comment 4 Markus Meier 2009-03-09 20:30:21 UTC
fails testsuite here on amd64/x86, older versions had it disabled: ========================== ./lossy_comp_test aiff_ima ========================== test_float_peak : peak_float.aiff ......... ok read_write_peak_test : rw_peak.aiff ............ ok update_header_test : header.aiff ............. ok update_seek_short_test : header_short.aiff ....... ok update_seek_int_test : header_int.aiff ......... ok update_seek_float_test : header_float.aiff ....... ok update_seek_double_test : header_double.aiff ...... ok header_shrink_test : header_shrink.wav ....... ok extra_header_test : extra.aiff .............. ok zero_data_test : zerolen.aiff ............ ok filesystem_full_test : /dev/full ............... Line 300 : Error bad error string : System error : Permission denied.. make: *** [check] Error 1 make: Leaving directory `/var/tmp/portage/media-libs/libsndfile-1.0.19/work/libsndfile-1.0.19/tests' make: *** [check-recursive] Error 1 * * ERROR: media-libs/libsndfile-1.0.19 failed. * Call stack: * ebuild.sh, line 49: Called src_test * environment, line 2708: Called _eapi0_src_test * ebuild.sh, line 616: Called die * The specific snippet of code: * hasq test $FEATURES && die "Make check failed. See above for details." * The die message: * Make check failed. See above for details.
Comment 5 Alexis Ballier 2009-03-10 07:13:54 UTC
(In reply to comment #4) > zero_data_test : zerolen.aiff ............ ok > filesystem_full_test : /dev/full ............... > weird, I had exactly this failure with the .18 pre releases but when I bumped it to the .18 it wasn't failing anymore; can you try to see if upgrading your sandbox helps? I'll probably disable this test for now but I'd like to know why :)
Comment 6 Brent Baude (RETIRED) 2009-03-10 14:58:26 UTC
Comment 7 Tobias Klausmann 2009-03-12 22:39:32 UTC
On alpha, I get this: >>> Emerging (1 of 1) sci-chemistry/gromacs-4.0.3 * gromacs-4.0.3.tar.gz RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * You need one of these Fortran Compilers: g77 gfortran ifc * Installed are: gfortran >>> Unpacking source... >>> Unpacking gromacs-4.0.3.tar.gz to /var/tmp/portage/sci-chemistry/gromacs-4.0.3/work * Running eautoreconf in '/var/tmp/portage/sci-chemistry/gromacs-4.0.3/work/gromacs-4.0.3' ... * Running aclocal ... [ ok ] * Running true --copy --force --install --automake ... [ ok ] * Running aclocal ... [ ok ] * Running autoconf ... [ ok ] * Running autoheader ... [ ok ] * Running automake --add-missing --copy --foreign ... [ ok ] * Running elibtoolize in: gromacs-4.0.3/config * Applying install-sh-1.5.4.patch ... * Applying portage-1.5.10.patch ... * Applying sed-1.5.6.patch ... >>> Source unpacked in /var/tmp/portage/sci-chemistry/gromacs-4.0.3/work >>> Compiling source in /var/tmp/portage/sci-chemistry/gromacs-4.0.3/work ... * * ERROR: sci-chemistry/gromacs-4.0.3 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 3075: Called die * The specific snippet of code: * die "If you must run gromacs without sse (not recommended) gfortran will not work."; * The die message: * If you must run gromacs without sse (not recommended) gfortran will not work. * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/log/portage/sci-chemistry:gromacs-4.0.3:20090312-223608.log'. * The ebuild environment file is located at '/var/tmp/portage/sci-chemistry/gromacs-4.0.3/temp/environment'. * >>> Failed to emerge sci-chemistry/gromacs-4.0.3, Log file: >>> '/var/log/portage/sci-chemistry:gromacs-4.0.3:20090312-223608.log' Naturally, I *can't* use SSE. So where do I get g77? ifc is right out for obvious reasons.
Comment 8 Tobias Klausmann 2009-03-12 22:40:31 UTC
Gah. Wrong browser tab. Nevermind me.
Comment 9 Jeroen Roovers (RETIRED) 2009-03-13 21:24:51 UTC
Stable for HPPA.
Comment 10 Markus Meier 2009-03-15 16:44:32 UTC
(In reply to comment #5) > (In reply to comment #4) > > zero_data_test : zerolen.aiff ............ ok > > filesystem_full_test : /dev/full ............... > > > > weird, I had exactly this failure with the .18 pre releases but when I bumped > it to the .18 it wasn't failing anymore; can you try to see if upgrading your > sandbox helps? I'll probably disable this test for now but I'd like to know why > :) tests pass with sys-apps/sandbox-1.6
Comment 11 Tobias Klausmann 2009-03-15 18:05:01 UTC
Stable on alpha.
Comment 12 Brent Baude (RETIRED) 2009-03-18 21:44:38 UTC
Comment 13 Raúl Porcel (RETIRED) 2009-03-25 18:40:20 UTC
arm/ia64/sh/sparc stable, since tests failures aren't a blocker and previous versions had it restricted...
Comment 14 Robert Buchholz (RETIRED) 2009-04-05 15:18:59 UTC
I'd like to move this bug to [glsa], however amd64 and x86 are still on ~arch. Either we need to RESTRICT=test or send a beer over to Markus, so he'll be happy.
Comment 15 Raúl Porcel (RETIRED) 2009-04-14 09:47:16 UTC
x86 stable, now its amd64 issue :P
Comment 16 Markus Meier 2009-04-15 19:45:27 UTC
amd64 stable, all arches done.
Comment 17 Alex Legler (RETIRED) 2009-04-15 20:07:54 UTC
GLSA request filed.
Comment 18 Pierre-Yves Rofes (RETIRED) 2009-04-17 19:10:15 UTC