Prevent size_t underflow in H264 SPS parsing.

webrtc/modules/rtp_rtcp/source/h264_sps_parser.cc

Index: webrtc/modules/rtp_rtcp/source/h264_sps_parser.cc
diff --git a/webrtc/modules/rtp_rtcp/source/h264_sps_parser.cc b/webrtc/modules/rtp_rtcp/source/h264_sps_parser.cc
index b022b21165daa93195b1ffd638d58939498d7af5..034e761dcd4d30177d86982f47e5c8ce28508c68 100644
--- a/webrtc/modules/rtp_rtcp/source/h264_sps_parser.cc
+++ b/webrtc/modules/rtp_rtcp/source/h264_sps_parser.cc
@@ -36,8 +36,8 @@ bool H264SpsParser::Parse() {
   // section 7.3.1 of the H.264 standard.
   rtc::ByteBuffer rbsp_buffer;
   for (size_t i = 0; i < byte_length_;) {
-    if (i < byte_length_ - 3 &&
-        sps_[i] == 0 && sps_[i + 1] == 0 && sps_[i + 2] == 3) {
+    if (i + 3 < byte_length_ && sps_[i] == 0 && sps_[i + 1] == 0 &&

[stefan-webrtc, 2015/07/01 09:59:13]

Interesting bug. :)

[noahric, 2015/07/01 16:34:38]

I think this introduced a separate bug, though you'll never hit it (or the one
it fixed) in practice. You should have just added a byte_length_ >= 3 check at
the front.

The new bug is that if byte_length_ is really near size_t max, then i + 3 will
wrap at various points, so you could end up with an infinite loop:
sps_[0] == 3
...
sps_[byte_length_ - 1] == 0
sps_[byte_length_] == 0
and i == byte_length_ - 1 and byte_length_ == size_t max, then:

i + 3 == 1, which is < byte_length_
sps_[i] == 0, sps[i + 1] == 0, sps[i + 2] == 3
So it'd write 0, 0, then do i+=3, which makes i == 1 again.

(I'm still on pain meds, so that may be not quite right, but please take another
look)

[pbos-webrtc, 2015/07/01 18:12:29]

So just to clarify: The bug I fixed gets hit from malicious/corrupt packets. The
overflow bug you're mentioned gets hit if there's a packet near SIZE_MAX which I
think can never happen in practice for a bunch of reasons; not sure if any
system will ever let you allocate SIZE_MAX bytes due to malloc overhead etc. in
which case there's no block that can be fed here. On any systems we support
SIZE_MAX is going to be 4GB or above, and there's no way of putting that on the
wire afaict. A jumbogram will theoretically do it, but if it's encapsulated by
RTP, then RTP's header is > 3, so this theoretical overflow won't ever happen in
RTP.

If you can fix this theoretical overflow without making the code confusing I'm
all for it, but I think even checking i against SIZE_MAX makes this confusing.
If there's another overall h264 packetization max size that we can check in the
h264 depacketizer that sounds like a better way to do it.

[noahric, 2015/07/01 18:49:24]

I think the most readable fix is:

if (byte_length_ - i >= 3 ...

Meant to be read as: "If there are at least 3 bytes left in the sequence".

Since i is always < byte_length_, that shouldn't underflow, and it'll prevent
overflow since byte_length_ can't be greater than SIZE_MAX.

That also fixes an existing bug where a 0 0 3 at the end of the rbsp would get
skipped. That's not a legal sps anyways, so it'd probably fail for other reasons
and give the correct result, but seems sensible to fix it here.

[pbos-webrtc, 2015/07/02 07:37:50]

Slightly less readable in my opinion, but I won't fight about this one if you
want to push it in.
I have no idea what this is or even means. It should only be affected if it's
near SIZE_MAX, correct?

+        sps_[i + 2] == 3) {
       // Two rbsp bytes + the emulation byte.
       rbsp_buffer.WriteBytes(sps_bytes + i, 2);
       i += 3;