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

[Jean-Marc Valin <[e-mail]>]

Hi Spencer,

Thanks for the comments. See below.

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?

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

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

Cheers,

	Jean-Marc