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

From: Spencer Dawkins <[email-masked]>
Date: Tue, 15 Aug 2017 09:40:46 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-codec-opus-update-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-codec-opus-update/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for producing this specification. I have some questions, but nothing at
Discuss level.

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.
Googling for ‘opus “extreme bitstream”’ turns up one hit for side effects from
a drug being tested, so that wasn’t much help.

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.

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.

---

From: Jean-Marc Valin <[email-masked]>
Date: Tue, 15 Aug 2017 13:22:56 -0400

Hi Spencer,

Thanks for the comments. See below.

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

> downmixed outside the decoder? Section 10 thinks decoders can know that,

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.

> 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

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 15 Aug 2017 13:22:48 -0500

Jean-Marc,

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

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

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

> 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

---

From: Warren Kumari <[email-masked]>
Date: Tue, 15 Aug 2017 17:30:11 -0400

On Tue, Aug 15, 2017 at 2:22 PM, Spencer Dawkins at IETF
<[email-masked]> wrote:
> 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

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

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