[issue24201] _winreg PyHKEY Type Confusion

Steve Dower added the comment: Agreed. -- resolution: -> wont fix stage: needs patch -> resolved status: open -> closed ___ Python tracker ___ __

[issue24201] _winreg PyHKEY Type Confusion

Zachary Ware added the comment: I agree with Eryk that this is not a winreg bug. If I'm understanding this correctly, you would need to pass unsanitized remote input into a function that's going to affect your registry. That strikes me as an incredibly ridiculous thing to do; anyone doing so

[issue24201] _winreg PyHKEY Type Confusion

Steve Dower added the comment: I think this requires arbitrary code execution as a minimum - there's no way anyone would pass a user-provided value here - so the security implications are less interesting. All we can really do is restrict the types accepted here, which I don't think is approp

[issue24201] _winreg PyHKEY Type Confusion

Christian Heimes added the comment: Steve, Zach, please have a look. -- assignee: -> steve.dower nosy: +christian.heimes stage: -> needs patch ___ Python tracker ___ __

[issue24201] _winreg PyHKEY Type Confusion

JohnLeitch added the comment: Thank you again for the explanation of the internals at play here. Armed with the knowledge you provided, I conducted further experimentation, and I believe I can now demonstrate how EIP control is possible with this bug. Note that RPC initialization is not necess

[issue24201] _winreg PyHKEY Type Confusion

eryksun added the comment: > ntdll!RtlAllocateHeap+0x17: > 776f1037 8b4344 mov eax,dword ptr [ebx+44h] > ds:002b:0044= Some functions in RPCRT4 assume RPCRT4!PerformRpcInitialization has already been called. How else could you get an RPC handle? In this case RPCRT4!hR

[issue24201] _winreg PyHKEY Type Confusion

JohnLeitch added the comment: Thank you for taking the time to peruse my report and explain the behavior I observed. My understanding of Windows RPC internals is lacking, and perhaps I jumped the gun upon catching an AV while fuzzing. That said, after poking around to better understand the mat

[issue24201] _winreg PyHKEY Type Confusion

eryksun added the comment: > wherein pointers can be passed directly in place of PyHKEY > instances e.g. _winreg.QueryValue(0x41414141, "") If a debugger is attached you see the first-chance exception for the access violation. Normally the registry function simply returns ERROR_INVALID_HANDLE

[issue24201] _winreg PyHKEY Type Confusion

New submission from JohnLeitch: The Python _winreg module suffers from a type confusion vulnerability wherein pointers can be passed directly in place of PyHKEY instances e.g. _winreg.QueryValue(0x41414141, "") This behavior is due to the underlying PyHKEY_AsHKEY function of _winreg.c: BOOL P