Chromium

Setting milestone because of s2 severity.

Setting Priority to P1 to match Severity s2. If this is incorrect, please reset the priority. The automation bot account won't make this change again.

I'm looking into this. I haven't been able to reproduce the behavior with the minimized test cases, but I do see the problem with the Google Single Sign-On. At this point I can't tell whether the issue is in the javascript on that site or in the IntersectionObserver V2 implementation.

szager: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add Disable-Nags (case sensitive) to the Chromium Labels custom field.

Project: chromium/src
Branch: main

commit 78bd1f0eef2612f22dac87d0335e8714a0ecee89
Author: Stefan Zager <szager@chromium.org>
Date:   Thu May 16 05:52:33 2024

    [IntersectionObservation] Fix needs_occlusion_tracking bookkeeping
   
    This fixes three related bugs in occlusion tracking:
   
    1. When an IntersectionObserver using trackVisibility is created in an
    OOPIF, there is some latency in notifying the parent renderer that
    occlusion tracking is required for the iframe. During that interval,
    the parent renderer might send a 'guaranteed not occluded' message to
    the child, causing the IntersectionObserver to report a false
    positive. With this change, we will never tell an OOPIF that it's
    "guaranteed not occluded" if the OOPIF hasn't requested occlusion
    information. This is fixed in frame_view.cc.
   
    2. When an OOPIF runs LocalFrameView::RunIntersectionObserverSteps,
    it might get a transient `false` value when recomputing
    needs_occlusion_tracking, due to an early return from
    UpdateViewportIntersectionsForSubtree (which has a couple of
    early-return edge cases). When that happens, we should *not* relay
    the `false` value back to the parent process, because it can create
    a temporary gap in occlusion reporting from the parent. We should
    instead preserve the previous value until it can be successfully
    recomputed on a subsequent BeginMainFrame. This is fixed in
    local_frame_view.cc.
   
    2. For OOPIF's, needs_occlusion_tracking is stored in two places:
    on RemoteFrameOwner::needs_occlusion_tracking_ in the iframe process,
    and in RemoteFrameView::needs_occlusion_tracking_ in the parent
    process. When the first one changes in the iframe process, it IPC's
    to the parent process to synchronize the second one. To keep them
    consistent, there should be no other point of entry into
    RemoteFrameView::SetNeedsOcclusionTracking. Currently, that method is
    also called from RemoteFrameView::Dispose, but that call is unnecessary
    and it can cause the two values to get out of sync. This is fixed in
    remote_frame_view.cc.
   
    Bug: chromium:333708039
    Change-Id: Id1dd08eefb5aa201651b2c6950ea61f3b4a081a9
    Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5540331
    Commit-Queue: Stefan Zager <szager@chromium.org>
    Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#1301762}

M       third_party/blink/renderer/core/frame/frame_view.cc
M       third_party/blink/renderer/core/frame/local_frame_view.cc
M       third_party/blink/renderer/core/frame/remote_frame_view.cc
M       third_party/blink/web_tests/TestExpectations

https://chromium-review.googlesource.com/5540331

louisjannett@ -- thank you for the bug report and the excellent reproduction, which helped greatly in debugging. With the fix from May 16, I can no longer reproduce the bug. The fix is available in the current dev channel release on Mac (127.0.6485.0), if you'd like to try it out.

szager: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add Disable-Nags (case sensitive) to the Chromium Labels custom field.

** NOTE: This is an automatically generated email **

Hello,

Congratulations! The Chrome Vulnerability Rewards Program (VRP) Panel has decided to award you $5000.00 for this report.

Rationale for this decision:
$5,000 for high quality report (with functional exploit) of user information disclosure


Important: If you aren't already registered with Google as a supplier, p2p-vrp@google.com will reach out to you. If you have registered in the past, no need to repeat the process – you can sit back and relax, and we will process the payment soon.

If you have any payment related requests, please direct them to p2p-vrp@google.com. Please remember to include the subject of this email and the email address that the report was sent from.


Thank you for your efforts and helping us make Chrome more secure for all users!

Cheers,
Chrome VRP Panel Bot


P.S. One other thing we'd like to mention:

* Please do NOT publicly disclose details until a fix has been released to all our users. Early public disclosure may cancel the provisional reward. Also, please be considerate about disclosure when the bug affects a core library that may be used by other products. Please do NOT share this information with third parties who are not directly involved in fixing the bug. Doing so may cancel the provisional reward. Please be honest if you have already disclosed anything publicly or to third parties. Lastly, we understand that some of you are not interested in money. We offer the option to donate your reward to an eligible charity. If you prefer this option, let us know and we will also match your donation - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing.
Please contact security-vrp@chromium.org with any questions.