21-09-25, 12:55 AM
Hello dakrforums community, today I have found a 0day in windows consent.exe file, a key file in window UAC system. This all started when I was reverse engineering the consent.exe file located inside the system32 folder, I not only successfully decompiled the entire source code, but built a reconstructed version of it which will be easier to edit, analyze and use in the future (the source code leaks will come soon)
So, here is the vulnerable code I found as well as a reconstruction of it I found when reviewing the decompiled code: https://snippet.host/ggmtmv
Okay so basically The code copies filename/argument text supplied from CommandLineToArgvW. If an attacker can invoke this code path with a long filename/argument they control, they can overflow the buffer used for lpsz or adjacent stack data. consent.exe is the UAC/consent UI process; it runs elevated and communicates with secure parts of the OS. A memory corruption in this process can lead to local privilege escalation or code execution depending on surrounding protections (ASLR/CFG/DEP/etc.). That makes the bug high severity. Also elsewhere the binary uses SHStrDupW and WindowsGetStringRawBuffer to duplicate strings — but the manual loop-style copy above does not use safe APIs like StringCchCopyW/StringCchCatW consistently.
so in summary: The HLIL shows code that calls CommandLineToArgvW, then processes each argument and copies a filename into a local buffer (lpsz) by walking the source characters in a loop with only a crude counter (0x104) and an early break. That pattern is exactly where a long filename/argument can overflow the destination. See the disassembly/HLIL excerpt around the CommandLineToArgvW handling.
Heres some exploits I wrote for it: https://files.catbox.moe/m9g8ld.c https://files.catbox.moe/8sdyrm.c
So, here is the vulnerable code I found as well as a reconstruction of it I found when reviewing the decompiled code: https://snippet.host/ggmtmv
Okay so basically The code copies filename/argument text supplied from CommandLineToArgvW. If an attacker can invoke this code path with a long filename/argument they control, they can overflow the buffer used for lpsz or adjacent stack data. consent.exe is the UAC/consent UI process; it runs elevated and communicates with secure parts of the OS. A memory corruption in this process can lead to local privilege escalation or code execution depending on surrounding protections (ASLR/CFG/DEP/etc.). That makes the bug high severity. Also elsewhere the binary uses SHStrDupW and WindowsGetStringRawBuffer to duplicate strings — but the manual loop-style copy above does not use safe APIs like StringCchCopyW/StringCchCatW consistently.
so in summary: The HLIL shows code that calls CommandLineToArgvW, then processes each argument and copies a filename into a local buffer (lpsz) by walking the source characters in a loop with only a crude counter (0x104) and an early break. That pattern is exactly where a long filename/argument can overflow the destination. See the disassembly/HLIL excerpt around the CommandLineToArgvW handling.
Heres some exploits I wrote for it: https://files.catbox.moe/m9g8ld.c https://files.catbox.moe/8sdyrm.c
