CrashWrangler – Apple’s !exploitable

CrashWrangler is a set of developer tools that help in creating and debugging secure Mac OS X applications. The tools work by inspecting the application’s state at the time of the crash, as well as the application crash logs. Using these tools on a reproducible test case can determine if a crash could lead to a potentially exploitable security issue, while providing valuable data to fix these issues. Additionally, any crash log can be inspected to determine if it is a duplicate of a known crash. The CrashWrangler tools support Mac OS X 10.5 or later.

It should be understood that CrashWrangler uses advanced heuristics, but that false positives and false negatives are possible. It’s intended for quick assessment. As always, a detailed manual inspection is the only way to be sure something is or isn’t exploitable. The basic algorithm for determining exploitability looks like this.

Exploitable if: Crash on write instruction Crash executing invalid address Crash calling an invalid address Crash accessing an uninitialized or freed pointer as indicated by using the MallocScribble environment variable 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 Other abort Crash on read instruction

If a crash is determined to be non-exploitable, it’s recommended to run the test case again with libgmalloc(3) on with MALLOC_ALLOW_READS and MALLOC_FILL_SPACE set, and see if the crash changes to one that is considered to be exploitable.

CrashWrangler does not send any data about your crash to Apple or anyone else. Note that it does forward the information about the crash to CrashReporter, which is part of the OS, and as always it will send info to Apple if and only if you click the “Send to Apple” button in the Crash Reporter dialog.

Apple keyboard firmware based keylogger hack

Apple’s keyboards are no have 8Kb of flash memory, and 256 bytes of RAM. K. Chen has found a way to very easily install keyloggers, rootkits or other malicious code right inside of an Apple keyboard. K. Chen presented his findings at this year’s Black Hat conference.

It’s actually quite easy to abuse the memory and RAM in Apple keyboards, thanks to Apple’s HIDFirmwareUpdaterTool, which is used to update the firmware in HID devices, among which is the Apple keyboard. “The tool is run, a breakpoint set, and then you simply cut and paste the new code into the firmware image in memory. That’s it,” SemiAccurate explains. Nothing is encrypted, decrypted, and it’s all very simple to do. Resume the HIDFirmwareUpdaterTool, and a few seconds later, your keyboard is compromised. Rebooting won’t help, you can’t pull any batteries, and it’s impossible to detect.

News, main...