Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 80c45a1e6ff21d51c26acad87b0a02f35357e202
      
https://github.com/WebKit/WebKit/commit/80c45a1e6ff21d51c26acad87b0a02f35357e202
  Author: Alex Christensen <achristen...@apple.com>
  Date:   2023-10-10 (Tue, 10 Oct 2023)

  Changed paths:
    M Source/WebKit/Shared/API/Cocoa/WKRemoteObjectCoder.mm

  Log Message:
  -----------
  Fix crashes from hardening _WKRemoteObjectRegistry decoding
https://bugs.webkit.org/show_bug.cgi?id=262983
rdar://113527046

Reviewed by David Kilzer.

In April 2023, I made _WKRemoteObjectRegistry deserialization stricter by not 
allowing subclasses
of the specified class to be deserialized.  To make this transition as smooth 
as possible, I added
a set of common and safe always-allowed subclasses including NSMutableString 
and several others.
Telemetry indicates this increased the crash rate and this is to bring that 
crash rate back down.

After analyzing 100% of the recent crash reports with useful data, I found 4 
things that will help:
1. Allowing a class named "NSDecimalNumberPlaceholder" which is a subclass of 
NSDecimalNumber that
   some internal frameworks apparently use and give to Safari in a path that 
serializes it.  Allow this.
2. Some crash logs indicate that NSDate objects are failing to decode because 
they are not in the
   set of allowed classes.  There are some JS to ObjC object converters (such 
as the one used in
   WKWebView.callAsyncJavaScript) that can produce an NSDate, and this is ok 
and safe.  Allow this too.
3. There are logs that indicate that sometimes a class is being sent from one 
process to another,
   and the receiving process has not loaded the dylib containing the ObjC class 
so the ObjC runtime
   can't find it.  Add telemetry to get this class name for future diagnosis.
4. There are logs that indicate that sometimes a class is being sent that does 
not conform to
   NSSecureCoding according to NSCoder.  Also add telemetry to get this class 
name for future diagnosis,
   but in this case I needed to add a @try/@catch because 
validateClassSupportsSecureCoding either
   returns YES or throws an ObjC exception, so to get the class name to 
CRASH_WITH_INFO I need to catch.

* Source/WebKit/Shared/API/Cocoa/WKRemoteObjectCoder.mm:
(alwaysAllowedClasses):
(validateClass):
(decodeObject):

Canonical link: https://commits.webkit.org/269185@main


_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to