security-research

kernelCTF rules

kernelCTF is a part of the Google VRP and is focused on making exploiting Linux kernel vulnerabilities harder by inviting security researchers to demonstrate their exploitation techniques on 0-day and 1-day vulnerabilities in various kernel versions. This includes the kernel version with our experimental mitigations; we’d like to see if and how researchers can bypass these mitigations.

We are asking researchers to publish their submissions, helping the community to learn from each other’s techniques.

Reward structure and targets

Targets

A submission can contain any number of the following 4 parts:

1. Exploit for the latest LTS instance

This instance uses the latest LTS (currently 6.1, soon 6.6) with COS kernel config, but with io_uring and nftables (for 6.6) disabled. Only the first submission is eligible per LTS kernel version, but we are upgrading the kernel version every 2-4 weeks on average.

Rewards

• Base reward: $21.337

• Stability bonus (+$10.000)

  • Criteria: 90% of runs successfully steal the flag.

  • More precisely, the exploit_repro Github Action reports Reliability: 90% or better in the Reproduction summary (after a sane amount of re-runs if needed)

  • If the exploit requires us to provide a KASLR base address, then it is ineligible for the bonus (requires_separate_kaslr_leak is true in metadata.json file).

  • Valid submissions with Flag submission time older than 2023-09-08T00:00:00Z on the public spreadsheet automatically get the bonus.

• Reduced attack surface bonus (+$20.000)

  • Criteria: Exploit works without using unprivileged user namespaces.

  • Note: We may change the bonus definition from time to time (for example adding additional restrictions), but we will announce any changes at least 1 month in advance (see the “Program change notifications and communication” section).

• 0-day bonus (+$20.000)

  • Criteria: You are exploiting a non-patched, non-disclosed vulnerability (see a more detailed definition in the section “0-day submissions” below).

2. Mitigation bypass (on the mitigation instance)

The mitigation instance is upgraded far less frequently than the LTS instance (currently staying on 6.1.55), thus more 1-day vulnerabilities can be exploited. This way you have more opportunity to present your mitigation bypass techniques.

Only exploits which clearly bypass our mitigations are eligible (e.g. if a mitigation protects against UAF, but not against BoF, then an exploit using a BoF vulnerability is not eligible).

As the current instance (mitigation-v3-6.1.55) uses the CONFIG_RANDOM_KMALLOC_CACHES probabilistic memory allocator hardening, only exploits with at least 70% reliability are eligible (checked the same way as the LTS stability bonus).

See the source code and the extra kernel hardenings turned on.

Reward

• $21.000

3. Exploits for COS instances

These instances follow the live COS kernel config (which is also used in GKE), with the necessary modifications to make it work in our infrastructure. io_uring and nftables are enabled here.

Only the first submission is eligible per COS version unless it is part of a valid 0-day LTS submission. New COS versions are released every few weeks on average.

Reward

• $21.000 if the exploit does not use user namespaces and io_uring

• $10.500 if the exploit uses user namespaces or io_uring

  • This reward is based on whether the exploit works on GKE AutoPilot or not. AutoPilot currently does not enable unprivileged user namespaces and they are also considering disabling io_uring.

• Currently, there are two instances (COS 97 and COS 105) available, with kernel versions 5.10 and 5.15 respectively (soon we will switch to COS 105 and COS 109 - 5.15 & 6.1). The reward is the same regardless of which instance was exploited (the reward is not doubled if both were exploited).

