Speex dev - Apr 2008 - speex affected by vulnerability described in [oCERT 2008-02]

Hi folks,

we've tried contacting Jean-Marc Valin but email address bounces. We
published yesterday an advisory about libfishsound, you can find it at the
following URL:

http://www.ocert.org/advisories/ocert-2008-2.html

The issues seems to affect Speex (since the code is the same) versions
<1.1.12. While the 1.2beta branch is not vulnerable we advise that you fix
with a security release what's advertised as stable version as well.

We have contacted vendors that ship speex package, if you know of any project
that links statically or includes the vulnerable code (coming from both speex or
libfishsound) please let us know so that we can send out appropriate
notifications.

Bye and thanks!

-- 
Andrea Barisani |                Founder & Project Coordinator
          oCERT | Open Source Computer Emergency Response Team

<lcars at ocert.org>                         http://www.ocert.org
 0x864C9B9E 0A76 074A 02CD E989 CE7F AC3F DA47 578E 864C 9B9E
        "Pluralitas non est ponenda sine necessitate"

Andrea Barisani a ?crit :
> we've tried contacting Jean-Marc Valin but email address bounces. 
What email address did you use? This email address has always been
listed for Speex.
> We
> published yesterday an advisory about libfishsound, you can find it at the
> following URL:
> 
> http://www.ocert.org/advisories/ocert-2008-2.html
> 
> The issues seems to affect Speex (since the code is the same) versions
<> 1.1.12. While the 1.2beta branch is not vulnerable we advise that you
fix
> with a security release what's advertised as stable version as well.
The fundamental issue is actually not with Speex itself. What happens is
that libfishsound would use the Speex call to parse the header, but
wouldn't actually sanitise them. That being said, I think it's worth
putting a workaround in Speex that just rejects headers that have
invalid modes or other invalid data.
> We have contacted vendors that ship speex package, if you know of any
project
> that links statically or includes the vulnerable code (coming from both
speex or
> libfishsound) please let us know so that we can send out appropriate
> notifications.
Note that not all apps would be vulnerable, only apps that *both* 1) use
Ogg (not VoIP apps) and 2) don't properly check the parsed headers.

	Jean-Marc

On 08/04/2008, Jean-Marc Valin <jean-marc.valin at usherbrooke.ca>
wrote:
> Andrea Barisani a ?crit :
>
>  > We
>  > published yesterday an advisory about libfishsound, you can find it
at the
>  > following URL:
>  >
>  > http://www.ocert.org/advisories/ocert-2008-2.html
>  >
>  > The issues seems to affect Speex (since the code is the same)
versions <>  > 1.1.12. While the 1.2beta branch is not vulnerable we
advise that you fix
>  > with a security release what's advertised as stable version as
well.
>
>
> The fundamental issue is actually not with Speex itself. What happens is
>  that libfishsound would use the Speex call to parse the header, but
>  wouldn't actually sanitise them.
I think Andrea is saying that the speexdec shipped in <= 1.1.12 does
have the bug, and suggesting a 1.0.x release that fixes it (as 1.0.5
is still advertised as the "stable"  branch at
http://speex.org/downloads/).
>  That being said, I think it's worth
>  putting a workaround in Speex that just rejects headers that have
>  invalid modes or other invalid data.
I sent Jean-Marc a patch that does that recently. This issue is also
avoided if the speex_lib_get_mode() function is used instead of
indexing into the global speex_mode_list[]. See
http://blog.kfish.org/2008/04/release-libfishsound-091.html
for a discussion about that.

Anyway, I wouldn't call these "workarounds", just part of making a
robust API :-)

cheers,

Conrad.

On Tue, Apr 08, 2008 at 11:46:16AM +1000, Jean-Marc Valin
wrote:
> Andrea Barisani a ?crit :
> > we've tried contacting Jean-Marc Valin but email address bounces. 
> 
> What email address did you use? This email address has always been
> listed for Speex.
>
I used an old address mentioned in 1.0.5 (which is advertised as the current
stable release on speex.org download page), I see now that beta and 1.1.12
have the updated one.
> > We
> > published yesterday an advisory about libfishsound, you can find it at
the
> > following URL:
> > 
> > http://www.ocert.org/advisories/ocert-2008-2.html
> > 
> > The issues seems to affect Speex (since the code is the same) versions
<> > 1.1.12. While the 1.2beta branch is not vulnerable we advise that
you fix
> > with a security release what's advertised as stable version as
well.
> 
> The fundamental issue is actually not with Speex itself. What happens is
> that libfishsound would use the Speex call to parse the header, but
> wouldn't actually sanitise them. That being said, I think it's
worth
> putting a workaround in Speex that just rejects headers that have
> invalid modes or other invalid data.
> 
Ok, thanks for the clarification. Shall we still consider Speex affected in
our advisory?
> > We have contacted vendors that ship speex package, if you know of any
project
> > that links statically or includes the vulnerable code (coming from
both speex or
> > libfishsound) please let us know so that we can send out appropriate
> > notifications.
> 
> Note that not all apps would be vulnerable, only apps that *both* 1) use
> Ogg (not VoIP apps) and 2) don't properly check the parsed headers.
> 
Indeed, but these are conditions which are app-side and not library-side so
to speak, and there's no enforcement of them. So while it might not always
be
the case it's better to be safe than sorry.

Thanks a lot for your feedback.

Cheers.
> 	Jean-Marc
-- 
Andrea Barisani |                Founder & Project Coordinator
          oCERT | Open Source Computer Emergency Response Team

<lcars at ocert.org>                         http://www.ocert.org
 0x864C9B9E 0A76 074A 02CD E989 CE7F AC3F DA47 578E 864C 9B9E
        "Pluralitas non est ponenda sine necessitate"