On Tue, Aug 15, 2017 at 2:22 PM, Spencer Dawkins at IETF <spencerdawkins.i...@gmail.com> wrote: > Jean-Marc, > > On Tue, Aug 15, 2017 at 12:22 PM, Jean-Marc Valin <jmva...@mozilla.com> > wrote: >> >> Hi Spencer, >> >> Thanks for the comments. See below. > > > By the way, ADs always appreciate responses when they can still remember > what they were thinking when they balloted. You rock! > >> >> >> On 15/08/17 12:40 PM, Spencer Dawkins wrote: >> > I have no idea what an “extreme bitstream” is. Aren’t they all pretty >> > much 0s >> > and 1s? >> > >> > More seriously, it would be nice to know what about the bitstream is >> > extreme. >> >> What is meant here is that the bit-stream is trying to represent an >> extremely large value for the high LSF parameters. It's either >> impossible or at least extremely unlikely for an encoder to generate >> such a bit-stream that triggers the bug. So any occurrence would likely >> be specially crafted rather than random. Would you prefer the word >> "malicious" instead of "extreme" here? > > > So to tease this apart - my comment was hoping for something like "a > bitstream that represents an extremely large value for the high LSF > parameters", which makes things clear for me. > > On "malicious" - you might say that such a bitstream is most likely to be > hand-crafted as an exploit", or something like that, because that seems like > a really good thing to say. >
This feel like <AOL>Me too</AOL>, but, well, I also think that having some more explanation here would be helpful Unless you are trying not to make it too obvious that there is a security issue here (which seems like a really bad idea!) I think that explaining what the issue and why it is important would be good. This may be blindingly obvious to those schooled in art, but I certainly didn't get "extreme bitstream" means "likely malicious" (I do happen to like the term though :-) W >> >> > Is there an obvious way that the decoder can know whether audio will be >> > downmixed outside the decoder? Section 10 thinks decoders can know that, >> > apparently. >> >> The most common case is when the application initializes a mono decoder >> (e.g. the receiver has just one speaker), but is decoding a stereo file >> (or the sender is sending a stereo stream). In that case, the >> down-mixing occurs in the decoder itself. In the other case, the >> application developer would have to explicitly tell the decoder that its >> stereo output is meant to be down-mixed. > > > This would be much clearer if you added a sentence that captures what you > just told me, unless this is in the OPUS base specification someplace. If > it's not, it seems useful. > > (I think you're actually adding information that both codec implementers and > application implementers need to know - decoders that can downmix need to > have an input for an application to tell them not to downmix. If I > understand correctly, that would also be good to write down someplace) > >> >> > In the security considerations, why is it highly unlikely that the >> > read-only >> > table will be placed next to sensitive data? I’m not balloting Discuss >> > on this >> > because the assertion is nested in a reported vulnerability with no >> > known >> > exploit, but I am curious. >> >> Well, the linker will typically have a text segment where it puts all >> the executable code and the read-only data, separate from the heap and >> other writable areas. The out-of-bounds read is just 256 bytes before >> the target table and the text segment would typically be around 200 kB. >> So the only way for the out-of-bounds read to be outside of the text >> segment (which isn't sensitive because everyone can have it) is if the >> linker placed the table in the first 0.1% of the read-only segment. >> >> That being said, in response to the SecDir review, I proposed rewriting >> that part to say: >> >> "CVE-2017-0381 is fixed by Section 7 and can only result in a 16-bit >> out-of-bounds read to a fixed location 256 bytes before a constant >> table. That location would normally be part of an executable's read-only >> data segment, but if that is not the case, the bug could at worst >> results in either a crash or the leakage of 16 bits of information from >> that fixed memory location (if the attacker has access to the decoded >> output). Despite the claims of the CVE, the bug cannot results in >> arbitrary code execution." >> >> Would that address your concerns? > > > Yes, because it moves from "think happy thoughts and everything will be > fine" to providing enough information for implementers to assess risk, and > because someone who understands security better than I do is also working > with you on this text! > > Thanks for all this. > > Spencer > >> >> Cheers, >> >> Jean-Marc >> > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec
