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
