opus: cve-2013-0899

Debian Bug report logs - #704870
opus: cve-2013-0899

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Michael Gilbert <mgilbert@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: opus: cve-2013-0899

Date: Sat, 6 Apr 2013 20:00:56 -0400

Package: opus
Severity: serious
Version: 0.9.14+20120615-1
Tags: security

Hi,
the following vulnerability was published for opus.

CVE-2013-0899[0]:
| Integer overflow in the padding implementation in the
| opus_packet_parse_impl function in src/opus_decoder.c in Opus before
| 1.0.2, as used in Google Chrome before 25.0.1364.97 on Windows and
| Linux and before 25.0.1364.99 on Mac OS X and other products, allows
| remote attackers to cause a denial of service (out-of-bounds read) via
| a long packet.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0899
    http://security-tracker.debian.org/tracker/CVE-2013-0899

Message #10 received at 704870@bugs.debian.org (full text, mbox, reply):

From: gregor herrmann <gregoa@debian.org>

To: 704870@bugs.debian.org

Subject: Re: Bug#704870: opus: cve-2013-0899

Date: Sun, 7 Apr 2013 15:35:38 +0200

[Message part 1 (text/plain, inline)]

On Sat, 06 Apr 2013 20:00:56 -0400, Michael Gilbert wrote:

> CVE-2013-0899[0]:

