Skip to content

Commit 8163dde

Browse files
committed
Update vrp.md: add kernelCTF-related changes, remove kernel-specific details
1 parent 818e3b6 commit 8163dde

File tree

1 file changed

+8
-46
lines changed

1 file changed

+8
-46
lines changed

docs/vrp.md

Lines changed: 8 additions & 46 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,8 @@
11
# kCTF VRP Setup
22

3-
We invite you to demonstrate an exploit against our kCTF demo cluster based on the challenges presented on this page. Successful demonstrations are eligible for rewards between [20,000 - 91,337 USD](https://security.googleblog.com/2022/02/roses-are-red-violets-are-blue-giving.html) as defined in [https://g.co/vrp](https://g.co/vrp). On top of this, exploiting our [new instances](#experimental-mitigations-challenge) are eligible up to 42,000 USD, increasing the total possible payout to [133,337 USD](https://security.googleblog.com/2022/08/making-linux-kernel-exploit-cooking.html).
3+
We invite you to demonstrate an exploit against our kCTF demo cluster based on the challenges presented on this page. Successful demonstrations which don't use Linux kernel vulnerabilities are eligible for rewards as described in our [kCTF VRP announcement blog post](https://security.googleblog.com/2020/05/expanding-our-work-with-open-source.html).
4+
5+
**Important note:** If you'd like to demonstrate an exploit against a Linux kernel vulnerability, please submit it to [our kernelCTF program](https://google.github.io/security-research/kernelctf/rules.html). **kCTF VRP does not accept Linux kernel vulnerabilities anymore** since 2023-06-14. For more information read our blog post "[Learnings from kCTF VRP's 42 Linux kernel exploits submissions](https://security.googleblog.com/2023/06/learnings-from-kctf-vrps-42-linux.html)".
46

57
[kCTF](https://github.com/google/kctf) is an open source infrastructure for CTF competitions. You can find details on how it works in the [kCTF documentation](https://google.github.io/kctf/introduction.html), but in short, it’s running on a hardened Kubernetes cluster with the following security features:
68

@@ -26,19 +28,19 @@ You can find the code for the challenges
2628

2729
The “kctf” challenge is the only entry point to the cluster. You can connect to it via:
2830

29-
**Older cluster (running Linux 5.10 currently):**
31+
**Older cluster (GKE Regular release channel):**
3032
```
3133
socat FILE:`tty`,raw,echo=0 TCP:kctf.vrp.ctfcompetition.com:1337
3234
```
3335

34-
**Newer cluster (running Linux 5.15 currently):**
36+
**Newer cluster (GKE Rapid release channel):**
3537
```
3638
socat FILE:`tty`,raw,echo=0 TCP:kctf.vrp2.ctfcompetition.com:1337
3739
```
3840

3941
It will ask you to solve a proof-of-work and then gives you access to a bash running in a setup similar to the [kCTF pwn template challenge](https://github.com/google/kctf/tree/beta/dist/challenge-templates/pwn). The only difference is that the flag is not accessible inside of the nsjail sandbox and you will need to break out of the chroot in order to read it. You can observe the full source code [here](https://github.com/google/google-ctf/tree/master/vrp).
4042

41-
The details of the kernel of the VM can be read from `/etc/node-os-release`, and you can get the image of the VM following [this script](https://gist.github.com/sirdarckcat/568934df2b33a125b0b0f42a5366df8c) based on the output of `/etc/node-os-release`.
43+
The details of the environment of the VM can be read from `/etc/node-os-release`, and you can get the image of the VM following [this script](https://gist.github.com/sirdarckcat/568934df2b33a125b0b0f42a5366df8c) based on the output of `/etc/node-os-release`.
4244

4345

4446
## full-chain challenge
@@ -58,62 +60,22 @@ KCTF{$CHAL_NAME-$TIMESTAMP:$MAC}
5860

5961
As you can see, the flags include a timestamp and are rotated frequently.
6062

61-
## Experimental mitigations challenge
62-
63-
We’re [launching new instances](https://security.googleblog.com/2022/08/making-linux-kernel-exploit-cooking.html) to evaluate the latest Linux kernel stable image as well as new experimental mitigations in a custom kernel we've built. Rather than simply learning about the current state of the stable kernels, the new instances are used to ask the community to help us evaluate the value of both our latest and more experimental security mitigations.
64-
65-
The [mitigations](https://github.com/thejh/linux/blob/slub-virtual/MITIGATION_README) we've built attempt to tackle the following exploit primitives:
66-
* Out-of-bounds write on slab
67-
* Cross-cache attacks
68-
* Elastic objects
69-
* Freelist corruption
70-
71-
You can connect to the instance with the latest kernel without the patch via
72-
73-
```
74-
nc kctf-mitigation.vrp.ctfcompetition.com 1337
75-
```
76-
77-
And to the version patched with our experimental mitigations:
78-
79-
```
80-
nc kctf-mitigation.vrp.ctfcompetition.com 31337
81-
```
82-
83-
(Previous kernel version 5.19 with the mitigation is available at `nc kctf-mitigation.vrp.ctfcompetition.com 31338`, but please do not use that for new research.)
84-
85-
These instances are not based on the kCTF infrastructure (as they require running custom kernel version), instead they spin up a new QEMU VM on every new connection. As this is not a production-ready infrastructure, breaking the infrastructure itself (or e.g. using leaks from console) is not considered a valid submission.
86-
87-
| | Upstream | Custom mitigation |
88-
| -------------- | -------- | ----------------- |
89-
| Kernel version | 6.1.25 | 6.1.25 - custom |
90-
| Kernel image | [bzImage_upstream_6.1.25](https://storage.googleapis.com/kctf-vrp-public-files/bzImage_upstream_6.1.25) | [bzImage_mitigation_6.1.25](https://storage.googleapis.com/kctf-vrp-public-files/bzImage_mitigation_6.1.25) |
91-
| Kernel config | [bzImage_upstream_6.1.25_config](https://storage.googleapis.com/kctf-vrp-public-files/bzImage_upstream_6.1.25_config) | [bzImage_mitigation_6.1.25_config](https://storage.googleapis.com/kctf-vrp-public-files/bzImage_mitigation_6.1.25_config) |
92-
| Source code | [f17b0ab](https://github.com/thejh/linux/commit/f17b0ab65d17988d5e6d6fe22f708ef3721080bf) | [a87ad16](https://github.com/thejh/linux/commit/a87ad16046f6f7fd61080ebfb93753366466b761) |
93-
| Port | 1337 | 31337 |
94-
| Reward (base) | $21000 | $42000 |
95-
96-
Please also note that although we are trying to keep up-to-date with the latest kernel version, these instances may sometimes be outdated.
97-
9863
### Submission
9964

10065
We want to avoid learning about unfixed vulnerabilities, so the process to submit reports is:
10166
1. Test your exploit - we recommend you to test it locally first, and run a GKE cluster to debug.
102-
2. If it is a 0day (there's no patch for it on [linus master branch](https://github.com/torvalds/linux/tree/master) yet), then send us a checksum of your working exploit to our form [here](https://docs.google.com/forms/d/e/1FAIpQLSeQf6aWmIIjtG4sbEKfgOBK0KL3zzeHCrsgA1EcPr-xsFAk7w/viewform). You won't share any technical details about the vulnerability, you will just record the fact you found something (as we only reward the first person that writes an exploit for a given bug, we use it to resolve the timing in case of an exploit collision). Make sure to submit the exploit checksum **before** there's a public patch and to submit the full exploit **within a week** after the patch is public. If you take longer than a week, we might issue the reward to someone else.
67+
2. If it is a 0day (there's no patch for it yet), then send us a checksum of your working exploit to our form [here](https://docs.google.com/forms/d/e/1FAIpQLSeQf6aWmIIjtG4sbEKfgOBK0KL3zzeHCrsgA1EcPr-xsFAk7w/viewform). You won't share any technical details about the vulnerability, you will just record the fact you found something (as we only reward the first person that writes an exploit for a given bug, we use it to resolve the timing in case of an exploit collision). Make sure to submit the exploit checksum **before** there's a public patch and to submit the full exploit **within a week** after the patch is public. If you take longer than a week, we might issue the reward to someone else.
10368
3. For 1days or once there is a public patch, test your exploit it on the [lab environment](#kctf-challenge). If you have troubles let us know in [#kctf](https://discord.gg/V8UqnZ6JBG) and we'll help you figure out any problems.
10469
4. Once you get the flag, send it together with the patch and the exploit [here](https://docs.google.com/forms/d/e/1FAIpQLSeQf6aWmIIjtG4sbEKfgOBK0KL3zzeHCrsgA1EcPr-xsFAk7w/viewform).
10570
5. To increase the timely sharing of new techniques with the community, we are also now requiring that the exploits that receive innovation bonus get publicly documented within a month, otherwise we may publish it.
10671

10772
### Notes
10873

109-
We want to encourage the community to help research vulnerabilities such as those [found by Syzkaller](https://syzkaller.appspot.com/upstream#open), but which are still unfixed since they have not been shown to be exploitable. As such:
110-
111-
74+
We want to encourage the community to help research vulnerabilities, but which are still unfixed since they have not been shown to be exploitable. As such:
11275

11376
* The person that develops the exploit and receives the reward might not be the same as the person that discovered or patched the vulnerability.
11477
* It's ok to use 1-day exploits against the lab environment using publicly known vulnerabilities that exploit the patch gap between the time when a patch is announced and the lab environment is updated, however we will only issue a single reward per vulnerability.
11578

116-
11779
**When we receive an exploit for a fixed vulnerability we'll add details [here](https://docs.google.com/spreadsheets/d/e/2PACX-1vS1REdTA29OJftst8xN5B5x8iIUcxuK6bXdzF8G1UXCmRtoNsoQ9MbebdRdFnj6qZ0Yd7LwQfvYC2oF/pubhtml).**
11880

11981
In case of questions or suggestions, you can reach us in [#kctf](https://discord.gg/V8UqnZ6JBG).

0 commit comments

Comments
 (0)