[webkit-changes] [WebKit/WebKit] 76a6ff: nonce hiding in SVG is buggy

Wed May 22 09:31:48 PDT 2024

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 76a6ff4a88da11885fb1c5b8af8b41bf0a7844b5
      https://github.com/WebKit/WebKit/commit/76a6ff4a88da11885fb1c5b8af8b41bf0a7844b5
  Author: Ryosuke Niwa <rniwa at webkit.org>
  Date:   2024-05-22 (Wed, 22 May 2024)

  Changed paths:
    A LayoutTests/http/tests/security/contentSecurityPolicy/nonce-hiding-on-svg-script-expected.txt
    A LayoutTests/http/tests/security/contentSecurityPolicy/nonce-hiding-on-svg-script.py
    M Source/WebCore/dom/ScriptElement.cpp
    M Source/WebCore/svg/SVGElement.cpp

  Log Message:
  -----------
  nonce hiding in SVG is buggy
https://bugs.webkit.org/show_bug.cgi?id=268598
rdar://122151552

Reviewed by Chris Dumez.

The bug was caused by SVGElement::insertedIntoAncestor hiding nonce after it had an early exit for returning
InsertedIntoAncestorResult::NeedsPostInsertionCallback. Fixed the bug by hiding it before this early exit.

* LayoutTests/http/tests/security/contentSecurityPolicy/nonce-hiding-on-svg-script-expected.txt: Added.
* LayoutTests/http/tests/security/contentSecurityPolicy/nonce-hiding-on-svg-script.py: Added.
* Source/WebCore/dom/ScriptElement.cpp:
(WebCore::ScriptElement::didFinishInsertingNode):
* Source/WebCore/svg/SVGElement.cpp:
(WebCore::SVGElement::insertedIntoAncestor):

Originally-landed-as: 272448.567 at safari-7618-branch (d915a3b6357c). rdar://128504044
Canonical link: https://commits.webkit.org/279131@main

  Commit: 9e5283739c9809f145488a20f8a52f09fd3a85f4
      https://github.com/WebKit/WebKit/commit/9e5283739c9809f145488a20f8a52f09fd3a85f4
  Author: Chris Dumez <cdumez at apple.com>
  Date:   2024-05-22 (Wed, 22 May 2024)

  Changed paths:
    M Source/WebCore/workers/WorkerOrWorkletThread.cpp

  Log Message:
  -----------
  Flaky crash under WorkerDedicatedRunLoop::runCleanupTasks() during fuzzing
https://bugs.webkit.org/show_bug.cgi?id=269731
rdar://121961101

Reviewed by Brent Fulgham.

I haven't been able to reproduce but based on the ASAN report, it looks
like the WorkerOrWorkletGlobalScope is getting destroyed in the middle
of WorkerDedicatedRunLoop::runCleanupTasks(), causing a use-after free
of the context.

To make sure this can't happen, apply our smart pointer adoption rules
and make sure the WorkerOrWorkletGlobalScope is being protected on the
stack at the call site of WorkerDedicatedRunLoop::run() before passing
it in argument.

* Source/WebCore/workers/WorkerOrWorkletThread.cpp:
(WebCore::WorkerOrWorkletThread::runEventLoop):

Originally-landed-as: 272448.578 at safari-7618-branch (459d377c63c2). rdar://128504577
Canonical link: https://commits.webkit.org/279132@main

  Commit: 5944980db644fb2ea879bf3e2d6e5efd47156cdc
      https://github.com/WebKit/WebKit/commit/5944980db644fb2ea879bf3e2d6e5efd47156cdc
  Author: Wenson Hsieh <wenson_hsieh at apple.com>
  Date:   2024-05-22 (Wed, 22 May 2024)

  Changed paths:
    M Source/WebCore/loader/EmptyClients.cpp
    M Source/WebCore/page/EditorClient.h
    M Source/WebCore/page/LocalFrame.cpp
    M Source/WebKit/UIProcess/WebPageProxy.cpp
    M Source/WebKit/UIProcess/WebPageProxy.h
    M Source/WebKit/UIProcess/WebPageProxy.messages.in
    M Source/WebKit/WebProcess/WebCoreSupport/WebEditorClient.cpp
    M Source/WebKit/WebProcess/WebCoreSupport/WebEditorClient.h
    M Source/WebKit/WebProcess/WebPage/WebPage.cpp
    M Source/WebKit/WebProcess/WebPage/WebPage.h
    M Source/WebKitLegacy/mac/WebCoreSupport/WebEditorClient.h

  Log Message:
  -----------
  Compromised web process can grant pasteboard access by spamming WebPage::RequestDOMPasteAccess
https://bugs.webkit.org/show_bug.cgi?id=269769
rdar://97343267

Reviewed by Ryosuke Niwa and Richard Robinson.

