Authors: tiszka@chromium.org, bookholt@chromium.org, mattdr@chromium.org
In this document we outline how WebGPU works through the mind of an attacker, our vulnerability research methodologies, and our thought processes in some of the more difficult research areas. There are many interesting portions of Chrome graphics that we omitted from review to keep scope manageable. While our primary focus was WebGPU, we did explore a few attack surfaces shared by other graphics features. We will interleave background information on WebGPU with descriptions of the important bugs we found. We hope this report will give the security community a deeper understanding of the shape of vulnerabilities we may come to expect with the addition of WebGPU, along with a lens into the vulnerabilities we might encounter in the future.
The graphics stack has long been an area of interest for Chrome Security. Before we dive into WebGPU internals, consider the diagram below showing a simplified view of the Chrome graphics architecture.
Show above: Attackers' perspective of Chrome graphics.
The Chrome process model uses sandboxing to create layered security boundaries between untrusted content from the web and protected user data. However, the rapid evolution and high complexity of Chrome's accelerated graphics features coupled with their need to interface directly with drivers in the kernel, as well as their implementation in memory-unsafe languages mean bugs in graphics code are especially useful for bypassing Chrome sandbox boundaries. Furthermore, although Chrome sets the industry standard for rapidly fixing security bugs and quickly shipping updates to users, the presence and exposure of code supported by third parties creates challenges to getting fixes to users rapidly that can lengthen the period when a vulnerability may be viable for exploitation, reducing the cost attackers must bear to sustain a capability.
WebGPU entered Origin Trial in mid-2022 marking the first time web developers and users got to experience the new features. Coincidentally, the Chrome Offensive Security team decided to look into WebGPU as our first major research target.
According to the WebGPU spec, “WebGPU exposes an API for performing operations, such as rendering and computation, on a Graphics Processing Unit”. Unlike WebGL, its predecessor that set out with similar goals, WebGPU isn't an existing native API ported to the Web; WebGPU is a new API designed to surface the functionality of existing graphics APIs like Vulkan, Metal, and Direct3D. In the context of this document we will only be discussing Vulkan as it is ubiquitously reachable on every platform that WebGPU supports either through the GPU rendering pipeline or the software rendering pipeline.
WebGPU introduces two unique attack surfaces to Chrome that will come with their own challenges:
While they are related and shader compilation is accessible via web-exposed APIs, they pose two unique challenges so we will dig into both attack surfaces separately.
To give you the big picture first, the diagram below shows the slice of the Chrome graphics stack required for WebGPU. While WebGPU has many pieces and inter-connections, we omitted a great many notable portions of Chrome's graphics attack surface, including WebGL, Skia, Canvas2D, Widevine DRM, and video decoding for the sake of avoiding complexity explosion.
Shown above: The full Chrome WebGPU stack.
The WebGPU API is exposed via JavaScript which calls into Dawn, the library within Chrome that implements WebGPU.
Dawn is separated into two different libraries: Dawn Wire and Dawn Native. Dawn Wire is a client-server implementation of WebGPU. When a WebGPU API call is made from JavaScript the request is serialized in the renderer process using the Dawn Wire Client, the serialized blob is passed to the GPU process using WebGPU extensions to the Chrome GPU Command Buffer (WebGPUDecoderImpl) , and then deserialized in the GPU process by Dawn Wire Server. Dawn Wire Server then calls into Dawn Native which is the “native” implementation of WebGPU that wraps the underlying platform's GPU APIs.
This portion of the review focused on the WebGPU API implementation from Blink to Dawn Backends. We also chose to scope our review to Dawn‘s Vulkan Backend because it is reachable on every WebGPU platform and it is the only platform that’s fuzzable with ClusterFuzz since most of the Vulkan Backend code can be exercised without a physical GPU.
