When people refuse to use common sense...

So I subscribe to the Focus-Apple list at security focus. During the DMG stuff from the Month of Kernel Bugs there was a big discussion about the exploitability of the bug. One of the list members then says:

“I have to admit I don't understand what you think this proves. It seems to me that the OS is giving you a KERN_PROTECTION_FAILURE instead of allowing you to do anything bad. Perhaps I just don't understand what's going on.”

A few people (including me) responded to the individual and let him know that the error really doesn't determine if something is exploitable. The discussion went on and it turns out that it wasn’t really that exploitable. A different individual comes back and wants an apology for people being wrong. He missed the entire point; the exploitability of the condition has NOTHING to do with that error message.

“As with Simon, I look forward to public apology from those who slagged usoff for expressing our opinions here, as the exploit had been so'confidently demonstrated'. One important lesson here is that you can onlybe arrogant when you have a thoroughly sound basis of evidence - andignoring the questions of others (particularly very experienced sysadminslike Simon) is standing into danger.”

How do I know that the error message really doesn’t have anything to do with the exploitability of a vulnerability you may ask? It’s simple; I wrote code to prove it. You see a lot of people seem to have no desire to actually investigate issues anymore but would rather instead play armchair quarter back and criticize others instead of investigating for themselves. Lets write some code, the very basic example of a stack overflow.

#include <stdio.h>
#include <string.h>

void bob(char *badstr)
{

char dest[5];

strcpy(dest, badstr);

printf("Copy done: %s\n", dest);
}

int main()
{

char
*bad="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";

printf("In main.\n");

bob(bad);

return 0;
}

So build it and test it.

david-maynors-computer:~/code/book dave$ make example
cc example.c -o
example
david-maynors-computer:~/code/book dave$ ./example
In main.
Copy done:
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Segmentation fault
david-maynors-computer:~/code/book dave$

Now lets go take a look at the crash logs in /Users/dave/Library/Log/CrashReporter
**********

Host Name: david-maynors-computer
Date/Time: 2007-01-18 09:45:32.555 -0500
OS Version: 10.4.7 (Build 8J2135)
Report Version: 4

Command: example
Path: ./example
Parent: bash [25427]

Version: ??? (???)

PID: 25453
Thread: Unknown

Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0x41414141

Backtrace not available

Unknown thread crashed with i386 Thread State:
eax: 0x00000039 ebx: 0x41414141 ecx:0x00000000 edx: 0x00000000
edi: 0xbffffd2c esi: 0xbffffd36 ebp:0x41414141 esp: 0xbffffc40
ss: 0x0000002f efl: 0x00010282 eip:0x41414141 cs: 0x00000027
ds: 0x0000002f es: 0x0000002f fs:0x00000000 gs: 0x00000037

Binary Images Description:
0x1000 - 0x1fff example /Users/dave/code/book/example
0x8fe00000 - 0x8fe4bfff dyld 45.1 /usr/lib/dyld
0x90000000 - 0x9016efff libSystem.B.dylib /usr/lib/libSystem.B.dylib
0x901be000 - 0x901c0fff libmathCommon.A.dylib /usr/lib/system/libmathCommon.A.dylib

It’s the same error message although you can clearly see that EIP has been overwritten by 0x41414141 (that’s hex for AAAA). So you can clearly see that no, KERN_INVALID_ADDRESS really has no affect on if something is exploitable or not. If I had placed the address of an instruction like “jmp esp” at the correct location in the string of A’s that clobbered the stack this crash would not have occurred, instead it would have went on to execute code that it finds on its stack.

The moral of the story: A lot of questions that are asked can often be solved with two minutes of code writing.