Bug#704870: opus: cve-2013-0899
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704870: opus: cve-2013-0899
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=173498r2=173497pathrev=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 Description: Binary data
Bug#704870: opus: cve-2013-0899
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704870: opus: cve-2013-0899
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.kna...@coredump.us
From d5aeb4fa4ff5e93deb7641359678d91b49fae4b0 Mon Sep 17 00:00:00 2001
From: Christopher Knadle chris.kna...@coredump.us
Date: Mon, 8 Apr 2013 17:59:28 -0400
Subject: [PATCH] fix for CVE-2013-0899
Fix possible overflow padding by feeding ~16 MB of 0xff bytes to the decoder
Thanks to Gregor Herrmann for finding these links with more detail:
https://code.google.com/p/chromium/issues/detail?id=160480
http://git.xiph.org/?p=opus.git;a=commitdiff;h=9345aaa5ca1c2fb7d62981b2a538e0ce20612c38
---
src/opus_decoder.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/opus_decoder.c b/src/opus_decoder.c
index 24869e7..7d2219d 100644
--- a/src/opus_decoder.c
+++ b/src/opus_decoder.c
@@ -596,16 +596,14 @@ static int opus_packet_parse_impl(const unsigned char *data, opus_int32 len,
/* Padding flag is bit 6 */
if (ch0x40)
{
- int padding=0;
int p;
do {
if (len=0)
return OPUS_INVALID_PACKET;
p = *data++;
len--;
-padding += p==255 ? 254: p;
+len -= p==255 ? 254: p;
} while (p==255);
- len -= padding;
}
if (len0)
return OPUS_INVALID_PACKET;
--
1.7.10.4
signature.asc
Description: This is a digitally signed message part.
Bug#704870: opus: cve-2013-0899
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 Description: Digital signature
Bug#704870: opus: cve-2013-0899
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
