Estimated reading time: 2 minutes
Executive Summary
This Article is intended for quick assessment of XNU Crash Analysis. Manually debugging the Code is the only way to be sure something is or isn’t exploitable. A Crash is only a security issue if it is triggered by untrusted input. Data ripped from Apple CrashWrangler, Lisa.py or other Public Domain Data Sources.
Table of contents
Exceptions
Exception Type | Subtype | Exploitable |
abort | EXC_CRASH | No |
bad_func_call | EXC_BAD_ACCESS | Yes |
cfrelease_null | Not Security Related | No |
cpp_crash | EXC_BAD_ACCESS | Yes |
crashexec | EXC_BAD_ACCESS | Yes |
crashread | EXC_BAD_ACCESS | No |
crashwrite | EXC_BAD_ACCESS | Yes |
divzero | EXC_ARITHMETIC | No |
exploitable_jit | EXC_BAD_ACCESS | Yes |
fastMalloc | EXC_BAD_ACCESS | No |
fortify_source_overflow | EXC_CRASH | Yes |
illegal_libdispatch | EXC_BAD_INSTRUCTION | No |
illegalinstruction | EXC_BAD_INSTRUCTION | Yes |
invalid_address | EXC_BAD_ACCESS | Yes |
malloc_abort | EXC_CRASH | Yes |
nocrash | Not Security Related | No |
null_deref | EXC_BAD_ACCESS | Yes |
objc_crash | EXC_BAD_ACCESS | Yes |
read_and_write_instruction | EXC_BAD_ACCESS | No |
recursion | EXC_BAD_ACCESS | No |
recursive_write | EXC_BAD_ACCESS | No |
stack_buffer_overflow | EXC_CRASH | Yes |
variable_length_stack_buffer | EXC_BAD_ACCESS | Yes |
detected buffer overflow | EXC_BAD_INSTRUCTION | Yes |
heap-buffer-overflow | EXC_BAD_ACCESS | Yes |
System Libraries
Ignore these System Libraries and look further up the Stack.
libSystem.B.dylib
libsystem_blocks.dylib
libsystem_kernel.dylib
libsystem_c.dylib
libsystem_m.dylib
libsystem_malloc.dylib
libsystem_network.dylib
libsystem_platform.dylib
libsystem_pthread.dylib
libsystem_sandbox.dylib
com.apple.CoreFoundation
libstdc++.6.dylib
libobjc.A.dylib
libgcc_s.1.dylib
libgmalloc.dylib
libc++abi.dylib
libxpc.dylib
libdispatch.dylib
modified_gmalloc.dylib #Apple internal dylib
libclang_rt.asan_osx_dynamic.dylib
dyld
???
System Functions
Ignore these System Functions
"WTFCrashWithSecurityImplication", "WTFCrash",
"CsLeReadUInt64", "CsLeReadSInt64", "CsLeReadUInt32", "CsLeReadSInt32","CsLeReadUInt16", "CsLeReadSInt16",
"CsLeWriteUInt64", "CsLeWriteSInt64", "CsLeWriteUInt32", "CsLeWriteSInt32","CsLeWriteUInt16", "CsLeWriteSInt16",
"JSC::DFG::crash(JSC::DFG::Graph&, WTF::CString const&, char const*, int, char const*, char const*)",
"JSC::DFG::Graph::handleAssertionFailure(std::nullptr_t, char const*, int, char const*, char const*)"
Offset Functions
Look for these offset functions:
- __longcopy
- __memmove
- __bcopy
- __memset_pattern
- __bzero
- memcpy
- longcopy
- memmove
- bcopy
- bzero
- memset_pattern
- WTFCrashWithSecurityImplication
- WTFCrash
- dyld_error
Exploitable if
- Crash on write instruction
- Crash executing invalid address
- Crash calling an invalid address
- Illegal instruction exception
- Abort due to -fstack-protector, _FORTIFY_SOURCE, heap corruption detected
- Stack trace of crashing thread contains certain functions such as malloc, free, szone_error, objc_MsgSend, etc.
Not exploitable if
- Divide by zero exception
- Stack grows too large due to recursion
- Null dereference(read or write)
- Other abort
- Crash on read instruction