The array offsets_to_Names is dynamically allocated on the stack using exp->NumberOfFunctions as its size (line 104). However, the loop starting at line 111 uses exp->NumberOfNames to iterate over it and set values at line 132. Therefore, this snippet assumes that exp->NumberOfFunctions is greater than ordinal at each iteration.
That condition may be followed by compilers, but not by hackers. What happens if I craft a PE file with ordinal greater than or equal to exp->NumberOfFunctions? Depending on the values, I am able to overwrite the return address of pe_exports function. On Windows 7 and Windows Server 2008 (systems on which I could produce higher impact), I may even use a ROP chain to get an arbitrary code execution.
Hello guys.
I have found a bug on
pe_exportsfunction fromexports.cwhich allows me to exploitreadpe.exeprogram frompev 0.81(last release).The issue occurs on the following lines:
https://github.com/merces/libpe/blob/07f90de4e5cc6f7aff8e8b62ca1a39804907848f/exports.c#L104-L132
The array
offsets_to_Namesis dynamically allocated on the stack usingexp->NumberOfFunctionsas its size (line 104). However, the loop starting at line 111 usesexp->NumberOfNamesto iterate over it and set values at line 132. Therefore, this snippet assumes thatexp->NumberOfFunctionsis greater thanordinalat each iteration.That condition may be followed by compilers, but not by hackers. What happens if I craft a PE file with
ordinalgreater than or equal toexp->NumberOfFunctions? Depending on the values, I am able to overwrite the return address ofpe_exportsfunction. On Windows 7 and Windows Server 2008 (systems on which I could produce higher impact), I may even use a ROP chain to get an arbitrary code execution.I have recorded a PoC video to proof the exploitability of the bug on
readpe.exe: https://drive.google.com/file/d/1zBH9ykgmHlnWQEBDIxwrYG8CTrHtUf26/view?usp=sharing.If you guys need any more details about the bug, I am at your disposal!