Red Hat Bugzilla – Bug 441239
CVE-2008-1686 speex, libfishsound: insufficient boundary checks
Last modified: 2012-06-20 10:37:12 EDT
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:
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:
So far, same issue was identified in following other projects:
- vorbis-tools-1.1.1 (ogg123)
- vlc-0.8.6f (not shipped in Fedora or Red Hat Enterprise Linux)
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:
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/
--- speex_header.c (revision 14700)
+++ speex_header.c (revision 14701)
@@ -178,6 +178,13 @@
+ 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;
le_header->nb_channels = 2;
$ 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:
Upstream speex commit mentioned in comment #14 is also viewalbe via xiph.org trac:
xine-lib 1.1.12 was released today adding same check to speex decoder used by
xine-lib update will not be needed for security reasons after following speex
updates are pushed to stable:
Those updates implement check on speex side, based on speex upstream change
xine-lib HG commit:
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:
Speex package update is sufficient to address the issue in all affected
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: