opus: CVE-2017-0381: Memory corruption during media file and data processing

Debian Bug report logs - #851612
opus: CVE-2017-0381: Memory corruption during media file and data processing

Toggle useless messages

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

From: Salvatore Bonaccorso <carnil@debian.org>

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

Subject: opus: CVE-2017-0381: Memory corruption during media file and data processing

Date: Mon, 16 Jan 2017 21:35:32 +0100

Source: opus
Version: 1.1-2
Severity: grave
Tags: upstream security patch
Justification: user security hole

Hi,

the following vulnerability was published for opus.

CVE-2017-0381[0]:
Memory corruption during media file and data processing

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] https://security-tracker.debian.org/tracker/CVE-2017-0381
[1] https://github.com/xiph/opus/commit/79e8f527b0344b0897a65be35e77f7885bd99409

Regards,
Salvatore

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

From: Jean-Marc Valin <jmvalin@jmvalin.ca>

To: 851612@bugs.debian.org

Cc: Salvatore Bonaccorso <carnil@debian.org>, Ron <ron@debian.org>

Subject: CVE-2017-0381

Date: Tue, 17 Jan 2017 01:25:27 -0500

Hi,

CVE-2017-0381 states that:
"A remote code execution vulnerability in silk/NLSF_stabilize.c in
libopus in Mediaserver could enable an attacker using a specially
crafted file to cause memory corruption during media file and data
processing."

Now I'm not sure who did the analysis of this bug, but the analysis we
did concluded that the very worst that could happen was a slightly out
of bounds *read* 256 bytes before a constant table. What this means in
practice is that the value is read from another table and the decoded
data audio will sound bad (which was already going to happen if you're
decoding garbage data).

The worst case that could happen is a plain crash. This would happen if
the code is compiled with assertions (the code would assert before
making the read), or -- if you're really unlucky -- if the table is
placed just after some unreadable memory.

So while the bug definitely needed to be fixed -- and was fixed back in
July -- we don't consider it to be a severe security issue. If you
disagree with our analysis, could you point out what we missed?

Cheers,

	Jean-Marc

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

From: Ron Lee <ron@debian.org>

To: 851612-close@bugs.debian.org

Subject: Bug#851612: fixed in opus 1.2~alpha2-1

Date: Thu, 19 Jan 2017 17:49:05 +0000

Source: opus
Source-Version: 1.2~alpha2-1

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 851612@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Ron Lee <ron@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@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Fri, 20 Jan 2017 02:48:31 +1030
Source: opus
Binary: libopus0 libopus-dev libopus-dbg libopus-doc
Architecture: source amd64 all
Version: 1.2~alpha2-1
Distribution: unstable
Urgency: medium
Maintainer: Ron Lee <ron@debian.org>
Changed-By: Ron Lee <ron@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: 851612
Changes:
 opus (1.2~alpha2-1) unstable; urgency=medium
 .
   * Run the tonality analysis at 24 kHz, which reduces complexity while giving
     better frequency resolution for the tonality estimate.
   * Speech quality improvements especially in the 12-20 kbit/s range.
   * Improved VBR encoding for hybrid mode.
   * More aggressive use of wider speech bandwidth, including fullband speech
     starting at 14 kbit/s.
   * Music quality improvements in the 32-48 kb/s range.
   * Generic and SSE CELT optimizations.
   * Support for directly encoding packets up to 120 ms.
   * DTX support for CELT mode.
   * SILK CBR improvements.
   * Ensure that NLSF cannot be negative when computing a min distance between
     them.  This was reported and fixed in July, and assessed as having only a
     relatively minor impact (garbage output, from the garbage input needed to
     trigger it), or at very worst, an assertion failure or simple crash from
     a slightly out of bounds read.  In December it was assigned CVE-2017-0381
     by someone other than the upstream developers, with claims of it being a
     'Critical' issue on Android, but we're yet to see any analysis to back
     that up.  Closes: #851612
