Google Chrome: Privilege Escalation from Renderer Process to Browser Process

[GoogleCodeExporter]

There is an overflow in the ui::PlatformCursor WebCursor::GetPlatformCursor 
method. In 
src/content/common/cursors/webcursor_aurax11.cc&q=webcursor_aurax11.cc, there 
is the following code:

bitmap.allocN32Pixels(custom_size_.width(), custom_size_.height());
memcpy(bitmap.getAddr32(0, 0), custom_data_.data(), custom_data_.size());

The bitmap buffer is allocated based on the width and height of the 
custom_size_, but the memcpy is performed using the size of the custom_data_.

These values are set during WebCursor deserialization in 
src/content/common/cursors/webcursor.cc in WebCursor::Deserialize.

custom_size_ is set from two integers that a deserialized from a message and 
can be between 0 and 1024. custom_data_ is set from a vector that is 
deserialized, and can be any size, unrelated to the width and height. The 
custom_data_ is verified not to be smaller than the expected pixel buffer based 
on the width and height, but can be longer.

GetPlatformCursor is called indirectly by RenderWidgetHostImpl::OnSetCursor, 
which is called in response to a  ViewHostMsg_SetCursor message from the 
renderer.

The issue above is in the x11 implementation, but it appears also affect other 
platform-specific implementations other than the Windows one, which instead 
reads out of bounds.

I recommend this issue be fixed by changing the check in WebCursor::Deserialize:

if (size_x * size_y * 4 > data_len)
    return false;

to

if (size_x * size_y * 4 != data_len)
    return false;

to prevent the issue in all platform-specific implementations.

To reproduce the issue replace WebCursor::Serialize with:

bool WebCursor::Serialize(base::Pickle* pickle) const {

  if(type_ == WebCursorInfo::TypeCustom){
  LOG(WARNING) << "IN SERIALIZE\n";
  if (!pickle->WriteInt(type_) ||
      !pickle->WriteInt(hotspot_.x()) ||
      !pickle->WriteInt(hotspot_.y()) ||
      !pickle->WriteInt(2) ||
      !pickle->WriteInt(1) ||
      !pickle->WriteFloat(custom_scale_))
     return false;
   }else{

     if (!pickle->WriteInt(type_) ||
      !pickle->WriteInt(hotspot_.x()) ||
      !pickle->WriteInt(hotspot_.y()) ||
      !pickle->WriteInt(custom_size_.width()) ||
      !pickle->WriteInt(custom_size_.height()) ||
      !pickle->WriteFloat(custom_scale_))
    return false;

  }
  const char* data = NULL;
  if (!custom_data_.empty())
    data = &custom_data_[0];
  if (!pickle->WriteData(data, custom_data_.size()))
    return false;

  return SerializePlatformData(pickle);
}

and visit the attached html page, with the attached image in the same directory.

This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without a broadly available patch, then the bug report will automatically
become visible to the public.

Original issue reported on code.google.com by natashe...@google.com on 3 Dec 2015 at 1:48

Attachments:

• cursor.html
• test.gif

[GoogleCodeExporter]

This is Chrome issue https://code.google.com/p/chromium/issues/detail?id=565023

Original comment by natashe...@google.com on 3 Dec 2015 at 1:50

[GoogleCodeExporter]

Original comment by natashe...@google.com on 17 Dec 2015 at 11:18

• Removed labels: Restrict-View-Commit

[GoogleCodeExporter]

Why is this not restricted? The linked Chromium issue is currently restricted...

Original comment by phistuck on 30 Dec 2015 at 7:17

[GoogleCodeExporter]

The fix for this was released with Chrome 47.0.2526.106

Original comment by wfh@chromium.org on 30 Dec 2015 at 9:00

[GoogleCodeExporter]

If this is not restricted, the Chromium issue should not be restricted (barring 
sensitive information within the issue, of course)...

Original comment by phistuck on 30 Dec 2015 at 9:37

[GoogleCodeExporter]

Nothing new or strange with different projects having different disclosure 
practices.

P0 choose to disclose immediately the issue is fixed, but Chromium opens up 
bugs automatically a number of weeks after the issue is fixed in Stable.

Original comment by wfh@chromium.org on 30 Dec 2015 at 12:48

[GoogleCodeExporter]

Original comment by natashe...@google.com on 4 Feb 2016 at 12:53

• Changed state: Fixed