Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Susctl CVE-2024-54507: A particularly 'sus' sysctl in the XNU kernel

jprx.io

Post reply on HN
Print view View original

1–10 of 47 posts

Re: Susctl CVE-2024-54507: A particularly 'sus' sysctl in the XNU kernel

#4

Post by inetknght » 

    -   int new_value = *(int *)oidp->oid_arg1;
    +   int new_value = *(uint16_t *)oidp->oid_arg1;
Why not just have `uint16_t new_value = ...`?

Ahh, because `new_value` is being given to `sysctl_handle_int(..., &new_value, ...);` which of course expects an `int`. So then it begs the question: if the value is really a `uint16_t`, then why is it being handled through a plain `int`? It smells like there could easily be tons of other memory-safety and/or type confusion problems endemic to the sysctl API.

Re: Susctl CVE-2024-54507: A particularly 'sus' sysctl in the XNU kernel

#5

Post by ChocolateGod »

nxobject wrote: post #2

Did you get a bounty payout for this? I got the impression that Apple wasn't particularly on the ball with those.

Is it even exploitable in the real world?

Correct me if I'm wrong but you get 2 bytes of kernel data (potentially blank padding) and the same two bytes each time?

Re: Susctl CVE-2024-54507: A particularly 'sus' sysctl in the XNU kernel

#7

Post by bean-weevil »

ChocolateGod wrote: post #5
nxobject wrote: post #2

Did you get a bounty payout for this? I got the impression that Apple wasn't particularly on the ball with those.

Is it even exploitable in the real world? Correct me if I'm wrong but you get 2 bytes of kernel data (potentially blank padding) and the same two bytes each time?

If the linker puts a pointer there, this would let you leak part of the pointer which could let you bypass kaslr. Not too likely for that to occur. If I were submitting this bug I would feel complete if they bought me a sandwich.

Re: Susctl CVE-2024-54507: A particularly 'sus' sysctl in the XNU kernel

#8

Post by aritashion »

inetknght wrote: post #4

- int new_value = *(int *)oidp->oid_arg1; + int new_value = *(uint16_t *)oidp->oid_arg1; Why not just have `uint16_t new_value = ...`? Ahh, because `new_value` is being given to `sysctl_handle_int(..., &new_value, ...);` which of course expects an `int`. So then it begs the question: if the value is really a `uint16_t`, then why is it being handled through a plain `int`? It smells like there could easily be tons of o…

> So then it begs the question: if the value is really a `uint16_t`, then why is it being handled through a plain `int`?

I don't think it begs the question, but it does raise one!

Re: Susctl CVE-2024-54507: A particularly 'sus' sysctl in the XNU kernel

#10

Post by buzzergfxkjkl »

ChocolateGod wrote: post #5
nxobject wrote: post #2

Did you get a bounty payout for this? I got the impression that Apple wasn't particularly on the ball with those.

Is it even exploitable in the real world? Correct me if I'm wrong but you get 2 bytes of kernel data (potentially blank padding) and the same two bytes each time?

Good to find the bug regardless! I appreciated the succinct and not overly dramatic write-up. I don't think anything significant was claimed other than the fact that it is a kernel bug (which is significant in itself don't get me wrong).
Post reply on HN