Live data from Hacker News

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

jprx.io

41–47 of 47 posts

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

#41
post #30

Earlier quoted context omitted.

Usually promotions are to signed int, not unsigned. (With some exceptions. But every uint16_t value can fit in int.)

Unless int is 16-bit. Code like this is potentially UB; you should use int32_t as the target.

You should use long, and don't ever assume it's exactly 32-bits. The fixed size types are often an overused crutch that hampers future portability.

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

#43
post #11

Earlier quoted context omitted.

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.

The bottom 2 bytes of a pointer contain two bits of the slide, assuming it's even a pointer into the kernelcache itself. I'd take half a sandwich.

Little endianness considered harmful

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

#44
This is a nice and easy to understand example of a memory-safety bug that CHERI [1] prevents (among other classes of vulnerabilities). Given that the SYSCTL_PROC() macro installs a pointer to an uint16_t value in the oid_arg1 field, a CHERI pure-capability kernel would construct a capability with bounds set to sizeof(uint16_t) and later the dereference of (int *)oidp->oid_arg1 in sysctl_udp_log_port() would trigger a capability bounds violation.

`sysctl -a` would simply crash on CHERI allowing a developer to catch this without KASAN being involved.

[1] http://cheri-cpu.org

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

#45
post #30

Earlier quoted context omitted.

Usually promotions are to signed int, not unsigned. (With some exceptions. But every uint16_t value can fit in int.)

Unless int is 16-bit. Code like this is potentially UB; you should use int32_t as the target.

There are no mainstream 16-bit int platforms. It's fine to know what you target.

The promotions that are really surprising are from uint64_t bitfields to int (because it's based on value representability).

  struct {
    uint64_t a : 33,
             b : 15;
  } s;
  // s.b gets "promoted" to int, s.a does not

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

#46

This is a nice and easy to understand example of a memory-safety bug that CHERI [1] prevents (among other classes of vulnerabilities). Given that the SYSCTL_PROC() macro installs a pointer to an uint16_t value in the oid_arg1 field, a CHERI pure-capability kernel would construct a capability with bounds set to sizeof(uint16_t) and later the dereference of (int *)oidp->oid_arg1 in sysctl_udp_log_port() would trigger a…

Not only, SPARC ADI and ARM MTE as well.

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

#47
post #11

Earlier quoted context omitted.

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.

The bottom 2 bytes of a pointer contain two bits of the slide, assuming it's even a pointer into the kernelcache itself. I'd take half a sandwich.

Yeah, you could probably contrive a situation where you get more interesting information (page numbers maybe?), but it definitely doesn't seem likely to me-
Post reply on HN