WebRTC - VP9 Frame Processing Out-of-Bounds Memory Access

There is a missing check in VP9 frame processing that could lead to memory corruption.

In the file video_coding/rtp_frame_reference_finder.cc, the function RtpFrameReferenceFinder::ManageFrameVp9 fetches the GofInfo based on a pic_idx parsed from the incoming packet header. If the incoming frame is of type kVideoFrameKey, find is called on an iterator and the result is used without checking whether the it succeeds.

 if (frame->frame_type() == kVideoFrameKey) {
    ...
    GofInfo info = gof_info_.find(codec_header.tl0_pic_idx)->second;
    FrameReceivedVp9(frame->id.picture_id, &info);
    UnwrapPictureIds(frame);
    return kHandOff;
  }

This can cause a pointer to memory outside the gof_info_ map to be passed to FrameReceivedVp9. This function both reads and writes the info structure.

This issue does not crash reliably, so I recommend reproducing it using an asan build of Chrome. To reproduce the issue:

1) unzip the attached webrtc-from-chat.zip on a local webserver
2) fetch the webrtc source (https://webrtc.org/native-code/development/), and replace src/modules/rtp_rtcp/source/rtp_format_vp9.cc with the version attached to the code
3) build webrtc, including the examples
4) run the attached webrtcserver.py with python 3.6 or higher
5) start the peerconnection_client sample in the webrtc examples. Connect to the recommended server, and then select test2 as the peer to connect to
6) visit http://127.0.0.1/webrtc-from-chat/index.html in chrome
7) Enter any username and hit "Log in"
8) Type anything into the chat window at the bottom and hit send

Chrome should crash in a few seconds.

Though the attached PoC requires user interaction, it is not necessary to exercise this issue in a browser.

This issue affects any browser that supports VP9, and can be reached by loading a single webpage (though some browsers will prompt for permissions). It also affects native clients (such as mobile applications) that use webrtc and support VP9, though the user has to place or answer a video call for their client to be in the state where this issue is reachable.

I recommend fixing this by changing the above code to:

    auto gof_info_it = gof_info_.find(codec_header.tl0_pic_idx);
    if (gof_info_it == gof_info_.end())
        return kDrop;
    GofInfo info = gof_info_it->second;
    FrameReceivedVp9(frame->id.picture_id, &info);

I have verified that this fix would prevent the crash.


Proof of Concept:
https://github.com/offensive-security/exploitdb-bin-sploits/raw/master/bin-sploits/44862.zip