Add kernelCTF CVE-2023-31436

[liona24]

No description provided.

[koczkatamas]

We switched JSON schema version, please accept these changes to make the PR check succeed.

[koczkatamas]

Hey!

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

The current test run mostly failed because we switched the metadata.json schema version, I made code change suggestion above how to fix these issues. You can see the current test run results here: https://github.com/google/security-research/actions/runs/5964149526

After you fix these issues the Github Action will run again, and it will test the exploit compilation and exploit reproduction too.

The compilation failed for us with undefined reference to 'flush_cache'.

The exploit reproduction (10 tries) will also probably fail based on our internal tests, but maybe this happens because of the mentioned 5% success rate. In this case we will re-run the tests, as long as it repros at least once, you are good to go.

If the reproduction fails for some other reason, then please take a look why it fails. The reproduction system is a bit different than the live one (it runs the exploit directly from /init and there is no nsjail). You can also give feedback how we should modify our reproduction procedure.

So 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!

[liona24]

Hey. Thanks for the update. My Makefile was using a slightly different target, so I fixed that. The exploit is using side channels for KASLR bypass. This does not appear to be working on the runner, does however work on the real instances. (tbh I haven't checked in a while, where there any infra changes?). Any suggestions on how to proceed here? I can have a closer look in a week or so.

[liona24]

So I checked again, the cache timing side channel works fine on the real instance. Both use QEMUs -cpu host, not sure what is underneath here.

Would KASLR disabled be an option for the CI job? As far as the CTF is concerned KASLR bruteforce is a valid strategy anyway, so you probably do not want such submissions to spam your runner too.

Also the CLA check is failing because apparently you (@koczkatamas) are not approved as a contributor and we shared some commits.

(sorry for closing the PR, the buttons are pretty close ..)

[koczkatamas]

Hey! Yeah, we will provide an option to disable KASLR. When it's ready (ETA: next week), I will comment here.

…

On Fri, Sep 1, 2023, 15:38 liona24 ***@***.***> wrote: Reopened #34 <#34>. — Reply to this email directly, view it on GitHub <#34 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAT4XUTUVAZVKQ5EL4DERJDXYHQN5ANCNFSM6AAAAAA2VGHKII> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[koczkatamas]

Implemented, KASLR base will be supplied as the first argument to ./exploit. Example full command line: su user -c '/tmp/exp/exploit ffffffff8a000000'.

You need to change to the v3 metadata schema and modify the exploits node to this:

    "exploits": {
        "mitigation-6.1": {
            "uses": ["userns"],
            "stability_notes": "5% success rate",
            "requires_separate_kaslr_leak": true
        }
    }

See the full modified file here: https://github.com/koczkatamas2/security-research/pull/1/files#diff-a3e5b8f8744c0ae7ff2ed99f0c28cb0a940bf5b6964a86eeecc0fa42d19bdd6d

[liona24]

Alright thank you very much. The only thing missing now is the CLA check because of the co-authored commits.