[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 19 Jul 2023 16:31:55 +0200
From: Tamás Koczka <poprdi@...omium.org>
To: Solar Designer <solar@...nwall.com>
Cc: oss-security@...ts.openwall.com
Subject: Re: Our learnings from 42 Linux kernel exploits, we
are limiting io_uring
Hey!
Answering the questions organized by topics, if I miss something,
please feel free to ask.
Topic 1) VRP programs
We have multiple Vulnerability Rewards Programs[1], including Android
VRP, Chrome (OS) VRP and kernelCTF (as part of Google VRP) and a
vulnerability can be eligible for multiple programs as long as the
reporters are following the respective rules of the different
programs.
I am working on kernelCTF (previously: kCTF VRP), and as far as I know
the program rules are not synchronized explicitly, it is possible that
there are cases where the different VRP programs are not compatible.
We encourage researchers to contact us if they run into a conflict
like this and we will look into what we can do.
The disclosure policies are also different in different VRP programs,
kernelCTF requires researchers to publish all the details of the
vulnerabilities, exploits and techniques they are using.
Topic 2) Android, CVE-2023-21400, io_uring
For kernelCTF / kCTF VRP did not get a submission for CVE-2023-21400
(this can be tracked on our public spreadsheet[2]), but I read about
this vuln in the news and I personally think the prerequisite for the
exploit that you are already running in a non-Zygote process[3] (e.g.
adb shell) where you are not limited by seccomp.
Seccomp is only applied by processes forked from the Zygote process,
which is true for Android user apps, but not for e.g. system services,
components. The future SELinux policy[4] will limit the io_uring
attack surface to only fastbootd and snapuserd (but won't allow e.g.
adbd). Based on this I believe CVE-2023-21400 is not exploitable
directly from a malicious app, you need to get code execution in a
system component and then you can use CVE-2023-21400 to elevate your
privileges to root.
I think (again, personal opinion) it's factored in the Medium
severity[5], and system app -> root is only considered as "A general
bypass for operating system protections" (Medium) and not a "Local
arbitrary code execution in ... the OS Kernel" (High).
Topic 3) Disclosure details
The submission workflow[6] explains in more detail what we consider as
a disclosure, but tl;dr: either a CVE or an oss-sec post.
> 4) Wait for us to publish the CVE or publish the vulnerability details yourself on oss-sec.
> 5) After the vulnerability is disclosed via a CVE or oss-sec, wait 30 days (recommendation, see notes below) and send us your exploit with the description of the exploitation technique via a PR to https://github.com/google/security-research/ (see required structure below).
But thanks for the tip, maybe we will repeat this information in the
other section to keep them together.
Also thanks for the questions, I hope my answers make some aspects more clear,
Tamas
[1] https://bughunters.google.com/about/rules
[2] https://docs.google.com/spreadsheets/d/e/2PACX-1vS1REdTA29OJftst8xN5B5x8iIUcxuK6bXdzF8G1UXCmRtoNsoQ9MbebdRdFnj6qZ0Yd7LwQfvYC2oF/pubhtml#
[3] https://miro.medium.com/v2/1*oVJgKQJMm0p1-whfB6W4kg.png
[4] https://android-review.git.corp.google.com/c/platform/system/sepolicy/+/2302679
[5] https://source.android.com/docs/security/overview/updates-resources#severity
[6] https://google.github.io/security-research/kernelctf/rules.html#1-day-submissions
On Fri, Jul 14, 2023 at 8:07 PM Solar Designer <solar@...nwall.com> wrote:
>
> Hi,
>
> Thank you for bringing this to oss-security back then. I have a few
> questions below that I think you could clarify for everyone. I'll quote
> more of your message than I normally do since it's been a while.
>
> On Fri, Jun 16, 2023 at 11:43:49AM +0200, Tamas Koczka wrote:
> > We've posted the following article to the Google Security Blog which
> > contains some of our learnings from 42 Linux kernel exploits we got so
> > far on our kCTF VRP and the actions we are taking based on these
> > learnings (tl;dr: we are limiting io_uring in our products):
> >
> > =======================
> > In 2020[1], 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[2] (to $50k), then again in February
> > 2022[3] (to $91k), and finally in August 2022[4] (to $133k). In 2022,
> > we also summarized our learnings to date in our cookbook[5], and
> > introduced our experimental mitigations[6] 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[7] 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[8] 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[9] io_uring (while we explore new ways to sandbox it).
> >
> > * Android: Our seccomp-bpf filter[10] 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[11].
> >
> > * 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[12] 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.
>
> There's a recent write-up on an exploitation technique that also
> partially describes CVE-2023-21400, "a double free vulnerability in
> io_uring [...] found by Ye Zhang and [Nicolas Wu] last year, affecting
> kernel 5.10. [...] we exploit CVE-2023-21400 with Dirty Pagetable on
> Google Pixel 7."
>
> Dirty Pagetable: A Novel Exploitation Technique To Rule Linux Kernel
> https://yanglingxi1993.github.io/dirty_pagetable/dirty_pagetable.html
>
> I wish this vulnerability and exploitation technique were properly
> brought to oss-security on its own, and in a context not limited to
> Google Pixel. Maybe it will be once the full description is made
> public, as right now the write-up above omits vulnerability detail.
>
> It appears that this got patched in the July 5 update for Google Pixel:
>
> Pixel Update Bulletin - July 2023
> Published July 5, 2023
> https://source.android.com/docs/security/bulletin/pixel/2023-07-01
>
> "For Google devices, security patch levels of 2023-07-05 or later
> address all issues in this bulletin and all issues in the July 2023
> Android Security Bulletin."
>
> "CVE-2023-21400 A-264663832 * EoP Moderate Kernel io_uring"
>
> Nothing is mentioned about seccomp-bpf on either of the above web pages,
> although maybe it's factored into the Moderate severity rating?
>
> I understand that with vulnerability detail still not public you might
> not be able to tell much, but I am wondering whether there's any
> inconsistency here (seccomp-bpf on Android was meant to prevent this,
> but did not?) or just a misunderstanding or something else. I wonder
> if a vulnerability in io_uring could be such that it's exploitable
> without io_uring access directly from the attacking app.
>
> > = Transparency =
> >
> > Currently, we make vulnerability details public on our spreadsheet[8]
> > (which now also includes CVE details), and we have summarized
> > different exploitation techniques in our cookbook[5]. 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[13], including the code they used.
>
> For archival and relevant discussions on linux-distros list policy, let
> me quote what [13] currently says:
>
> Quote start:
> > Note about making the exploit public
> >
> > You can publish your exploit at any time you would like to, but we
> > recommend publishing the exploit 30 days after the vulnerability was
> > disclosed. This gives the industry time to apply patches. Read our
> > stance on the topic in Google's disclosure policy.
> >
> > We only process submissions after the exploit is public (and we can only
> > issue rewards when the submission was processed), but not sooner than 30
> > days after the vulnerability disclosure.
> >
> > If you publish sooner than 30 days, you won't get the reward faster. If
> > you want to delay the publication (disclose later than 30 days), you
> > could do that, but you would get the money later (we want to encourage
> > you to publish the exploit details sooner than later).
> >
> > The above is about the exploit itself, not the vulnerability. We
> > automatically share some limited vulnerability details of the
> > submissions on our public submission spreadsheet, as a CVE, and as soon
> > as you submit the vulnerability details via the form.
> Quote end.
>
> In the above, do you mean 30 days after _public_ disclosure (or e.g.
> disclosure to Google, to upstream, or something else)? I suggest you
> clarify this.
>
> > = 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[14]. 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.
>
> Are there separate bug bounty programs for ChromeOS and Android, which
> would also cover relevant Linux kernel issues? If so, a Linux kernel
> bug can potentially be eligible for up to 4 Google bug bounty programs,
> right? Are the program terms compatible?
>
> > = 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[15], with a separate #kernelctf-announcements
> > channel[16]. Please join us there for the latest updates regarding
> > kernelCTF.
> >
> > [1] https://security.googleblog.com/2020/05/expanding-our-work-with-open-source.html
> > [2] https://security.googleblog.com/2021/11/trick-treat-paying-leets-and-sweets-for.html
> > [3] https://security.googleblog.com/2022/02/roses-are-red-violets-are-blue-giving.html
> > [4] https://security.googleblog.com/2022/08/making-linux-kernel-exploit-cooking.html
> > [5] https://docs.google.com/document/d/1a9uUAISBzw3ur1aLQqKc5JOQLaJYiOP5pe_B4xCT1KA/edit
> > [6] https://security.googleblog.com/2022/08/making-linux-kernel-exploit-cooking.html#:~:text=The%20mitigations%20we%27ve%20built%20attempt%20to%20tackle%20the%20following%20exploit%20primitives
> > [7] https://github.com/thejh/linux/blob/slub-virtual/MITIGATION_README
> > [8] https://docs.google.com/spreadsheets/d/e/2PACX-1vS1REdTA29OJftst8xN5B5x8iIUcxuK6bXdzF8G1UXCmRtoNsoQ9MbebdRdFnj6qZ0Yd7LwQfvYC2oF/pubhtml
> > [9] https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4228112
> > [10] https://cs.android.com/android/platform/superproject/+/master:bionic/libc/SECCOMP_ALLOWLIST_COMMON.TXT
> > [11] https://android-review.googlesource.com/c/platform/system/sepolicy/+/2302679
> > [12] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=788d0824269bef539fe31a785b1517882eafed93
> > [13] https://google.github.io/security-research/kernelctf/rules#note-about-making-the-exploit-public
> > [14] https://google.github.io/security-research/kernelctf/rules
> > [15] https://discord.gg/A3qZcyaZ69
> > [16] https://discord.gg/AjGJ3acF2e
> > =======================
> >
> > The article can also be read on our blog:
> > https://security.googleblog.com/2023/06/learnings-from-kctf-vrps-42-linux.html
>
> Thank you for your efforts, and for the transparency.
>
> Alexander
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
