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
Description: Binary data
