[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

[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

[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

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

[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

[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

[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

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