As I followed the trail described by Mr. Szor and Mr. Chien’s article (http://www.peterszor.com/blended.pdf), it became clear to me the following was the transfer point to the abused exception handler like Code Red. For a normal C/C++ function, it was OK to assume that sub-functions will not depend on the values of EBX, EDI, and ESI and will not abuse them. However, that assumption was proved wrong with the Code Red exploitation and should be corrected. One simple way is to save EBX and xor EBX out before it transfers the rein. A more panicky way is to save and xor out all the unused registers like EBX, EDI, and ESI for this function before it calls ECX as follows: NTDLL Sub_77F9250D called by KiUserExceptionDispatcher .text:77F9250D mov edx, offset loc_77F8A896 .text:77F92512 .text:77F92512 loc_77F92512: ; CODE XREF: sub_77F8A88A+7j .text:77F92512 push ebp .text:77F92513 mov ebp, esp .text:77F92515 push [ebp+arg_8] .text:77F92518 push edx .text:77F92519 push large dword ptr fs:0 push ebx push edi push esi xor esi, esi xor edi, edi xor ebx, ebx .text:77F92520 mov large fs:0, esp .text:77F92527 push [ebp+arg_10] .text:77F9252A push [ebp+arg_C] .text:77F9252D push [ebp+arg_8] .text:77F92530 push [ebp+arg_4] .text:77F92533 mov ecx, [ebp+arg_14] .text:77F92536 call ecx .text:77F92538 mov esp, large fs:0 pop esi pop edi pop ebx .text:77F9253F pop large dword ptr fs:0 .text:77F92546 mov esp, ebp .text:77F92548 pop ebp .text:77F92549 retn 14h That is it. Two cracks (one boundary check bug and another normal (sometimes incomplete) assumption about C/C++ call) made the Code Red exploitation possible in real life. Peter Huang For more articles written by Peter Huang, please visit http://members.rogers.com/yinrong/articlelist.html
