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

Issue metadata

Status: Fixed
Owner:
Closed: Sep 2014
Cc:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 0
Type: Bug-Security

Blocked on:
issue 416526
issue 416528

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment
link

Issue 416449: Chrome exploit: V8 properties + P2PHostMsg_Send

Reported by aedla@chromium.org, Sep 22 2014 Project Member

Issue description

See writeup.pdf.

1. V8 slow / fast properties confusion

Code in src/objects.cc:4089:
MaybeHandle<Object> JSObject::SetOwnPropertyIgnoreAttributes(
  ..
  object­>LookupOwn(name, &lookup, true);
  ..
  if (is_observed && lookup.IsProperty()) { 
    if (lookup.IsDataProperty()) { 
      old_value = Object::GetPropertyOrElement(object, name).ToHandleChecked(); 
    } 
    old_attributes = lookup.GetAttributes(); 
  } 
  ..
  switch (lookup.type()) { 
    case NORMAL: 
      ReplaceSlowProperty(object, name, value, attributes);

GetPropertyOrElement() can invoke a getter. The getter can transform object to fast properties, confusing ReplaceSlowProperty() into corrupting memory. The lookup.IsDataProperty() actually checks whether name is a getter. And it takes some trickery to get past that. See writeup.pdf.

This bug was fixed by refactoring on August 18, but still impacts current stable and beta. I got the renderer arbitrary R/W to work on Android and 64-bit linux. I think it should work on Windows as well.


2. P2PHostMsg_Send OOB write

content/browser/renderer_host/p2p/socket_dispatcher_host.cc:269:
void P2PSocketDispatcherHost::OnSend(int socket_id,
                                     ...
                                     const rtc::PacketOptions& options,

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

The srtp_auth_tag_len field is renderer-controlled and lacks validation. The first memcpy OOB writes 4 bytes if srtp_auth_tag_len == 0. socket_host.cc also has a bunch of other issues. See writeup.pdf.


Chrome Version:
  37.0.2062.120 stable
  38.0.2125.66 beta

Operating System:
  Renderer R/W: all
  Sandbox break: 64-bit linux

Reproduction:
- run ./webserver inside v8p2p/
- navigate to http://localhost:8000/v8p2p/v8p2p.html
- /etc/passwd is displayed
 
writeup.pdf
156 KB Download
v8p2p.tar.gz
180 KB Download

Comment 1 by verwa...@chromium.org, Sep 22 2014

Cc: danno@chromium.org adamk@chromium.org
Owner: rafaelw@chromium.org
Arg. Thanks for the report. Adding rafaelw@ who owns the O.o code. Adding adamk@ since rafaelw@ may still be OOO.

I'd be inclined to turn off O.o again until this is fixed (or my refactoring hits stable). I'll leave it up to adamk@ / rafaelw@ though.

Comment 2 by verwa...@chromium.org, Sep 22 2014

Cc: rossberg@chromium.org
+rossberg@: FYI

Comment 3 by verwa...@chromium.org, Sep 22 2014

Cc: rafaelw@chromium.org
Owner: verwa...@chromium.org
Status:
Ok, just assigning it to rafaelw@ was a bit premature; my apologies. There's obviously other stuff to be done. I'll pick up at least the JSON part of this.

Comment 4 by verwa...@chromium.org, Sep 22 2014

Fixed the JSON parsing part in https://codereview.chromium.org/592813002/

Comment 5 by danno@chromium.org, Sep 22 2014

Cc: parisa@chromium.org infe...@chromium.org

Comment 6 by wfh@chromium.org, Sep 22 2014

Labels: -Pri-1 Pri-0 Security_Impact-Stable Security_Severity-Critical

Comment 7 by infe...@chromium.org, Sep 22 2014

Cc: jww@chromium.org

Comment 8 by infe...@chromium.org, Sep 22 2014

Jww@, this will be the master tracking bug. Please file additional sub-bugs (blocked on this) after triaging.

Comment 9 by ClusterFuzz, Sep 22 2014

Project Member
Labels: M-37

Comment 10 by palmer@chromium.org, Sep 22 2014

And thanks again, Jüri! :) Great work as always.

Comment 11 by infe...@chromium.org, Sep 22 2014

Labels: -M-37 M-38

Comment 12 by infe...@chromium.org, Sep 22 2014

Blockedon: chromium:416526

Comment 13 by aedla@chromium.org, Sep 22 2014

Hey Chris, thanks :)

If you guys would cc me on sub-bugs, that would be great.

Comment 14 by wfh@chromium.org, Sep 22 2014

Blockedon: chromium:416528
Labels: -Security_Impact-Stable Security_Impact-None
impact -> none, severity -> critical, as this is the parent bug.  See child bugs -  issue 416526  and  issue 416528 .

Comment 15 by infe...@chromium.org, Sep 22 2014

Thanks Juri, cced you on both.

Comment 16 by ClusterFuzz, Sep 22 2014

Project Member
Labels: -Security_Impact-None Security_Impact-Beta

Comment 17 by adamk@chromium.org, Sep 22 2014

I'm probably a better Object.observe contact for this than Rafael. Can someone please CC me on the the sub-bugs?

Turning off O.o should be considered a last resort, given that it's been on by default for more than an entire release.

Comment 18 by jww@chromium.org, Sep 22 2014

adamk@, I CC'd you on the observe sub-bug.

Comment 19 by ClusterFuzz, Sep 23 2014

Project Member
Labels: ReleaseBlock-Stable

Comment 20 by verwa...@chromium.org, Sep 24 2014

Owner: yangguo@chromium.org
I don't think anything needs to be done on the O.o side. It was just a simple step along the way to provoke the bug.

The JSON part (entry-point) is fixed, and Yang backmerged a CHECK (which will crash) in SetNormalizedProperty, the backend function that was used to corrupt the heap.

Reassigning to yangguo@ since I'm unexpectedly OOO.

Comment 21 by yangguo@chromium.org, Sep 24 2014

Status: Fixed
This has been merged back to M37 and M38 with additional CHECK to prevent slow/fast mode confusion when setting a property. Marking this as fixed.

Comment 22 by amin...@google.com, Sep 24 2014

Labels: Merge-TBD
Is there a merge required here?

Comment 23 by yangguo@chromium.org, Sep 24 2014

The fix has been merged to older V8 branches:
V8 3.28.71.12 (r24162) for M38
V8 3.27.34.21 (r24125) for M37
I guess the DEPS file will need to be updated to pick up the changes in Chromium.

Comment 24 by ClusterFuzz, Sep 24 2014

Project Member
Labels: -Restrict-View-SecurityTeam Merge-Triage M-39 Restrict-View-SecurityNotify
Adding Merge-Triage label for tracking purposes.

Once your fix had sufficient bake time (on canary, dev as appropriate), please nominate your fix for merge by adding the Merge-Requested label.

When your merge is approved by the release manager, please start merging with higher milestone label first. Make sure to re-request merge for every milestone in the label list. You can get branch information on omahaproxy.appspot.com.

Your fix is very close to the branch point. After the branch happens, please make sure to check if your fix is in.

- Your friendly ClusterFuzz

Comment 25 by infe...@chromium.org, Sep 24 2014

Labels: -Merge-TBD -Merge-Triage -M-39 Merge-Merged Release-0-M38
Thanks!

Comment 26 by infe...@chromium.org, Sep 24 2014

Labels: -Merge-Merged -Release-0-M38 Merge-NA
Actually this is the meta bug, fixing labels in  bug 416526 .

Comment 27 by mbarbe...@chromium.org, Oct 6 2014

Labels: reward-topanel

Comment 28 by timwillis@chromium.org, Oct 7 2014

Labels: -reward-topanel reward-27634 reward-unpaid
Hey Jüri - the reward for this bug is $27.633.70! It's comprised of:

$15,000 for the sandbox escape + exploit
$7,500 for the renderer RCE + exploit
+$2,000 for the patch ($1,000 for the first one, plus an additional $1,000 for picking up the bug in the original patch)
+$3,133.7 for your linux l33tness IPC memory corruption on 64-bit linux!

Congratulations!

Comment 29 by timwillis@chromium.org, Oct 7 2014

Labels: CVE-2014-3188

Comment 30 by aedla@chromium.org, Oct 7 2014

Thank you!

Comment 31 by timwillis@google.com, Dec 8 2014

Labels: -reward-unpaid reward-inprogress
Payment in progress

Comment 32 by timwillis@google.com, Dec 9 2014

Labels: -reward-inprogress reward-inprocess

Comment 33 by ClusterFuzz, Dec 31 2014

Project Member
Labels: -Restrict-View-SecurityNotify
Bulk update: removing view restriction from closed bugs.

Comment 34 by timwillis@google.com, Jan 1 2015

Labels: -reward-inprocess
Processing via our e-payment system can take up to six weeks, but the reward should be on its way to you. Thanks again for your help!

Comment 35 by sheriffbot@chromium.org, Oct 1 2016

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

Comment 36 by sheriffbot@chromium.org, Oct 2 2016

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

Comment 37 by mbarbe...@chromium.org, Oct 2 2016

Labels: allpublic

Comment 38 by awhalley@chromium.org, Apr 25 2018

Labels: CVE_description-submitted

Comment 40 by jorgelo@chromium.org, Oct 3

Labels: Restrict-AddIssueComment-EditIssue

Sign in to add a comment