Checksums-Sha1:
 943e4d3250ef57f3214a4f330eaf32067069d08d 1967 opus_1.2~alpha2-1.dsc
 ee80d7823dadea7036a7589d5a5faca182b9b87d 1021012 opus_1.2~alpha2.orig.tar.gz
 5b19cc0c72dba9508a18640fef677705ae6c1db4 7445 opus_1.2~alpha2-1.diff.gz
 5d751953518498d059cf26c1c40b2eb916251e80 350212 libopus-dbg_1.2~alpha2-1_amd64.deb
 80c9564f2292584eae4ef0e669b7a57cf8d8548f 212298 libopus-dev_1.2~alpha2-1_amd64.deb
 620237e051be6e3c6c4c687f0d76cbeb5b316c20 194618 libopus-doc_1.2~alpha2-1_all.deb
 de3120acc49728d43140587bf16509fd394ed764 170836 libopus0_1.2~alpha2-1_amd64.deb
 d593e09d1960621eac80da3057132b64eccc4b5b 7385 opus_1.2~alpha2-1_amd64.buildinfo
Checksums-Sha256:
 1b281c14f23ff5336f2edfc07181ae9a6d358a72162598589fec609df83d9de6 1967 opus_1.2~alpha2-1.dsc
 148d38cd0a19e0dde7f7e5491c19953025ff4e7e172e7b21fcf7ba3ff84fa06e 1021012 opus_1.2~alpha2.orig.tar.gz
 0bc67d52b0d1de2836390e267240c4bd998c5985e34a71d03ba3f57d7668a219 7445 opus_1.2~alpha2-1.diff.gz
 ad37c6b049bee74069be513f19a11747a40b5ab59a68f832452e5e14d664ad5d 350212 libopus-dbg_1.2~alpha2-1_amd64.deb
 ec4273be54eef25193d5a5f17fc1413b161462d9daad0f6bfa12f8e0c2ec3dc8 212298 libopus-dev_1.2~alpha2-1_amd64.deb
 4588a23de06f29621b97af247b5a5dfc9de8a2981873b7ffa56cb4444cfb4f4f 194618 libopus-doc_1.2~alpha2-1_all.deb
 56727cc3d0b893d483509cd897e85cce421cd8b7edcd99efb23eed4af717bd3b 170836 libopus0_1.2~alpha2-1_amd64.deb
 e858a03c72cd45a9c056e091e22a9a0a5e718ba35fcf39652074ee17dff888e6 7385 opus_1.2~alpha2-1_amd64.buildinfo
Files:
 1d103f17752fec206e0ef81a7d22c234 1967 sound optional opus_1.2~alpha2-1.dsc
 96c5f6cbf8431e568e22c8153a2fded5 1021012 sound optional opus_1.2~alpha2.orig.tar.gz
 e4f97b932afc702054a11f307cab8206 7445 sound optional opus_1.2~alpha2-1.diff.gz
 2ab4c51a870a2ea90827c4a00ef5ac4b 350212 debug extra libopus-dbg_1.2~alpha2-1_amd64.deb
 31ef4633d0faa3fbf6bf4a7a76737625 212298 libdevel optional libopus-dev_1.2~alpha2-1_amd64.deb
 0b36d84269898f35605d91e9323fec2b 194618 doc optional libopus-doc_1.2~alpha2-1_all.deb
 6b40f87cf45b36c82669643f14690e64 170836 libs optional libopus0_1.2~alpha2-1_amd64.deb
 6b1309d78c9f0b2e0f12cde5104adb73 7385 sound optional opus_1.2~alpha2-1_amd64.buildinfo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJYgPUoAAoJECSWn9pgwHEsPJ0P/07XvQQQGWTRLzr/Q3Vk9WQB
