Add kernelCTF CVE-2023-52447_cos #105
Conversation
| ## Use victim arraymap to modified near array_of_maps's value index 0 arraymap as (core_pattern-struct_bpf_array_offset). | ||
|
|
||
| Out of bound access from victim to modify next chunk's contents. | ||
| With heap feng shui, the next chunk can be array_of_maps and we ovewrite its index 0 arraymap. |
There was a problem hiding this comment.
Could you explicitly detail the heap spraying or grooming techniques used to ensure the array_of_maps is allocated adjacent to the victim array_map?
| BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_ringbuf_output) | ||
| ``` | ||
|
|
||
| Another thread can free the arraymap and reclaim as array_of_maps. |
There was a problem hiding this comment.
Could you elaborate on how a different thread free's the arraymap and the details on how to reclaim it as an array_of_maps? The exploit mentions using another thread to free the array_map while the BPF program is running, but it doesn't elaborate on:
- Why multi-threading or forking is necessary for this exploit
- How the threads are synchronized (e.g., barriers, signals, etc.)
- What data is shared between the threads
| ```C | ||
| for (int i = 0; i < 0x100; i++) { | ||
| spray_fd[i] = bpf_create_map(BPF_MAP_TYPE_ARRAY_OF_MAPS, 4, 4, | ||
| 0x30, samplemap); |
There was a problem hiding this comment.
Can you explain why the value 0x30 is chosen here?
| BPF_LD_MAP_FD(BPF_REG_9, target), | ||
| BPF_MAP_GET_ADDR(0, BPF_REG_9), | ||
| BPF_MAP_GET_ADDR(4, BPF_REG_8), | ||
| BPF_ST_MEM(BPF_W, BPF_REG_8, 4, 0x800), //modify map.max_entries |
There was a problem hiding this comment.
The new value written to map.max_entries is 0x800. Can you explain why this specific value is chosen, for example "we need this much room for the out-of-bounds because of X"?
| BPF_ST_MEM(BPF_W, BPF_REG_8, 4, 0x800), //modify map.max_entries | ||
|
|
||
| BPF_MAP_GET_ADDR(0x20, BPF_REG_8), | ||
| BPF_ST_MEM(BPF_W, BPF_REG_8, 4,0xffff), //modify array->index_mask |
There was a problem hiding this comment.
The new value written to array->index_mask is 0xffff. Can you explain why it's useful for enabling out-of-bounds access?
| @@ -0,0 +1,183 @@ | |||
| # Exploit Tech Overview | |||
|
|
|||
| The vulnerability is that bpf program can hold arraymap pointer without increase refcount if it's from array_of_maps. | |||
There was a problem hiding this comment.
Could you add the relevant code that's responsible for introducing the bug and explain why it allows you to get a reference to an arraymap without increasing it's refcount?
|
|
||
| The vulnerability is that bpf program can hold arraymap pointer without increase refcount if it's from array_of_maps. | ||
| If bpf first stores a arraymap pointer into one register, and do some time consume operation in the middle of program. | ||
| It gives other thread chance to free that arraymap can reclaim it to another structure like array_of_maps. |
There was a problem hiding this comment.
Can you add some notes on which caches these objects are in?
| BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_8,0), | ||
| ``` | ||
|
|
||
| We can leak arrymap address and array_map_ops by malformed arraymap. |
There was a problem hiding this comment.
Could you add a note that based on array_map_ops you can find the kASLR base address?
|
Hey! Thanks for take a look into my submission. |
|
Thanks @st424204 ! Those changes make it way more clear :) |
No description provided.