Common Vulnerabilities and Exposures assigned an identifier CVE-2008-1686 to the following vulnerability: Quoting oCert advisory: The libfishsound decoder library incorrectly implements the reference speex decoder from the Speex library, performing insufficient boundary checks on a header structure read from user input. A user controlled field in the header structure is used to build a function pointer. The libfishsound implementation does not check for negative values for the field, allowing the function pointer to be pointed at an arbitary position in memory. This allows remote code execution. Affected version: <= 0.9.0 Fixed version: 0.9.1 Upstream patch in trunk: http://trac.annodex.net/changeset/3536 References: http://www.ocert.org/advisories/ocert-2008-2.html http://lists.xiph.org/pipermail/speex-dev/2008-April/006636.html
oCert-2008-2 was updated to list speex as affected as well: Additional affected packages: Speex <= 1.1.6, the reference implementation from which libfishsound is derived. Current Fedora speex packages are not affected by this problem. Affected speex packages are shipped in Red Hat Enterprise Linux 4 and 5.
For speex, fix first occurred in 1.2.0beta1.
Some more info in Contrad Parker's blog: http://blog.kfish.org/2008/04/release-libfishsound-091.html
So far, same issue was identified in following other projects: - gstreamer-plugins-good-0.10.6 - vorbis-tools-1.1.1 (ogg123) - sweep-0.9.2 - xine-lib-1.1.11.1 - vlc-0.8.6f (not shipped in Fedora or Red Hat Enterprise Linux) - SDL_sound-1.0.1 Fedora packages seems unaffected, as they do not seem to be linked against libspeex despite --enable-speex and speex-devel BuildRequires
So far, fixed upstream in: - gstreamer-plugins-good http://webcvs.freedesktop.org/gstreamer/gst-plugins-good/ext/speex/gstspeexdec.c?r1=1.40&r2=1.41 - sweep http://trac.metadecks.org/changeset/554
Speex upstream added check in speex_packet_to_header(), so that can address this problem for all affected apps, that use speex_packet_to_header and check its return value (all applications seem to do that correctly). For caller of speex_packet_to_header that does not check return value, it will reduce problem to a crash caused by NULL pointer dereference. Patch applied to speex_packet_to_header(): $ svn diff -c 14701 http://svn.xiph.org/trunk/speex/libspeex/ Index: speex_header.c =================================================================== --- speex_header.c (revision 14700) +++ speex_header.c (revision 14701) @@ -178,6 +178,13 @@ ENDIAN_SWITCH(le_header->frames_per_packet); ENDIAN_SWITCH(le_header->extra_headers); + if (le_header->mode >= SPEEX_NB_MODES || le_header->mode < 0) + { + speex_notify("Invalid mode specified in Speex header"); + speex_free (le_header); + return NULL; + } + if (le_header->nb_channels>2) le_header->nb_channels = 2; if (le_header->nb_channels<1) $ svn log -r 14701 http://svn.xiph.org/trunk/speex/libspeex/ ------------------------------------------------------------------------ r14701 | jm | 2008-04-11 05:48:46 +0200 (Fri, 11 Apr 2008) | 5 lines Patch by kfish that checks for headers with invalid mode numbers. Technically, it should have been the application's responsability, but many didn't, so we ended up with security issues. Considering that there's no real use for modes that Speex doesn't know about, this should workaround a lot of problems. ------------------------------------------------------------------------
Upstream bugreport for ogg123: https://trac.xiph.org/ticket/1347
Upstream speex commit mentioned in comment #14 is also viewalbe via xiph.org trac: https://trac.xiph.org/changeset/14701
xine-lib 1.1.12 was released today adding same check to speex decoder used by xine-lib: http://sourceforge.net/project/shownotes.php?release_id=592185&group_id=9655 xine-lib update will not be needed for security reasons after following speex updates are pushed to stable: https://admin.fedoraproject.org/updates/F7/pending/speex-1.2-0.3.beta1 https://admin.fedoraproject.org/updates/F8/pending/speex-1.2-0.4.beta2 Those updates implement check on speex side, based on speex upstream change https://trac.xiph.org/changeset/14701
xine-lib HG commit: http://hg.debian.org/hg/xine-lib/xine-lib?cmd=changeset;node=66e1654718fb;style=gitweb
libfishsound-0.9.1-1.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
speex-1.2-0.4.beta2 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
speex-1.2-0.3.beta1 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
oCERT published advisory oCERT-2008-004 describing affected applications: http://www.ocert.org/advisories/ocert-2008-004.html Speex package update is sufficient to address the issue in all affected applications.
libfishsound-0.9.1-1.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
This issue was addressed in: Red Hat Enterprise Linux: http://rhn.redhat.com/errata/RHSA-2008-0235.html Fedora: https://admin.fedoraproject.org/updates/F7/FEDORA-2008-3117 https://admin.fedoraproject.org/updates/F7/FEDORA-2008-3191 https://admin.fedoraproject.org/updates/F8/FEDORA-2008-3059 https://admin.fedoraproject.org/updates/F8/FEDORA-2008-3103