ulRee7XCRDBrfiI4Jj/M5CtMxuaFqOq9x/aA/yGn/3ZzHr48PufMcZStdzRlf/iq
fiLjTH/DcCxe2axsm22a7kUKpZAqqGvz2gJ1PFu6tlN4WuJlz3oMbmsg8qA4F68A
pXD2+lJPAdXdxLzl4YEriHfS8g77YErNZ3Jv5EyCXN3ws4i5AQMpA9WxkslAUlQn
Vru1rqpS86mYANeMM4HSim26+YygW6dGRIrS5slBZofXYmelZqePlRxHjyIHMXzz
9yC15rlIsI4Hi98hSN8cPCVINkNLkOn5s7EZxqn8QR+6+pEN2isv28JOr0d+CnC0
6LyQ9sTWzD5l8MmvmsJYYRgspuOWfC5eNvKc4Ya/CeDUVfAKojWCaQTG3dqE3G6z
mniAS3mkJMnJQ1zUMN0oTEbBrl+tr58I3lH3MdUQkcs4CVhIknB590NQyLziZbcC
vLb7oBZ18GHC76dd/RvrhuzuDNaonl9Q8cu16Zly5+6ZYX+nlpOI49bACIxMpNsE
hq0XuEOhAzops3UP+QYI2CAgxeHbA5r/tPB4uDz9heUzFje1rS/LG7+Xw6qCBgq4
IW55ReEHeA3RoF3kzHU65yzen2SkJE5pF8+Y7guoVNWMXGfztk7ey4r0yXTcA6r8
7pSh4FM++av9Y14OEOFD
=MwWg
-----END PGP SIGNATURE-----

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

From: Salvatore Bonaccorso <carnil@debian.org>

To: Jean-Marc Valin <jmvalin@jmvalin.ca>, 851612@bugs.debian.org

Cc: Ron <ron@debian.org>, Debian Security Team <team@security.debian.org>

Subject: Re: Bug#851612: CVE-2017-0381

Date: Sun, 29 Jan 2017 16:39:59 +0100

Hi

On Tue, Jan 17, 2017 at 01:25:27AM -0500, Jean-Marc Valin wrote:
> Hi,
> 
> CVE-2017-0381 states that:
> "A remote code execution vulnerability in silk/NLSF_stabilize.c in
> libopus in Mediaserver could enable an attacker using a specially
> crafted file to cause memory corruption during media file and data
> processing."
> 
> Now I'm not sure who did the analysis of this bug, but the analysis we
> did concluded that the very worst that could happen was a slightly out
> of bounds *read* 256 bytes before a constant table. What this means in
> practice is that the value is read from another table and the decoded
> data audio will sound bad (which was already going to happen if you're
> decoding garbage data).
> 
> The worst case that could happen is a plain crash. This would happen if
> the code is compiled with assertions (the code would assert before
> making the read), or -- if you're really unlucky -- if the table is
> placed just after some unreadable memory.
> 
> So while the bug definitely needed to be fixed -- and was fixed back in
> July -- we don't consider it to be a severe security issue. If you
> disagree with our analysis, could you point out what we missed?

Apologies for the long delay, Jean-Marc. Thanks a lot for your
analysis.

Ron, would it be possible that you fix that issue via an upcoming
point release for jessie? It would not warrant a DSA on it's own.

Regards,
Salvatore

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

From: Ron <ron@debian.org>

To: Salvatore Bonaccorso <carnil@debian.org>

Cc: Jean-Marc Valin <jmvalin@jmvalin.ca>, 851612@bugs.debian.org, Ron <ron@debian.org>, Debian Security Team <team@security.debian.org>, debian-release@lists.debian.org

Subject: Re: Bug#851612: CVE-2017-0381

Date: Tue, 31 Jan 2017 15:32:13 +1030

