Every day, personal data, such as location information, images, or text queries are passed between your device and remote, cloud-based services. Your data is encrypted when in transit and at rest, but as potential attack vectors grow more sophisticated, data must also be protected during use by the service, especially for software systems that handle personally identifiable user data.

Toward this goal, Google’s Project Oak is a research effort that relies on the confidential computing paradigm to build an infrastructure for processing sensitive user data in a secure and privacy-preserving way: we ensure data is protected during transit, at rest, and while in use. As an assurance that the user data is in fact protected, we’ve open sourced Project Oak code, and have introduced a transparent release process to provide publicly inspectable evidence that the application was built from that source code. 

This blog post introduces Oak’s transparent release process, which relies on the SLSA framework to generate cryptographic proof of the origin of Oak’s confidential computing stack, and together with Oak’s remote attestation process, allows users to cryptographically verify that their personal data was processed by a trustworthy application in a secure environment. 

Integrity and transparency with SLSA  

Project Oak recently collaborated with the SLSA community to create a new container-based builder that produces Supply-chain Levels for Software Artifacts (SLSA) Build Level 3 provenance. This new container-based builder generates non-forgeable provenance statements that capture details about build process information that allow users to perform automated, rigorous provenance verification.

With this enhanced provenance generated by the container-based builder, you can answer questions like:

• Was the artifact built with a toolchain that I know and trust?

• Was the artifact built with a command that I trust?

• Did the build command use a tool that was affected by a vulnerability?

• How can I recreate the artifact?

Project Oak is particularly interested in answering these questions about every layer of the confidential computing stack. For instance, to be sure that a released binary was built using a trusted build process (e.g., the build command did not use any potentially malicious tool), the Oak release process compares the build command against a set of allow-listed tokens. Similarly, we can verify that the builder was not tampered with. 

Transparent releases: an added layer of trust

Project Oak develops a secure runtime and a remote attestation protocol—ways to detect potential adversaries on remote servers and to protect workloads while they are running. Now, with the addition of the container-based SLSA builder, we are able to complete our transparent release process to protect against software supply chain attacks and provide an automated process for verifying the integrity and trustworthiness of a remote server, before sending sensitive information to it. 

Specifically, for each released version of the Oak secure runtime, the Oak team generates and signs an endorsement statement for the binary, using a key accessible only to the Oak team. The endorsement statement can only be generated if the provenance statement passes verification checks, ensuring that a potential malicious attacker cannot forge the statement.

When the client establishes a connection to the server, the client must verify the endorsement statement and the proof of its inclusion in a transparency log, and check that the binary identities in the attestation report and the endorsement statement are the same. This, together with signature verification for the endorsement statement, guarantees three important points of trust for the overall process: that the client is interacting with the same publicly endorsed version of the Oak secure runtime that all other clients interact with; the Oak secure runtime is open source; and that it has a publicly published non-forgeable SLSA v1.0 provenance with adherence to SLSA Build Track 3. For a more technical explanation of the process, see Project Oak’s transparent release process.

Visualization of an Oak application, with attestation verification 

Try it out

We encourage you to check out the transparent release project as a use case for SLSA. Please reach out to us via our slack channel to explore ideas related to Oak secure runtimes and remote attestation.

You don’t need to use Project Oak to take advantage of the new SLSA builder tool. If your project is open source, try one of the SLSA builders to generate non-forgeable provenance for your binaries. We encourage you to containerize your build and try the container-based SLSA 3 builder! Using a container image for your builds improves the reproducibility of your binaries. We also recommend adding the instructions for building your container image (e.g., a Dockerfile) to your GitHub repository, which improves auditability and transparency of your build process, and thus the security of your software supply chain.

In 2020, we integrated kCTF into Google’s Vulnerability Rewards Program (VRP) to support researchers evaluating the security of Google Kubernetes Engine (GKE) and the underlying Linux kernel. As the Linux kernel is a key component not just for Google, but for the Internet, we started heavily investing in this area. We extended the VRP’s scope and maximum reward in 2021 (to $50k), then again in February 2022 (to $91k), and finally in August 2022 (to $133k). In 2022, we also summarized our learnings to date in our cookbook, and introduced our experimental mitigations for the most common exploitation techniques.

In this post, we’d like to share our learnings and statistics about the latest Linux kernel exploit submissions, how effective our mitigations are against them, what we do to protect our users, and, finally, how we are changing our program to align incentives to the areas we are most interested in.

Learnings and Statistics

Since its inception, the program has rewarded researchers with a total of 1.8 million USD, and in the past year, there has been a clear trend: 60% of the submissions exploited the io_uring component of the Linux kernel (we paid out around 1 million USD for io_uring alone). Furthermore, io_uring vulnerabilities were used in all the submissions which bypassed our mitigations.

Limiting io_uring

To protect our users, we decided to limit the usage of io_uring in Google products: 

• ChromeOS: We disabled io_uring (while we explore new ways to sandbox it).

• Android: Our seccomp-bpf filter ensures that io_uring is unreachable to apps. Future Android releases will use SELinux to limit io_uring access to a select few system processes. 

• GKE AutoPilot: We are investigating disabling io_uring by default.

• It is disabled on production Google servers.

While io_uring brings performance benefits, and promptly reacts to security issues with comprehensive security fixes (like backporting the 5.15 version to the 5.10 stable tree), it is a fairly new part of the kernel. As such, io_uring continues to be actively developed, but it is still affected by severe vulnerabilities and also provides strong exploitation primitives. For these reasons, we currently consider it safe only for use by trusted components.

Transparency

Currently, we make vulnerability details public on our spreadsheet (which now also includes CVE details), and we have summarized different exploitation techniques in our cookbook. In the future, to make our efforts more transparent and give faster feedback to the community, we will ask researchers to open-source their submissions, including the code they used.

Introducing kernelCTF

To better align incentives with our areas of interest, we are shifting our focus from GKE and kCTF to the latest stable kernel and our mitigations. As a result, starting today we will handle kernel exploit submissions under a new name, “kernelCTF,” with its own reward structure and submission process. The maximum total payout for kernelCTF is still $133,337 per submission. While the specific GKE kernel configuration is still covered by the new kernelCTF, exploits affecting non-kernel components like the full GKE stack (including Kubernetes), the container runtime, and GKE itself, are now separately eligible for vulnerability rewards under the kCTF VRP which is returning to its original reward amounts and conditions.

Conclusion

Our goal remains the same: we are building a pipeline to analyze, experiment, measure, and build security mitigations to make the Linux kernel as safe as possible, with the help of the security community. We hope that over time, we will be able to implement security mitigations that make it more difficult to exploit Linux kernel vulnerabilities.

With the name change, we have moved our communication channel to #kernelctf on Discord, with a separate #kernelctf-announcements channel. Please join us there for the latest updates regarding kernelCTF.