• We may change the number of instances or their kernel versions, but will announce this at least 1 month in advance (via #kernelctf-announcements).

• Note: Other bonuses (e.g. 0-day and reduced attack surface bonuses) do not apply here.

4. Novel techniques

We reward submissions demonstrating novel exploitation techniques (at our discretion), and including a description of the technique that shows why it is novel.

Novel techniques can be submitted at any time exploiting any available environment, even if the vulnerability was already exploited in that environment.

Reward

• From $0 to $20.000 per technique, at our discretion.

Target instances

You can connect to the targets with socat - ssl:kernelctf.vrp.ctfcompetition.com:1337,cafile=server_cert.pem

server_cert.pem:

-----BEGIN CERTIFICATE-----
MIIBazCCAR2gAwIBAgIUSXiRksvnzRI2WYqh7nDZVoZydOIwBQYDK2VwMCsxKTAn
BgNVBAMMIGtlcm5lbGN0Zi52cnAuY3RmY29tcGV0aXRpb24uY29tMB4XDTIzMDYw
ODIyNDA0MFoXDTMzMDYwNTIyNDA0MFowKzEpMCcGA1UEAwwga2VybmVsY3RmLnZy
cC5jdGZjb21wZXRpdGlvbi5jb20wKjAFBgMrZXADIQCTg2ayrs3BsxUocgbd1eWj
WWVzQQmORR5LT3unlZCzFaNTMFEwHQYDVR0OBBYEFCSsjYgVH8funXWPApo32zpS
NhPgMB8GA1UdIwQYMBaAFCSsjYgVH8funXWPApo32zpSNhPgMA8GA1UdEwEB/wQF
MAMBAf8wBQYDK2VwA0EAxJ+NlnvVYZKj/ctSIzcuPm7+4SlziIHDRW43SrLks15v
KQVTtek3sAifw5NuaXWZrGrX7JAqNqci3QPCMHFEDA==
-----END CERTIFICATE-----

Additional eligibility rules

Only the first submission for a vulnerability is eligible for a reward (per target). The COS instances are considered to be one target so there are 3 targets in total (LTS, mitigation, COS).

This means: if a vulnerability is exploited on the latest LTS by Researcher A (but not on the other targets), then it can still be exploited on the mitigation instance and COS instances (e.g. by Researcher B or later by Researcher A), but can no longer be exploited on the latest LTS (even if the LTS kernel version is updated).

If a patch commit fixes multiple vulnerabilities (e.g. by backporting a new version of a component to the stable tree), we assume the root cause is the same and we consider further submissions (for the same target) as duplicates.

If the same vulnerability is fixed in multiple patch commits (e.g. in commit A in the mainline tree and separately in commit B in the stable tree), then we still consider it as the same vulnerability, thus making further submissions (for the same target) duplicates.

The “novel techniques” category is an exception from these rules, as in that category we are rewarding the technique, so you can target already exploited vulnerabilities.

If you are unsure about eligibility, contact us on the #kernelctf Discord channel before making the submission.

Vulnerabilities used in kCTF VRP

This should not be relevant anymore, but click here to expand.

1. If a vulnerability was exploited against any target in kCTF VRP then it's not eligible against kernelCTF's LTS target. * Check on the "kCTF VRP" tab of the [public spreadsheet](https://docs.google.com/spreadsheets/d/e/2PACX-1vS1REdTA29OJftst8xN5B5x8iIUcxuK6bXdzF8G1UXCmRtoNsoQ9MbebdRdFnj6qZ0Yd7LwQfvYC2oF/pubhtml) that none of the "Link to the patch" fields point to the vulnerability. 2. If a vulnerability was exploited against any GKE target in kCTF VRP then it's not eligible against kernelCTF's COS targets. * If a vulnerability was exploited against a GKE target then the "kCTF VRP" tab of the [public spreadsheet](https://docs.google.com/spreadsheets/d/e/2PACX-1vS1REdTA29OJftst8xN5B5x8iIUcxuK6bXdzF8G1UXCmRtoNsoQ9MbebdRdFnj6qZ0Yd7LwQfvYC2oF/pubhtml) contains a flag with the `kctf-` or `full-chain-` prefix. 3. If a vulnerability was exploited against kCTF VRP's mitigation target then it's not eligible against kernelCTF's mitigation target. * If a vulnerability was exploited against a mitigation target then the "kCTF VRP" tab of the [public spreadsheet](https://docs.google.com/spreadsheets/d/e/2PACX-1vS1REdTA29OJftst8xN5B5x8iIUcxuK6bXdzF8G1UXCmRtoNsoQ9MbebdRdFnj6qZ0Yd7LwQfvYC2oF/pubhtml) contains a flag which contains the `mitigation` substring.

Submission process

Note: Minor details of the submission process may change from time to time, please make sure you check this page again for updates when you make a new submission.

Submissions can target 0-day and 1-day bugs.

Non-patched and 0-day submissions

We consider a bug 0-day if at the time of the submission:

• There is no patch commit in the mainline tree, and

• The vulnerability is not disclosed in any form (e.g. there is no Syzkaller report about the bug)

  • Note: We may still consider a bug 0-day at our discretion (e.g. although the bug was disclosed by Syzkaller more than 30 days ago, there is no fix and you convince the maintainers to fix the bug)

If the submission targets a bug which is not patched yet (0-day or 1-day without a patch), then the submission process has one additional initial stage.

The purpose of this additional stage is to make sure the vulnerability details are not shared with us before the patch is released but to still provide a 7-days long “protection window” for 0-day vulnerability founders in case some else makes a 1-day submission for the same vulnerability before the 0-day founder.

In this stage:

1. Exploit the bug and capture the flag from the target environment (the flag is a proof of successful exploitation).

   • The environments are not shared but running in separate VMs, so you don’t have to worry about others stealing your 0-day.

2. Compress the exploit and its source code as a .tar.gz file and calculate its SHA256 checksum.

   • Save this exact file, you will need to send us this later.

   • Try to keep this file to the minimum necessary, leave out large files like e.g. vmlinux, bzImage as they can be downloaded separately if needed.

3. Submit the flag and the hash via this form with the additional details requested.

   • Save the link as you’ll have to edit this form later.

4. Report the vulnerability to [email protected] within 7 days of the first form submission.

   • Note: A submission will be considered ineligible if it turns out that this requirement was not respected.

5. Make sure that you are credited in the Reported-By tag of the patch that fixes the bug.

   • Use the same email address in the Reported-By tag as you use for the form submission or in the “Email address used in Reported-By tag” field of the form.

   • If there is no Reported-By tag on a patch commit, then a 0-day submission is eligible only if this is the first 0-day submission for that patch commit (based on the first stage submission date).

   • If it is unclear who reported the bug, then the 0-day bonus can be split (multiple reporters), reduced, invalidated or the 0-day submission protection can be lost at our discretion.

6. Wait for the patch to land in a release candidate on the mainline tree (and tagged in Git), or committed on a stable tree.

7. Modify the form within 7 days by following the previously saved link and fill out the extra details as described below in the 1-day section.

   • If the 7-day deadline is missed, then the first stage 0-day protection expires and other 1-day submissions can take priority over this submission (which makes this submission a duplicate and thus ineligible for reward).

A submission will not be eligible as a 0-day submission if the vulnerability details were reported somewhere (e.g. Pwn2Own) other than [email protected].

Already patched, 1-day submissions

1. Exploit the bug and capture the flag from the target environment (the flag is a proof of successful exploitation).

2. Submit the requested vulnerability details via this form (without including additional details on the exploitation technique for now).

3. Send us the description of the vulnerability via bughunters.google.com (please follow the process described below).

4. Wait for us to publish the CVE or publish the vulnerability details yourself on oss-sec.

   • If you’d like to speed up the CVE publication process, please make sure you fill out all the details needed for the CVE when you fill out the form. This way the disclosure happens earlier and your submission will be processed faster.

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 the security-research repo (see required structure below).

6. Make sure that the PR is merged (this is a requirement to get a reward).

Google Bughunter’s website submission process

1. Go to https://bughunters.google.com/report/vrp

2. Sign in (this helps us identify you and send you a reward)

3. Put a summary of the vulnerability in the report description field – please mention “kernelCTF”, the submission ID (“expNN”) listed on the public spreadsheet, the affected targets, the affected subsystem, the cause and type of vulnerability (e.g. kernelCTF exp45: Refcount issue leading to UAF in io_uring affecting COS 5.15 and Linux 6.1)

4. Enter Linux Kernel into the affected product / website field, select the My product is not listed in the product list checkbox.

5. Enter kernel.org into the URL field.

6. Describe the vulnerability in detail (see the Documentation requirements section):

   • Do not include the exploitation details here.

   • Put “kernelCTF” and the submission ID here again (e.g. “kernelCTF exp45”).

   • Make sure that the patch commit, CVE (optionally, if it is already known) and the exact target(s) (e.g. cos-93-16623.402.40) are included.

   • You can reuse the contents of your vulnerability.md if it already exists (see the “Exploit PR file structure” section).

   • You can just enter “unprivileged user can get root” into the attack scenario (bottom) field.

   • If you’d like to attach images or a PoC (triggering the vulnerability without actually exploiting it), you can attach them as a tar.gz file here.

7. Select Privilege Escalation as the Vulnerability Type

8. Select Yes, this vulnerability is public or known to third parties (as the patch is already out).

9. You can optionally donate twice the reward to charity if you select “Donate to charity and double my reward.”

10. Submit your report.

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.

Exploit PR file structure

The submission should be put into the pocs/linux/kernelctf/<cve>_<targets>/ folder within the security-research repo, where:

• cve is the CVE number of the vulnerability in the format CVE-yyyy-NNNNN

• <targets> is the list of targets separated by underscore (_)

  • Valid target names: lts, mitigation, cos

• If there is a conflicting submission (e.g. you are only submitting a novel technique), then append _2 (or _3, etc.) after the directory name.

For example: pocs/linux/kernelctf/CVE-2023-1872_lts_cos/.

The structure of this submission folder should be:

• original.tar.gz

  • Required, contains the original exploit. Its hash must match the one submitted initially via the form (this hash cannot be modified later).

• metadata.json

  • Required, structured metadata information following this JSON schema (version 3).

• docs/vulnerability.md

  • Required, description of the vulnerability.

• docs/exploit.md

  • Required, description of how the exploits work. If exploits are too different, then it can also be put next to exploits.

• docs/novel-techniques.md

  • Only required if submission contains novel technique(s). Contains the description of the techniques.

• exploit/mitigation-6.1/
exploit/lts-6.1.x/
exploit/cos-(93|97|101|105|...)-xxxxx.yyy.zz/

  • exploit.c
    • Required, source code of the exploit.
  • exploit
    • Required, compiled exploit which stole the flag.
  • Makefile
    • Required, includes target (exploit) to compile exploit.c into exploit and target (run) to run the exploit on the live instance (which steals the flag).

You can add additional files (e.g. images for writeup or supporting libraries for the exploit). The exploit can be split into multiple files, although we prefer if it is kept as a single .c file.

Documentation requirements

Vulnerability

If possible please include the following information in the vulnerability details:

• Requirements to trigger the vulnerability:
  • Capabilities
  • Kernel configuration
  • Are user namespaces needed?

• Commit which introduced the vulnerability

• Commit which fixed the vulnerability

• Affected kernel versions

• Affected component, subsystem

• Cause (UAF, BoF, race condition, double free, refcount overflow, etc)

• Which syscalls or syscall parameters are needed to be blocked to prevent triggering the vulnerability? (If there is any easy way to block it.)

Exploit

Make sure that the exploit is properly commented and the accompanying exploit.md includes all the details, making it easy to understand what the exploit does.

Give a step-by-step overview of the exploitation process. When describing the following activities, include them as a separate step:

• Triggering a vulnerability.

• Converting one attack primitive into another.

• Spraying or grooming the heap.

• Executing cross-cache attack.

• Leaking information (e.g. heap pointer, kASLR base address).

• Overwriting kernel memory.

• Getting RIP control.

• Executing interesting post-RIP approaches.

• Doing a major step towards a successful exploitation which is not listed above.

In the steps, include the affected objects (e.g. struct file), their role (e.g. vulnerable object, victim object), and their respective caches (e.g. kmalloc-1k) and the used field members of the object (e.g. getting RIP control via file->ops->ioctl, overwriting msg_msg->security).

We expect the following parts to be properly documented:

• Non-trivial constant values should be explained, for example:
  • Flag and enumeration values
  • Field offsets
  • Function addresses
  • ROP gadget offsets
• ROP chain items should be explained.
  • E.g. in rop[0] = base + 0x123456; explain that 0x123456 is resolved to e.g. call_usermodehelper_exec.
• Fake structures should be explained; i.e. which structure is created and what fields are set.
  • E.g. data[0x8] = base + 0x123456; -> data variable contains a fake struct file, the field at 0x8 offset is a f_inode pointer which is set to ...
• Usage of multi-threading (or forking)
  • Why is it needed?
  • If a race condition is exploited, then what code paths are raced.
  • Communication and synchronization between two the threads (e.g. what data was sent between the threads, and when the threads are waiting on each other).
• Environmental requirements
  • If specific climit or cpu affinity settings are required, then explain why they are needed.
  • Which limit the exploit runs into using the default settings.

• Namespaces usage and why are they required.

• Separation between code parts which are needed to trigger the vulnerability and parts which are part of the exploitation process (spraying, heap grooming, cross-cache, converting one primitive to another).

• Any action (e.g. syscall) where a side-effect of the action is used for the exploit and not the main functionality, for example:
  • Syscall used for spraying a specific structure, not for its main purpose.
  • Some calls (e.g. sleep) used for a specific side-effect which is not trivial see.

If possible, also include how stable your exploit is (e.g. it worked 90% of the time during your testing) and whether your exploit requires a separate kASLR leak (or bruteforce).

Additional information

Program change notifications and communication

We announce major program changes on Google’s Security Blog, but we may change minor, mostly technical details (like steps in the submission process) by changing this page and announcing the change on our #kernelctf-announcements Discord channel.

Questions about program

If you have any questions regarding kernelCTF, check the FAQ page and feel free to ask on the #kernelctf Discord channel.

Non-kernel vulnerabilities

If you are submitting a non-kernel vulnerability affecting our kCTF VRP cluster, please submit the vulnerability to our kCTF VRP.

This site is open source. Improve this page.