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.“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.”
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.“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.”
void bob(char *badstr)
printf("Copy done: %s\n", dest);
So build it and test it.
david-maynors-computer:~/code/book dave$ make exampleNow lets go take a look at the crash logs in /Users/dave/Library/Log/CrashReporter
cc example.c -o
david-maynors-computer:~/code/book dave$ ./example
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
Parent: bash 
Version: ??? (???)
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.
Armchair quarterbacks in security and tech stuff are becoming more and more common, and I like that you used that term. I don't know all that stuff you just did and can't necessarily read registers without a hand to hold, but at least I don't go defending products by waving my ignorance around. I think some people would rather live in ignorance than face truth and common sense.
PS, typo? "A few people (including me) responded to the individual and let him know that the error really does determine if something is exploitable."
I think you mean "doesn't determine."
Yup, typo. Its fixed now.
Post a Comment