It's currently possible for a compromised web process to send arbitrary `originIdentifiers` through
`requestDOMPasteAccess` to the UI process during programmatic paste. Since the UI process
automatically grants programmatic pasteboard access in the case where the incoming origin ID matches
the origin ID of the current pasteboard content, it's possible to send a large number of origins
through this IPC endpoint, with the end goal of discovering both (1) which website origin the user
last copied from, and (2) the contents of the pasteboard in the case where the pasteboard copied
from web content in WebKit.

To mitigate this attack vector, we add a `FrameIdentifier` in the IPC endpoint, which is used in the
UI process to verify that:

1.  The incoming frame ID corresponds to a frame underneath the destination page.
2.  The pasteboard origin matches the origin of the frame, unless the pasteboard origin is an opaque
    (null) origin.

Additionally, we throttle pasteboard access requests to a maximum of 10 different domains every 5
seconds, to mitigate another variation on this attack vector where the compromised web process loads
a large number of cross-origin frames and requests pasteboard access on behalf of those origins, in
an attempt to get around the limitations above.

With this change, a compromised web process is only capable of grabbing data for a pasteboard origin
that matches itself, or another origin under the same `WebPage`.

* Source/WebCore/loader/EmptyClients.cpp:
* Source/WebCore/page/EditorClient.h:
* Source/WebCore/page/LocalFrame.cpp:
(WebCore::LocalFrame::requestDOMPasteAccess):
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::requestDOMPasteAccess):

Add the new `MESSAGE_CHECK`s.

* Source/WebKit/UIProcess/WebPageProxy.h:
* Source/WebKit/UIProcess/WebPageProxy.messages.in:
* Source/WebKit/WebProcess/WebCoreSupport/WebEditorClient.cpp:
(WebKit::WebEditorClient::requestDOMPasteAccess):
* Source/WebKit/WebProcess/WebCoreSupport/WebEditorClient.h:
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::requestDOMPasteAccess):
* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Source/WebKitLegacy/mac/WebCoreSupport/WebEditorClient.h:

Originally-landed-as: 272448.579 at safari-7618-branch (be0e10372eb5). rdar://128504822
Canonical link: https://commits.webkit.org/279133@main

  Commit: 2d8b1474ab48e248a1548ed59cf91fd1223b381f
      https://github.com/WebKit/WebKit/commit/2d8b1474ab48e248a1548ed59cf91fd1223b381f
  Author: Wenson Hsieh <wenson_hsieh at apple.com>
  Date:   2024-05-22 (Wed, 22 May 2024)

  Changed paths:
    M Source/WebKit/UIProcess/API/APIAttachment.h
    M Source/WebKit/UIProcess/API/Cocoa/APIAttachmentCocoa.mm
    M Source/WebKit/UIProcess/Cocoa/WebPageProxyCocoa.mm
    M Source/WebKit/UIProcess/WebPageProxy.cpp

  Log Message:
  -----------
  Harden IPC endpoints for decoding images from arbitrary file wrappers when using the attachment API
https://bugs.webkit.org/show_bug.cgi?id=269877
rdar://99194803

Reviewed by Abrar Rahman Protyasha and Aditya Keerthi.

It's currently possible for a compromised web process to use two IPC endpoints:

• `WebPageProxy::RegisterAttachmentsFromSerializedData`
• `WebPageProxy::RequestAttachmentIcon`

...in order to force image decoding through an `NSFileWrapper` created from arbitrary data,
underneath a call to `-[NSFileWrapper icon]`. This icon image is only meant to be used to generate
icons for folder attachments (e.g. a bundle icon for bundle directories, or Xcode icon for Xcode
projects), and should only ever be exercised in the case where the file wrapper was created from an
existing file path on the system (as opposed to untrusted data directly from the web process).

As such, we can lock this down by:

1.  Adding a `m_isCreatedFromSerializedRepresentation` flag, to track whether an `API::Attachment`
    was created using an arbitrary serialized representation.

2.  Before asking for `-icon`, verify that the file wrapper doesn't have the flag set in (1), and
    that the file wrapper is also actually a directory.

* Source/WebKit/UIProcess/API/APIAttachment.h:
* Source/WebKit/UIProcess/API/Cocoa/APIAttachmentCocoa.mm:
(API::Attachment::updateFromSerializedRepresentation):
(API::Attachment::cloneFileWrapperTo):
(API::Attachment::shouldUseFileWrapperIconForDirectory const):
* Source/WebKit/UIProcess/Cocoa/WebPageProxyCocoa.mm:
(WebKit::WebPageProxy::platformCloneAttachment):

Add logic here to ensure that a compromised web content process can't bypass the aforementioned
mitigation by cloning an attachment created from arbitrary data to an attachment that doesn't have
the `m_isCreatedFromSerializedRepresentation` flag.

* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::requestAttachmentIcon):

Originally-landed-as: 272448.599 at safari-7618-branch (6d9bbe958980). rdar://128505199
Canonical link: https://commits.webkit.org/279134@main

Compare: https://github.com/WebKit/WebKit/compare/2c9a11ae2283...2d8b1474ab48

To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications