Re: [codec] Spencer Dawkins' No Objection on draft-ietf-codec-opus-update-08: (with COMMENT)

[Spencer Dawkins at IETF <[e-mail]>]

Jean-Marc,

On Tue, Aug 15, 2017 at 12:22 PM, Jean-Marc Valin <[e-mail]>
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.


> > 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
>
>