On Sun, Jan 29, 2017 at 04:39:59PM +0100, Salvatore Bonaccorso wrote:
> On Tue, Jan 17, 2017 at 01:25:27AM -0500, Jean-Marc Valin wrote:
> > Hi,
> > 
> > CVE-2017-0381 states that:
> > "A remote code execution vulnerability in silk/NLSF_stabilize.c in
> > libopus in Mediaserver could enable an attacker using a specially
> > crafted file to cause memory corruption during media file and data
> > processing."
> > 
> > Now I'm not sure who did the analysis of this bug, but the analysis we
> > did concluded that the very worst that could happen was a slightly out
> > of bounds *read* 256 bytes before a constant table. What this means in
> > practice is that the value is read from another table and the decoded
> > data audio will sound bad (which was already going to happen if you're
> > decoding garbage data).
> > 
> > The worst case that could happen is a plain crash. This would happen if
> > the code is compiled with assertions (the code would assert before
> > making the read), or -- if you're really unlucky -- if the table is
> > placed just after some unreadable memory.
> > 
> > So while the bug definitely needed to be fixed -- and was fixed back in
> > July -- we don't consider it to be a severe security issue. If you
> > disagree with our analysis, could you point out what we missed?
> 
> Apologies for the long delay, Jean-Marc. Thanks a lot for your
> analysis.
> 
> Ron, would it be possible that you fix that issue via an upcoming
> point release for jessie? It would not warrant a DSA on it's own.

We could cherry pick that patch back into 1.1 that's in Jessie, but
unless someone does find a more serious hole in the upstream analysis,
the interesting question would be what do we actually want to achieve
with a point release update?

After we decided to tag 1.2-alpha2 as the best candidate for Stretch,
Jean-Marc also applied this to the 1.1 branch, now tagged as 1.1.4,
for people who did want the fix, but didn't want to jump to the 1.2
changes yet - since there was some amount of hysteria growing attached
to it based on the original CVE claims.

Between 1.1 and 1.1.4 there have actually been a number of patches
to fix things of approximately this severity (this code is continually
being fuzzed and subjected to new analysis, and that does shake out
new corner cases with numeric precision and the like from time to time).

So if we're going to update Jessie because this is "severe enough" to
warrant that (but not so serious to do as a DSA), it would seem a bit
silly to not pull in all of the fixes in that category, or to prioritise
them purely on "how much publicity someone else gave them".

The downside of that is the diff between 1.1 and 1.1.4 isn't something
I expect the SRMs will find a delight to review.  And cherry picking
all of them individually will probably be a significant amount of
error prone work, that personally I'd have a lot less faith in not
introducing an accidental regression.  I don't yet know how many of
them are significantly linked to prior patches in the series.

This patch is the only diff between 1.1.3 and 1.1.4, and 1.1.3 spent
a few months in Stretch without incident before this update.

In "normal use", most people are unlikely to hit any of these issues,
but if we want a stable update where we can honestly say "fixes all
known corner cases where corrupt or maliciously crafted input can do
Something Bad", we probably do want to consider pulling in significantly
more of 1.1.4 than just this patch.  And if we want what we pull in to
have been tested, then pulling in 1.1.4 verbatim would be the safest bet
by a fair margin.

If there's a real regression to that, it would be an upstream bug and
there'll be a 1.1.5 to fix it as soon as it's known ...  This is now
a 'serious' bugfix only branch.  New work is all for 1.2.


I've CC'd -release, to see what they'd prefer we do for Jessie.
It might be that the best option here is to just put something later
in -bpo, and if people are paranoid, they can choose to use that?

  Cheers,
  Ron

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

From: Julien Cristau <jcristau@debian.org>

To: Ron <ron@debian.org>

Cc: Salvatore Bonaccorso <carnil@debian.org>, Jean-Marc Valin <jmvalin@jmvalin.ca>, 851612@bugs.debian.org, Debian Security Team <team@security.debian.org>, debian-release@lists.debian.org

Subject: Re: Bug#851612: CVE-2017-0381

Date: Mon, 6 Feb 2017 20:45:01 +0100

