Thursday, April 18, 2024
HomeBig DataLearnings from kCTF VRP's 42 Linux kernel exploits submissions

Learnings from kCTF VRP’s 42 Linux kernel exploits submissions

In 2020, we built-in kCTF into Google’s Vulnerability Rewards Program (VRP) to assist researchers evaluating the safety of Google Kubernetes Engine (GKE) and the underlying Linux kernel. Because the Linux kernel is a key element not only for Google, however for the Web, we began closely investing on this space. We prolonged the VRP’s scope and most reward in 2021 (to $50k), then once more in February 2022 (to $91k), and eventually in August 2022 (to $133k). In 2022, we additionally summarized our learnings up to now in our cookbook, and launched our experimental mitigations for the most typical exploitation methods.

On this submit, we might prefer to share our learnings and statistics in regards to the newest Linux kernel exploit submissions, how efficient our mitigations are towards them, what we do to guard our customers, and, lastly, how we’re altering our program to align incentives to the areas we’re most keen on.

Learnings and Statistics

Since its inception, this system has rewarded researchers with a complete of 1.8 million USD, and prior to now yr, there was a transparent development: 60% of the submissions exploited the io_uring element of the Linux kernel (we paid out round 1 million USD for io_uring alone). Moreover, io_uring vulnerabilities have been utilized in all of the submissions which bypassed our mitigations.


Limiting io_uring

To guard our customers, we determined to restrict the utilization of io_uring in Google merchandise: 

Whereas io_uring brings efficiency advantages, and promptly reacts to safety points with complete safety fixes (like backporting the 5.15 model to the 5.10 steady tree), it’s a pretty new a part of the kernel. As such, io_uring continues to be actively developed, however it’s nonetheless affected by extreme vulnerabilities and in addition gives robust exploitation primitives. For these causes, we presently contemplate it secure just for use by trusted elements.


Presently, we make vulnerability particulars public on our spreadsheet (which now additionally contains CVE particulars), and we’ve summarized totally different exploitation methods in our cookbook. Sooner or later, to make our efforts extra clear and provides quicker suggestions to the group, we are going to ask researchers to open-source their submissions, together with the code they used.

Introducing kernelCTF

To raised align incentives with our areas of curiosity, we’re shifting our focus from GKE and kCTF to the newest steady kernel and our mitigations. In consequence, beginning right this moment we are going to deal with kernel exploit submissions underneath a brand new title, “kernelCTF,” with its personal reward construction and submission course of. The utmost whole payout for kernelCTF continues to be $133,337 per submission. Whereas the precise GKE kernel configuration continues to be coated by the brand new kernelCTF, exploits affecting non-kernel elements like the complete GKE stack (together with Kubernetes), the container runtime, and GKE itself, are actually individually eligible for vulnerability rewards underneath the kCTF VRP which is returning to its authentic reward quantities and situations.


Our objective stays the identical: we’re constructing a pipeline to investigate, experiment, measure, and construct safety mitigations to make the Linux kernel as secure as doable, with the assistance of the safety group. We hope that over time, we can implement safety mitigations that make it harder to take advantage of Linux kernel vulnerabilities.

With the title change, we’ve moved our communication channel to #kernelctf on Discord, with a separate #kernelctf-announcements channel. Please be a part of us there for the newest updates concerning kernelCTF.



Please enter your comment!
Please enter your name here

Most Popular

Recent Comments