> [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0899
>     http://security-tracker.debian.org/tracker/CVE-2013-0899

Clicking through the links in
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0899
I came upon
https://code.google.com/p/chromium/issues/detail?id=160480
which points to a commit
http://git.xiph.org/?p=opus.git;a=commitdiff;h=9345aaa5ca1c2fb7d62981b2a538e0ce20612c38

Same in https://codereview.chromium.org/11575026 which points to
https://codereview.chromium.org/download/issue11575026_5001_6001.diff

(Please note that I haven't checked if this applies to the opus
version in Debian.)


Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Tom Waits: Poncho's Lament

[signature.asc (application/pgp-signature, inline)]

Message #15 received at 704870@bugs.debian.org (full text, mbox, reply):

From: Chris Knadle <Chris.Knadle@coredump.us>

To: 704870@bugs.debian.org

Cc: control@bugs.debian.org

Subject: Re: opus: cve-2013-0899

Date: Mon, 8 Apr 2013 18:15:33 -0400

[Message part 1 (text/plain, inline)]

tags 704870 + patch
thanks

Gregor -- thanks for finding the links.
The .diff just had different line numbers, so would likely apply with fuzz, 
but I made a quick patch that doesn't agaist the git repo.

I would have made a quilt patch, but this looks like a package in 1.0 format.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us

[0001-fix-for-CVE-2013-0899.patch (text/x-patch, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #22 received at 704870@bugs.debian.org (full text, mbox, reply):

From: Ron <ron@debian.org>

To: Michael Gilbert <mgilbert@debian.org>, 704870@bugs.debian.org

Subject: Re: Bug#704870: opus: cve-2013-0899

Date: Tue, 9 Apr 2013 21:42:45 +0930

Hi,

On Sat, Apr 06, 2013 at 08:00:56PM -0400, Michael Gilbert wrote:
> Package: opus
> Severity: serious
> Version: 0.9.14+20120615-1
> Tags: security
> 
> Hi,
> the following vulnerability was published for opus.

So ...  I'm not particularly convinced that this issue is actually 'serious'
in the RC sense of that severity, and I did mention as much to #-security
when I indicated that the tracker was only following this for chrome.

It requires an application to willingly pass a packet > 16MB to the decoder
(after unpacking that from its transport container itself), when the maximum
size of a single frame according to the Opus standard is capped at 1275 bytes.
And the maximum packet duration is capped at 120ms, which even in the most
pathological case (which no current encoder gets anywhere near) means valid
packets (with multiple frames) will still always be < 64kB.

So any application which might do this, is probably at fair risk of exploding
in its own right due to some bug in its own code before the packet ever got
to the decoder ...  and there is so far no actual indication that any of the
apps currently in Wheezy are vulnerable to this at all.


Which isn't to say we shouldn't fix this, but a quick look over the commits
between the version we currently have and the one that fixes this issue shows
a number of other issues that would be far more likely to ruin a user's day in
some way, some of which also require a badly written app to trigger, yet none
of which I'd really consider major release-blockers in their own right (at
this stage of the release), but many of which I'd consider more serious and
real 'threats' to users than this issue.

The idea of blindly applying a cherry-picked "patch with some fuzz", without
properly analysing its interaction with the patches that wouldn't be applied
or assessing its severity against those does sound a lot like security theater
to me.  It would be pasting over bugs in other applications, without actually
guaranteeing they are no longer vulnerable to problems with accepting insane
packets, while ignoring real problems where the codec itself may do something
'harmful' to users, and other problems where application developers could
similarly hurt themselves through lack of care.  All on the basis of someone
(not upstream) deciding to file a CVE for this one without knowing about any
of the others ...


I'm not going to play severity ping-pong here, but if someone from -release
or -security wants to downgrade this or wheezy-ignore it, then I won't object
to that given what we currently know.  If we're going to fix the currently
'known problems' with this package properly, we really want 1.0.2, which I'll
push out as soon as the freeze is over.  Unless someone can show there is an
application in wheezy where this is more than a purely theoretical problem,
I think that's the only thing that will actually make any real difference to
any existing users here.

(and if someone can show that, they'll probably find a whole bunch of other
potentially serious bugs in that app too would be my first bet ... which
would still be a better use of time than blind patching without any real
testing ever being done)


  Cheers,
  Ron

Message #27 received at 704870@bugs.debian.org (full text, mbox, reply):

From: Michael Gilbert <mgilbert@debian.org>

To: 704870@bugs.debian.org

Subject: Re: Bug#704870: opus: cve-2013-0899

Date: Thu, 11 Apr 2013 21:55:31 -0400

[Message part 1 (text/plain, inline)]

control: tag -1 pending

On Tue, Apr 9, 2013 at 8:12 AM, Ron wrote:
> The idea of blindly applying a cherry-picked "patch with some fuzz", without
> properly analysing its interaction with the patches that wouldn't be applied
> or assessing its severity against those does sound a lot like security theater
> to me.

I wouldn't worry so much about the fuzz comment.  The chromium patch
applies cleanly:
http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/opus/src/opus_decoder.c?r1=173498&r2=173497&pathrev=173498

And the patch is small and clear anyway.  The wording in the bug log
may have made it seem like the patch was being applied blindly, but it
should be pretty obvious after a little analysis that there is indeed
an integer overflow issue in the padding.  The solution is quite
straightforward, and finds a simple one-liner to avoid the potential
for overflow.

Anyway, it is a pretty small and clear patch, so I've gone ahead and
uploaded an nmu to delayed/5.  Please let me know if I should delay
longer, or if you want to do the upload yourself.

> It would be pasting over bugs in other applications, without actually
> guaranteeing they are no longer vulnerable to problems with accepting insane
> packets, while ignoring real problems where the codec itself may do something
> 'harmful' to users, and other problems where application developers could
> similarly hurt themselves through lack of care.  All on the basis of someone
> (not upstream) deciding to file a CVE for this one without knowing about any
> of the others ...

If there are other issues that you're aware of that have a security
implications, please discuss that on oss-sec so that they can also be
properly studied, identified, and addressed:
http://www.openwall.com/lists/oss-security

Best wishes,
Mike

[opus.patch (application/octet-stream, attachment)]

Message #34 received at 704870@bugs.debian.org (full text, mbox, reply):

From: Ron <ron@debian.org>

To: Michael Gilbert <mgilbert@debian.org>, 704870@bugs.debian.org

Subject: Re: Bug#704870: opus: cve-2013-0899

Date: Fri, 12 Apr 2013 22:56:17 +0930

On Thu, Apr 11, 2013 at 09:55:31PM -0400, Michael Gilbert wrote:
> Anyway, it is a pretty small and clear patch, so I've gone ahead and
> uploaded an nmu to delayed/5.  Please let me know if I should delay
> longer, or if you want to do the upload yourself.

Since you've pushed this out already, you can undelay it too if you like.
As I said previously, I'm not seeing a compelling reason for this to delay
the release, so I likewise don't see a good reason to delay things with
extra theatre or to delay getting it actually tested by a few people now.

I'm sure if the untested patch does break something that you'll fix it :)

> If there are other issues that you're aware of that have a security
> implications, please discuss that on oss-sec so that they can also be
> properly studied, identified, and addressed:
> http://www.openwall.com/lists/oss-security

The git repo is publicly available, and the commits having similar or
greater repercussions to this one are fairly self-evident.  I didn't see
a lot of proper analysis of this one outside the upstream discussions to
date.  Not even an indication that any application is vulnerable to it.

I think it will be a much better use of our time to just get the release
out quickly so we can push out all of the fixes and let people who want
them pull backports.  That's what the people who've spoken to me about
using this for their own projects are already doing.  Opening a new
half-baked list of 'release-blockers' to cherry-pick doesn't really
seem helpful for either of those goals at this stage of the freeze.

If there were proven vectors for any of these things, including this one,
we'd have rushed out urgent fixes last year, when they were patched.

  Ron

Message #39 received at 704870-close@bugs.debian.org (full text, mbox, reply):

From: Michael Gilbert <mgilbert@debian.org>

To: 704870-close@bugs.debian.org

Subject: Bug#704870: fixed in opus 0.9.14+20120615-1+nmu1

Date: Sat, 13 Apr 2013 15:17:48 +0000

Source: opus
Source-Version: 0.9.14+20120615-1+nmu1

We believe that the bug you reported is fixed in the latest version of
opus, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 704870@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Michael Gilbert <mgilbert@debian.org> (supplier of updated opus package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Fri, 12 Apr 2013 01:40:52 +0000
Source: opus
Binary: libopus0 libopus-dev libopus-dbg libopus-doc
Architecture: source amd64 all
Version: 0.9.14+20120615-1+nmu1
Distribution: unstable
Urgency: medium
Maintainer: Ron Lee <ron@debian.org>
Changed-By: Michael Gilbert <mgilbert@debian.org>
Description: 
 libopus-dbg - debugging symbols for libopus
 libopus-dev - Opus codec library development files
 libopus-doc - libopus API documentation
 libopus0   - Opus codec runtime library
Closes: 704870
Changes: 
 opus (0.9.14+20120615-1+nmu1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Fix cve-2013-0899: integer overflow in src/opus_decoder.c (closes: #704870).
Checksums-Sha1: 
 e29d71587c6938b5c5fdac2efadfe088a0724301 2680 opus_0.9.14+20120615-1+nmu1.dsc
 e23d06d6448f0bbe505f6d73f04b0e84f5050007 5302 opus_0.9.14+20120615-1+nmu1.diff.gz
 af9c4a50a9f6497cee712c0cce191044afa872e8 152914 libopus0_0.9.14+20120615-1+nmu1_amd64.deb
 458eb56dcdee286c99077497218b41affd926698 199892 libopus-dev_0.9.14+20120615-1+nmu1_amd64.deb
 6954d00d1491ed161f46bd97949e8332ae8ffee0 367362 libopus-dbg_0.9.14+20120615-1+nmu1_amd64.deb
 43aea1fb659c75c719d1b2240d97e9db598ccdd8 166864 libopus-doc_0.9.14+20120615-1+nmu1_all.deb
Checksums-Sha256: 
 ef8a58d91ee59d5849266f530e7b382f6c3947b8788502ae4b6f2d73d861cb5c 2680 opus_0.9.14+20120615-1+nmu1.dsc
 1b788915eedd695d2dd2cc838fc25e8338fa7034944746b0d2eb59f55635892c 5302 opus_0.9.14+20120615-1+nmu1.diff.gz
 c110f5a4118ef6399ce7953bc53ec62eb649c073e6b614ea4c1bf73ff86d1602 152914 libopus0_0.9.14+20120615-1+nmu1_amd64.deb
 b8cf0422bcf34a3e55ba1b8b1bd681792002b87db02b9f540eeea4486b80def8 199892 libopus-dev_0.9.14+20120615-1+nmu1_amd64.deb
 23f1739e2db40358660c8c5c8bdbb143b82786314fda93849fd6c6c8aa3fbb5a 367362 libopus-dbg_0.9.14+20120615-1+nmu1_amd64.deb
 bb76d32211ea98b760dec1eb4d2045475aabbe41e8d56bde15c87884552d3adc 166864 libopus-doc_0.9.14+20120615-1+nmu1_all.deb
Files: 
 f3b9fcae29e7f570462750f15d4831a7 2680 sound optional opus_0.9.14+20120615-1+nmu1.dsc
 e8f6a68c03eeadc37f5b2441a517075b 5302 sound optional opus_0.9.14+20120615-1+nmu1.diff.gz
 a536ee2479074ddc05d3914fd34a43fe 152914 libs optional libopus0_0.9.14+20120615-1+nmu1_amd64.deb
 e5eb17b477acf2da50632e480ea42e7f 199892 libdevel optional libopus-dev_0.9.14+20120615-1+nmu1_amd64.deb
 0c1d6f12c11384a4c8aa2c9acf5d939b 367362 debug extra libopus-dbg_0.9.14+20120615-1+nmu1_amd64.deb
 a026546a20749c2ccd19289f8e956950 166864 doc optional libopus-doc_0.9.14+20120615-1+nmu1_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQQcBAEBCAAGBQJRZ2cmAAoJELjWss0C1vRzmjkf/1FpOpIOn6NAWpx/IUPjGnbi
66ovrecmzmUcEFNJp0IyDvLMragulbA7tBGmnirYB47tSd6uDaXX9S9KI6NWe406
BVGuxNH5l+1CLwwwjnVvuUyhAZ2S5V8nMKmXiRqIgyNRuMn92NP5R1l8CNgmEe6/
ucT5COhur9E74oTVtoG4F8fH0wXBqBOvnGxFNPNK4Swx+Fidv9rEexTNywDx48fY
PYG2quX55vbsNC+1ab4FHTFm/uNUrABAMtd4x5jNrEnGAL+hknx1sPq92IlgSyBv
jxt7DMyU3wWdArf4vWgE4OOeheBC6ChqJXB/co8dK3heZE9bA3KrKf7PzyFLDpXa
Tsi7kgSvpGT7+xfcqHmBG71kCnY8szMjIt18X4ZDDw78or+NkZXsBF2OJCZX/BiK
CvZWqQmPiDn43GYS8UEkn+5aI/q7gpzzIUK7Q+iMsG/YAcATDPxol8p9nkfXpjhS
Vtxb6yJxbkoz+8bip2ydhIordbjwtMRzagTSMqyFYFWkoDwk8MMfMaRSlA5Ep3z7
LnG6iWPQVYsK2/DCRzCeRu/wUo7EeQuBYv0XznaBvV3GdMc0V15s659/q3kmY+ip
Kjv7/PKpMnacvSGrD+ke8upbF4g4lFvZLYFZrTqD8J2zNOXYRi+0OcVZpVjtYG27
3fZj+DdyszjlwbNGvNeWOv/bccFpDsznL7RoBtKqr8UXEKNLKSLxVJdstDBE0SEQ
7eiTcuaTjq5OYyJvG0vDV4uZ+Yw0wrTJEE3eLPwkPs+gCUMQVGHGwUKEEZGAhsBM
wsdmm0gqenbP6//SdRPaGncg2hBzH1X+9S/9J2fRge6fIYYUSg3FWr7QXEALx/L1
sOG+M9V/g5zAcn4eitqBUUyIa3HdiI8YOCd2A0dgYPc9g6mB9zESyAmP89cOfiYJ
zHXQAkIDQE7Kx67H4lnLPnl6nxEiLYff+I9ff6rl/vLgF45Ap0wgM5U8kax93a7/
4Qs34nfT+6FfK8hU5UjocHtoxMe9q98S+E0sBmpnS33pzu8sq9bu/xTTLaC164LJ
BG+r8z7lHpjgRvYc0OBMfA1MBhd193IuoY9jM0oScq43NHv9UX028tZdSHadoVzQ
UbDJRaJKQpNVtHFnYj1FX5VXmemwUAMNZtW85w/tswnmfH2R7uF6wu+MoJFeDFx9
7iI7VG/SLBWlaEz7mDE45ltF6fScBratMx5O17rpxfHzNlyEvVZh4H70exLTiGnw
sTQPKK6JdvdGtYJGlyokLVsfwW3/vGa/O1db7DjgTLJ81zcnspW/bOrUMfRFZ+04
mj0d4NrJPweYP/ZyP1WOkTqjwAPSZkxWj4l7EZmcXD7esR6kfKOvYTIE9hQGU8E=
=gDz1
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.