On Tue, Jan 31, 2017 at 15:32:13 +1030, Ron wrote:

> I've CC'd -release, to see what they'd prefer we do for Jessie.
> It might be that the best option here is to just put something later
> in -bpo, and if people are paranoid, they can choose to use that?
> 
I'd prefer to review patches rather than walls of text that refer to
changes in the abstract, since that makes it easier to know what you're
talking about.  But based on what I've read it doesn't sound like jessie
needs an update?

Cheers,
Julien

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

From: Jean-Marc Valin <jmvalin@jmvalin.ca>

To: Julien Cristau <jcristau@debian.org>, Ron <ron@debian.org>

Cc: Salvatore Bonaccorso <carnil@debian.org>, 851612@bugs.debian.org, Debian Security Team <team@security.debian.org>, debian-release@lists.debian.org

Subject: Re: Bug#851612: CVE-2017-0381

Date: Mon, 6 Feb 2017 15:00:53 -0500

On 06/02/17 02:45 PM, Julien Cristau wrote:
> On Tue, Jan 31, 2017 at 15:32:13 +1030, Ron wrote:
> 
>> I've CC'd -release, to see what they'd prefer we do for Jessie.
>> It might be that the best option here is to just put something later
>> in -bpo, and if people are paranoid, they can choose to use that?
>>
> I'd prefer to review patches rather than walls of text that refer to
> changes in the abstract, since that makes it easier to know what you're
> talking about.  But based on what I've read it doesn't sound like jessie
> needs an update?

This is the commit (along with the analysis):
https://git.xiph.org/?p=opus.git;a=commitdiff;h=70a3d641b

That being said, the change itself will not help you much unless you
pull out the full source, since the illegal read occurs in a different file.

Cheers,

	Jean-Marc

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

From: Ron <ron@debian.org>

To: Julien Cristau <jcristau@debian.org>, 851612@bugs.debian.org

Cc: Ron <ron@debian.org>, Salvatore Bonaccorso <carnil@debian.org>, Jean-Marc Valin <jmvalin@jmvalin.ca>, Debian Security Team <team@security.debian.org>, debian-release@lists.debian.org

Subject: Re: Bug#851612: CVE-2017-0381

Date: Tue, 7 Feb 2017 15:00:56 +1030

On Mon, Feb 06, 2017 at 08:45:01PM +0100, Julien Cristau wrote:
> On Tue, Jan 31, 2017 at 15:32:13 +1030, Ron wrote:
> 
> > I've CC'd -release, to see what they'd prefer we do for Jessie.
> > It might be that the best option here is to just put something later
> > in -bpo, and if people are paranoid, they can choose to use that?
> > 
> I'd prefer to review patches rather than walls of text that refer to
> changes in the abstract, since that makes it easier to know what you're
> talking about.  But based on what I've read it doesn't sound like jessie
> needs an update?

Unless there's a surprise reveal about the real severity, I think it
would be theatre to push just this patch and not the similar things
fixed without fanfare in 1.1.4 as an SPU - and I don't think 1.1.4 is
in the usual comfort zone for an SPU, or that any of these are known
to be serious enough to warrant making an uncomfortable exception.

Salvatore asked me to look at our options, so I gave enough context
for people to do their own detailed assessment if they feel they want
to disagree.  If someone is really worried about being exposed by 1.1
in Jessie, they'd be much better off with a -bpo of what's in Stretch,
or a -sloppy backport of 1.1.4, than with just this one issue patched.

If we later find any of them are more seriously exploitable, we can
put a targetted fix through -security or -p-u for just that, but we'd
have already done that if the upstream analysis thought they were.


It looks like the language and severity of the original CVE has been
toned down now based on the analysis given here anyway - so even the
"it would be good PR to show this as fixed in Jessie" argument isn't
as strong as it was a week ago when I originally replied.

  Thanks!
  Ron

Send a report that this bug log contains spam.