Add kernelCTF CVE-2023-4147_lts_cos #112
Conversation
pocs/linux/kernelctf/CVE-2023-4147_lts_cos/docs/vulnerability.md
Outdated
Show resolved
Hide resolved
pocs/linux/kernelctf/CVE-2023-4147_lts_cos/exploit/cos-105-17412.101.42/exploit.c
Show resolved
Hide resolved
koczkatamas
force-pushed
the
master
branch
2 times, most recently
from
b2e2b9f
to
43a5a81
Compare
|
Hello, @artmetla. I updated the write-up based on your review. Please check it. Thanks. |
pocs/linux/kernelctf/CVE-2023-4147_lts_cos/exploit/cos-105-17412.101.42/exploit.c
Show resolved
Hide resolved
| struct nftnl_rule * rule_replace_3 = nftnl_rule_alloc(); | ||
|
|
||
| nftnl_rule_set_str(rule_replace_3, NFTNL_RULE_TABLE, table1_name); | ||
| nftnl_rule_set_u32(rule_replace_3, NFTNL_RULE_CHAIN_ID, 1337); |
There was a problem hiding this comment.
We're doing rule replace in this exploit by ID, as this chain is already bound by rule_bind_chain_1_2. Following our conversation in PR#111. Could we change the logic of exploit, to firstly create rule_bind_chain_2_3 then call replacement with rule_dangling_3 and then trigger deletion of rule_bind_chain_1_2? If so, we would not need to add the rule_dangling_3 to the chain by ID?
There was a problem hiding this comment.
We can create rule_bind_chain_1_2 later to bound the chain2 late, so we can replace rule_bind_chain_2_3 without using the chain ID. I think this is a missed point in CVE-2023-4147 and CVE-2023-5197 handles it by preventing replacing on chains with the bound flag present.
No description provided.