Comments on cr0 blog: CVE-2010-0232: Microsoft Windows NT #GP Trap Handl...

to Anonymous: >Code is never executed with the ...

2010-01-28T15:14:41.805-08:00

to Anonymous:
>Code is never executed with the vdm context
>specified, and that never happens with the exploit.
Yes, that would be correct. Our misunderstanding applies not to the exploit codepath, but to the nature of the checks performed in the VdmSwapContexts().

to Pablo Sole:
>test ebx, eax
>jnz short loc_6F7936 ;ebx=EFLAGS.VM
>or [esi+KTRAP_FRAME.SegCs], 3
Yup, for some bizzare reason we've missed exactly that point. Thank you for the clarification – now we can appreciate all the awesomeness of this exploitation.

I think you misunderstand the bug, of course setti...

2010-01-28T09:00:16.652-08:00

I think you misunderstand the bug, of course setting up a context is impossible (if that was the case, you could just pass one to NtCreateThread() and get ring0). Code is never executed with the vdm context specified, and that never happens with the exploit.

The bug is that the contents of the trap frame is trusted to be accurate. I would suggest you try it before claiming it's wrong :-(

to MTU: If you check VdmSwapContexts, which is th...

2010-01-28T05:20:33.630-08:00

to MTU:

If you check VdmSwapContexts, which is the function that switchs to monitor context, it has a checking that SS and CS need to be ring 3, unless it's V86:
PAGE:006F7919 mov eax, [edi+CONTEXT.EFlags]
PAGE:006F791F test ebx, eax
PAGE:006F7921 jnz short loc_6F7936 ;ebx=EFLAGS.VM
PAGE:006F7923 or [esi+KTRAP_FRAME.SegCs], 3
PAGE:006F7927 mov ecx, [esi+6Ch]
PAGE:006F792A or [esi+KTRAP_FRAME.HardwareSegSs], 3
PAGE:006F792E cmp ecx, 8
PAGE:006F7931 jnb short loc_6F7936
PAGE:006F7933 mov [esi+KTRAP_FRAME.SegCs], edx ; Force 0x1B

Tavis, thank you for the intresting writeup. We we...

2010-01-28T00:57:27.738-08:00

Tavis, thank you for the intresting writeup. We were happy to know about this VDM bug. Now, we have some thoughts. Codepath was audited and it seems there's no real 'trap frame forging' there, since involved part of KiTrap0D handler expects actual situation with hardware frame at the time of iret-fault (which happens since rpl > cpl): error code, eip-cs, eflags – and no esp-ss. Moreover, it seems the exploitation can be greatly simplified – we see no reason not to just specify context with user-mode eip and KGDT_R0_CODE cs in the fake VDM context. Given the fact eflags in the fake VDM context is also controllable, it appears the part with 'Ki386BiosCallReturnAddress' is not really required for the exploitation and can be skipped altogether – i.e. just set up fake VDM context with cs=8, eip=MyFunction, esi=param1, edi=param2, etc.

Now, we didn't actually try to paste a few lines of code together to implement this because of lazyness, so if there's something missing in our resoning – please correct us.