Bug 377602 (CVE-2008-1686)

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)