kernelCTF: add CVE-2023-0461_mitigation

[0xdevil]

No description provided.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[koczkatamas]

Hey!

Sorry for the late response. We created a Github Actions job to verify the submission PRs.

You can view the result of the check here: https://github.com/google/security-research/actions/runs/5962545386

It failed with two issues:

1. It could not build the exploit because libkeyutils-dev is missing from the system. You can resolve this by adding a prerequisites target into your Makefile:

prerequisites:
	sudo apt-get install libkeyutils-dev

2. The exploit reproduction is also failed. Most of the cases, the exploit crashed (segfault). The reproduction system is a bit different than the live one (it runs the exploit directly from /init and there is no nsjail).

   Could you please take a look why does it fail and if possible then fix it or give feedback how should we modify our reproduction procedure.

Feel free to modify the PR and the Github Action will run again and you will see the new verification results.

Thank you for your submission and participating in kernelCTF!

[koczkatamas]

Added JSON schema changes as suggestions and a Makefile change which will fix the build process.

[0xdevil]

Hey!

Looking at logs, nine times out of ten the rop-chain worked, but the exploit segfaulted after returning to user space.

segfault at df2cff8 ip 00000000004021ca sp 000000000df2d000 error 6 in exploit[401000+9d000] likely on CPU 0 (core 0, socket 0)

It turned out that it was crashing at the beginning of the getroot() function (0x4021ca) trying to push rbp on the mmapped stack (0xdf2d000).

gef➤  x/100i 0x4021ca
   0x4021ca:    push   rbp # <--
   0x4021cb:    mov    rbp,rsp
   0x4021ce:    sub    rsp,0x20
   0x4021d2:    lea    rax,[rip+0x9bf33]        # 0x49e10c
   0x4021d9:    mov    QWORD PTR [rbp-0x20],rax
   0x4021dd:    lea    rax,[rip+0x9bf32]        # 0x49e116
   ...

Initializing the stack memory before hijacking control flow solved the problem (tested locally using the rootfs_repro_v1.img.gz image).
This is weird because it never happened on the remote instance or in my local environment.

I updated the exploit source code, please let me know if I need to update the exploit binary as well.