New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 1 user
Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Sep 2014
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Security

Blocking:
issue 416449



Sign in to add a comment
Out-of-bounds write in the browser via P2PHostMsg_Send IPC
Project Member Reported by jww@chromium.org, Sep 22 2014 Back to list
P2PHostMsg_Send OOB - renderer controlled strp_auth_tag_len to memcpy :-(

Exploit meta bug:  issue 416449 

An out-of-bounds write in socket_host.cc can be caused by a renderer controlled IPC message.

Summary:

In socket_host.cc, UpdateRtpAuthTag takes renderer-controlled data from the PacketOptions IPC struct (namely srtp_auth_tag_len) and does a memcpy. This can be used to corrupt the first 4 bytes of TCMalloc size class. Other problems exist as well, details below.

More details, from Juri's exploit writeup:

P2PHostMsg_Send takes a PacketOptions argument:
content/browser/renderer_host/p2p/socket_dispatcher_host.cc:136:
  IPC_MESSAGE_HANDLER(P2PHostMsg_Send, OnSend)
content/browser/renderer_host/p2p/socket_dispatcher_host.cc:269:
void P2PSocketDispatcherHost::OnSend(int socket_id,
                                     ...
                                     const rtc::PacketOptions& options,
PacketOptions contains int srtp_auth_tag_len:
third_party/webrtc/base/asyncpacketsocket.h:24:
struct PacketTimeUpdateParams { ...
  int srtp_auth_tag_len;            // Authentication tag length.
  int64 srtp_packet_index;          // Required for Rtp Packet authentication.
};
...
struct PacketOptions {
  ...
  PacketTimeUpdateParams packet_time_params;
};
Which is renderer-controlled:
content/common/p2p_messages.h:33:
IPC_STRUCT_TRAITS_BEGIN(rtc::PacketTimeUpdateParams)
  ...
  IPC_STRUCT_TRAITS_MEMBER(srtp_auth_tag_len)
  IPC_STRUCT_TRAITS_MEMBER(srtp_packet_index)
And leads to memory corruption:
content/browser/renderer_host/p2p/socket_host.cc:131:
void UpdateRtpAuthTag(char* rtp, int len,
                      const rtc::PacketOptions& options) {
  ...
  size_t tag_length = options.packet_time_params.srtp_auth_tag_len;
  char* auth_tag = rtp + (len ­ tag_length);
  ...
  if (hmac.DigestLength() < tag_length) {
    NOTREACHED();
    return;
  }
  ...
  memcpy(auth_tag, &options.packet_time_params.srtp_packet_index, 4);
  ...
  memcpy(auth_tag, output, tag_length);By setting srtp_auth_tag_len = 0, the first memcpy OOB writes 4 bytes at rtp + len. We control 
len, so we can corrupt the first 4 bytes of any TCMalloc size class.
At first glance, the second memcpy looks worse because we control tag_length, but it's actually 
constrained by maximum tag_length == DigestLength() == 20 and minimum len == 12. I think 
it can be used to OOB write the last 4 bytes of arbitrary TCMalloc size class, but I haven't tried it.
There are more issues with socket_host.cc.
socket_host.cc:83: 2-byte OOB read and integer overflow:
  uint16 extn_length = rtc::GetBE16(rtp + 2) * 4;
socket_host.cc:226: 1-byte OOB read if length == 0:
  if (IsTurnChannelData(packet)) {
socket_host.cc:246: 2-byte OOB read if length == 0:
  } else if (IsTurnSendIndicationPacket(packet)) {
socket_host.cc:276: up to 3 byte OOB read if rtp_begin == length ­ 1:
  uint16 attr_type, attr_length;
  // Getting attribute type and length.
  attr_type = rtc::GetBE16(&packet[rtp_begin]);
  attr_length = rtc::GetBE16(
      &packet[rtp_begin + sizeof(attr_type)]);
socket_host.cc:281: length check doesn't account for the 4 bytes taken by attr_type and 
attr_length:
  // Checking for bogus attribute length.
  if (length < attr_length + rtp_begin) {
    return false;  }
socket_host.cc:384: missing bounds check for len:
    while (rtp ­ extn_start < extn_length) {
      ...
      const int len = (*rtp & 0x0F) + 1;
      ...
        UpdateAbsSendTimeExtnValue(rtp + kOneByteHdrLen, len, abs_send_time);
socket_host.cc:112: shouldn't use a DCHECK:
  DCHECK_EQ(len, kAbsSendTimeExtnLen);
socket_host.cc:124: 3-byte OOB write:
  extn_data[0] = static_cast<uint8>(now_second >> 16);
  extn_data[1] = static_cast<uint8>(now_second >> 8);
  extn_data[2] = static_cast<uint8>(now_second);
socket_host.cc:396: OOB read before bounds check:
  while ((*rtp == 0) && (rtp ­ extn_start < extn_length)) {
 
Comment 1 by jww@chromium.org, Sep 22 2014
Labels: Cr-Internals-RealTimeComm
Comment 2 by wfh@chromium.org, Sep 22 2014
Cc: jiayl@chromium.org brettw@chromium.org
Summary: Out-of-bounds write in the browser via P2PHostMsg_Send IPC (was: Out-of-bounds write in the browser via P2PHostMsg_Sond IPC)
Cc: -jiayl@chromium.org mallinath@chromium.org phoglund@chromium.org ronghuawu@chromium.org
Owner: jiayl@chromium.org
Status: Assigned
Jiayl@, can you please take a look asap or suggest owner. We want this to go into m38, so need fix this week.
Labels: M-38
Comment 5 by wfh@chromium.org, Sep 22 2014
Blocking: chromium:416449
Cc: -aarya@google.com aedla@chromium.org
Comment 7 by jiayl@chromium.org, Sep 22 2014
Cc: juberti@chromium.org pthatcher@chromium.org
Comment 8 by jiayl@chromium.org, Sep 22 2014
Fix sent out for CR: https://codereview.chromium.org/589183002/
Comment 9 by jww@chromium.org, Sep 22 2014
Cc: rsleevi@chromium.org
Cc: sergeyu@chromium.org
Project Member Comment 11 by clusterf...@chromium.org, Sep 22 2014
Labels: -Pri-0 Pri-1
Status: Fixed
Labels: Merge-Requested
Project Member Comment 15 by clusterf...@chromium.org, Sep 24 2014
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Comment 16 by jiayl@chromium.org, Sep 24 2014
Cc: tnakamura@chromium.org
Cc: jansson@chromium.org
Labels: -Merge-Requested Merge-Approved
Labels: Release-0-M38
Project Member Comment 21 by clusterf...@chromium.org, Dec 31 2014
Labels: -Restrict-View-SecurityNotify
Bulk update: removing view restriction from closed bugs.
Project Member Comment 22 by sheriffbot@chromium.org, Oct 1 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member Comment 23 by sheriffbot@chromium.org, Oct 2 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: allpublic
Sign in to add a comment