Bugzilla – Bug 377602
VUL-0: CVE-2008-1686: speex insufficient bounds checking
Last modified: 2015-03-09 09:16:56 UTC
Your friendly security team received the following report via vendor-sec. Please respond ASAP. This issue is not public yet, please keep any information about it inside SUSE. Following issue affects speex on 10.1. The libfishsound issue itself is public but the fact that speex is affected not yet. There might also be a separate cve for speex soon. --------- oCERT Advisories #2008-002 libfishsound insufficient boundary checks Description: 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. A patch has been committed to the libfishsound public repository. Affected version: <= 0.9.0 Fixed version: 0.9.1 Additional affected packages: Speex <= 1.1.12, the reference implementation from which libfishsound is derived. Illiminable DirectShow Filters, which statically include the libfishsound library. Annodex Plugins for Firefox. Credit: reporter wishes to remain anonymous CVE: CVE-2008-1686 Timeline: 2008-04-05: vulnerability report received 2008-04-05: contacted libfishsound maintainers 2008-04-06: upstream maintainer publicly releases patch 2008-04-06: advisory release 2008-04-07: libfishsound 0.9.1 released 2008-04-07: added Speex to affected packages References: http://trac.annodex.net/changeset/3535 http://trac.annodex.net/changeset/3536 http://lists.xiph.org/pipermail/speex-dev/2008-April/006636.html Permalink: http://www.ocert.org/advisories/ocert-2008-2.html OpenCERT © oCERT.org - Some rights reserved.
Created attachment 206469 [details] patch that went into upstream svn some time ago
Date: Thu, 10 Apr 2008 18:09:15 +0200 From: Tomas Hoger <thoger@redhat.com> To: Andrea Barisani <lcars@ocert.org>, coley@mitre.org Subject: Re: [vendor-sec] [oCERT 2008-02] libfishsound vulnerability report CC: vendor-sec@lst.de, team@ocert.org Hi all! Replying to self sucks, but that's life... On Mon, 7 Apr 2008 14:05:37 +0200 Tomas Hoger <thoger@redhat.com> wrote: > > The public changeset is here: > > http://trac.annodex.net/changeset/3535 (branches/1.0-stable) > > http://trac.annodex.net/changeset/3536 (trunk) > > Reading the commit message: > > Fix bounds checking of mode in Speex header (backported from > speexdec) > > my attention was obviously drawn towards speex to see if it may be > affected. > > $ grep -r 'header->mode >= SPEEX_NB_MODES' * > speex-1.0.4/src/speexdec.c: if (header->mode >= SPEEX_NB_MODES) > speex-1.0.5/src/speexdec.c: if (header->mode >= SPEEX_NB_MODES) > speex-1.2beta2/src/speexdec.c: if (header->mode >= SPEEX_NB_MODES || > header->mode<0) So it looks like libfishsound is just a tip of an iceberg. Ok, I exaggerate a bit, but it seems it's at least a small one. After some code searching, I've found bunch of other apps that are speex library clients and are / may be affected by this problem. Affected apps: - current version of vorbis tools (ogg123) http://svn.xiph.org/trunk/vorbis-tools/ogg123/speex_format.c - gstreamer-plugins-good http://webcvs.freedesktop.org/gstreamer/gst-plugins-good/ext/speex/gstspeexdec.c - sweep-0.9.2 (some audio player and editor, never used it before) Some other investigated apps: - opal-2.2.2 has mode < 0 check, so looks unaffected - openh323-1.13.4 has speex_mode_list defined, but does not seem to be used anywhere, so probably unaffected, but I'm not aware of any easy way to test - libwvstreams-3.75 has mode < 0 check, so look unaffected speex support is no longer present in recent versions - twinkle-1.1 uses different way to check mode id There are few more apps in Fedora that use speex that I haven't checked yet. oCert, as this was triggered by your advisory, will you take care of the communication towards upstream projects? As at least gstreamer looks like high-profile target and is still unfixed upstream, I believe vendors would prefer to keep this quiet for few more days and not rush it to your advisory as was done with speex. On the other hand, bad guys with advanced google-fu skillz know this already, don't they... Steven, can you give us an advice regarding CVE naming? I'm not sure if this all should be covered under single CVE id or there should be one for each affected application. Seems that problem is caused by the fact that those apps use / are based on the sample speex client code to talk to the speex library. And sample implementation contained a bug which was re-used in couple of projects and fixed in others. Let me hear your embargo preferences. -- Tomas Hoger / Red Hat Security Response Team _______________________________________________ Vendor Security mailing list Vendor Security@lst.de https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
Date: Thu, 10 Apr 2008 20:52:05 +0200 From: Tomas Hoger <thoger@redhat.com> To: Andrea Barisani <lcars@ocert.org> Subject: Re: [vendor-sec] [oCERT 2008-02] libfishsound vulnerability report CC: coley@mitre.org, vendor-sec@lst.de, team@ocert.org On Thu, 10 Apr 2008 19:22:52 +0200 Andrea Barisani <lcars@ocert.org> wrote: > > Affected apps: > > - current version of vorbis tools (ogg123) > > http://svn.xiph.org/trunk/vorbis-tools/ogg123/speex_format.c > > - gstreamer-plugins-good > > http://webcvs.freedesktop.org/gstreamer/gst-plugins-good/ext/speex/gstspeexdec.c > > - sweep-0.9.2 > > (some audio player and editor, never used it before) > > Yes, tomorrow I'll warn affected people. Please let me know if you > detect more affected applications. - vlc-0.8.6f http://git.videolan.org/gitweb.cgi?p=vlc.git;a=blob;f=modules/codec/speex.c - xine-lib-1.1.11.1 seems affected too (no checking at all http://hg.debian.org/hg/xine-lib/xine-lib?f=bb6c63fd3577;file=src/libxineadec/xine_speex_decoder.c;style=gitweb 219 modeID = spx_header->mode; 220 spx_mode = (SpeexMode *) speex_mode_list[modeID]; 221 222 if (spx_mode->bitstream_version != ... - MPlayer - not vulnerable http://svn.mplayerhq.hu/mplayer/trunk/libmpcodecs/ad_speex.c?view=markup -- Tomas Hoger / Red Hat Security Response Team _______________________________________________ Vendor Security mailing list Vendor Security@lst.de https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
Date: Fri, 11 Apr 2008 09:58:59 +0000 From: Andrea Barisani <lcars@ocert.org> To: Tomas Hoger <thoger@redhat.com> Subject: Re: [vendor-sec] [oCERT 2008-02] libfishsound vulnerability report CC: coley@mitre.org, vendor-sec@lst.de, team@ocert.org On Thu, Apr 10, 2008 at 07:22:52PM +0200, Andrea Barisani wrote: > > > > oCert, as this was triggered by your advisory, will you take care of > > the communication towards upstream projects? As at least gstreamer > > Yes, tomorrow I'll warn affected people. Please let me know if you detect > more affected applications. > > We'll probably release a new advisory then. I'll also try to dig more code > and see if I find more affected apps, I'll let you know. > I contacted vorbis-tools, gstreamer, vlc and xine maintainers. Additionally Sweep (http://www.metadecks.org/software/sweep/) is affected to, and while they patched it in svn they didn't release a new version yet, maintainer says they will release soon. A package called SDL_sound seems affected too (http://icculus.org/SDL_sound) and I'm contacting maintainer. I'm trying to see if I can find more affected packages, we also checked Asterisk but it seems safe. Cheers -- Andrea Barisani | Founder & Project Coordinator oCERT | Open Source Computer Emergency Response Team <lcars@ocert.org> http://www.ocert.org 0x864C9B9E 0A76 074A 02CD E989 CE7F AC3F DA47 578E 864C 9B9E "Pluralitas non est ponenda sine necessitate" _______________________________________________ Vendor Security mailing list Vendor Security@lst.de https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
Summary of the problem: header->mode is defined by the file. This integer is used as index into the array speex_mode_list. That array holds pointers to structures that contain pointers to functions. An application is vulnerable if it indexes that speex_mode_list array directly and does not verify that header->mode is not negative.
I'll use this bug as tracking bug and open separate ones for each potentially affected package.
MaintenanceTracker-17195
updates released
CVE-2008-1686: CVSS v2 Base Score: 9.3 (AV:N/AC:M/Au:N/C:C/I:C/A:C)