3 ms·

If the heap info leak fails, I bail out cleanly. If the kASLR leak fails, it is usually because instead of hitting a vm_map_copy (the intended structure I need

If the heap info leak fails, I bail out cleanly. If the kASLR leak fails, it is usually because instead of hitting a vm_map_copy (the intended structure I need to corrupt), something completely unrelated is hit instead. If it happens to hit something different than expected, that's undefined behaviour usually ending up in a panic.

bro-stick 11y ago
Mad props. If osx were s/xnu/minix 3-style, full microkernel/, sploiting Iokit as a least priv'd process, only it would get pwned and be limited to iokit's acls. Still bad, but it likely wouldnt have rights to exec a root shell. XNU kexts have way too much authority, and all the syscalls they each tack on compounds the attack surface to the total codebases of all Apple and third-party kexts. Because once you've found and symbolicated the not-really-hidden call table, you're pretty much able to do whatever. And with a mutating mem kext bug ...
- qwertyoruiop 11y ago
  while I agree with you on the security benefits of a full microkernel, to be entirely honest, if you had access to just IOKit you could easily use a network card or an hard drive controller to get a physical memory write-what-where, which in turn would allow you to gain access to anything, plus the microkernel performance issues of e.g. having to context switch on interrupts.
  - bro-stick 11y ago
    That things may be broken is no argument against defense-in-depth and least privilege. By having smaller codebases and smaller system components, the attack surface is far, far smaller than say Linux. IOKit is shit as is, and a full microkernel would break it up into processes based on areas of responsibility. Also, that shows the hardware needs better bus- and command-level security to prevent such attacks. (Don't even get me started on closed firmware blobs or unverifiability of commercial cores.) Expecting a finished product of a new project would be unreasonable. Minix 3 is early on and not the only full microkernel out there. They will probably find an approach to reduce context switches if it's a mature optimization to make. An Android-like mobile/embedded platform would make a sensible research -> real use-case, minus Java.

bro-stick 11y ago

Mad props. If osx were s/xnu/minix 3-style, full microkernel/, sploiting Iokit as a least priv'd process, only it would get pwned and be limited to iokit's acls. Still bad, but it likely wouldnt have rights to exec a root shell. XNU kexts have way too much authority, and all the syscalls they each tack on compounds the attack surface to the total codebases of all Apple and third-party kexts. Because once you've found and symbolicated the not-really-hidden call table, you're pretty much able to do whatever. And with a mutating mem kext bug ...

qwertyoruiop 11y ago
while I agree with you on the security benefits of a full microkernel, to be entirely honest, if you had access to just IOKit you could easily use a network card or an hard drive controller to get a physical memory write-what-where, which in turn would allow you to gain access to anything, plus the microkernel performance issues of e.g. having to context switch on interrupts.
- bro-stick 11y ago
  That things may be broken is no argument against defense-in-depth and least privilege. By having smaller codebases and smaller system components, the attack surface is far, far smaller than say Linux. IOKit is shit as is, and a full microkernel would break it up into processes based on areas of responsibility. Also, that shows the hardware needs better bus- and command-level security to prevent such attacks. (Don't even get me started on closed firmware blobs or unverifiability of commercial cores.) Expecting a finished product of a new project would be unreasonable. Minix 3 is early on and not the only full microkernel out there. They will probably find an approach to reduce context switches if it's a mature optimization to make. An Android-like mobile/embedded platform would make a sensible research -> real use-case, minus Java.