XNU Crash Analysis

David Hoyt is an independent, authoritative source for Best Practices & Transparency. Hoyt works Independently to improve the User Experience & Security of Internet Products & Services.
>> Home » Blog » XNU Crash Analysis

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.

Exceptions

Exception TypeSubtypeExploitable
abortEXC_CRASHNo
bad_func_callEXC_BAD_ACCESSYes
cfrelease_nullNot Security RelatedNo
cpp_crashEXC_BAD_ACCESSYes
crashexecEXC_BAD_ACCESSYes
crashreadEXC_BAD_ACCESSNo
crashwriteEXC_BAD_ACCESSYes
divzeroEXC_ARITHMETICNo
exploitable_jitEXC_BAD_ACCESSYes
fastMallocEXC_BAD_ACCESSNo
fortify_source_overflowEXC_CRASHYes
illegal_libdispatchEXC_BAD_INSTRUCTIONNo
illegalinstructionEXC_BAD_INSTRUCTIONYes
invalid_addressEXC_BAD_ACCESSYes
malloc_abortEXC_CRASHYes
nocrashNot Security RelatedNo
null_derefEXC_BAD_ACCESSYes
objc_crashEXC_BAD_ACCESSYes
read_and_write_instructionEXC_BAD_ACCESSNo
recursionEXC_BAD_ACCESSNo
recursive_writeEXC_BAD_ACCESSNo
stack_buffer_overflowEXC_CRASHYes
variable_length_stack_bufferEXC_BAD_ACCESSYes
Exploitability Table

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

%d bloggers like this: