Hi!
As some of you may know, 2 weeks ago I posted an exploit module for metasploit and it got committed in revision 8975.
Weaponizing actual PoC in working exploit is quite an interesting process in understanding and getting some exploit writing techniques.
Thanks to Joshua Drake for helping me on this one.
It was prolly a SEH based exploit, there was a buffer overflow in the m3u parsing routine. There wasn't anything really special about this exploit, it's a classic SEH exploit.
We have a direct ret overwrite at offset 1024 and SEH overwrite at offset 1040.
For bad chars, there was the classic NULL, then tried "\r\d" and turns out they were bad chars. 0x5c was found later to be a bad char too.
We found the pointers using msfpescan mostly, immunity debug and some plugins to see if they were SafeSEH modules or not.
The SEH exploit buffer is as follow :
[encoder] [payload] [junk] [ret] [stub] [jmp] [se handler]
The ret version :
[encoder] [payload] [junk] [ret]
The SEH ret pointer is quite interesting as how it is generated.
Since 0xc0000000 points after 0x80000000, it's a kernel pointer, it will trigger an exception for sure ;) .
0x01 in the rest of the address is to make sure we don't have NULL characters.
And finally rand() to have a different signature for the ret address each time.
The direct ret overwrite pointer is a "call ecx" since ecx points to our buffer ;) .
For the people wanting to have more details on SEH exploits, I advise you reading Peter Eeckoutte's great serie ;) .
m_101
Link to the exploit module : SteinBerg MyMP3Player .
Link to Peter Van Eechoutte's Blog : Peter Van Eechoutte's articles
As some of you may know, 2 weeks ago I posted an exploit module for metasploit and it got committed in revision 8975.
Weaponizing actual PoC in working exploit is quite an interesting process in understanding and getting some exploit writing techniques.
Thanks to Joshua Drake for helping me on this one.
It was prolly a SEH based exploit, there was a buffer overflow in the m3u parsing routine. There wasn't anything really special about this exploit, it's a classic SEH exploit.
We have a direct ret overwrite at offset 1024 and SEH overwrite at offset 1040.
For bad chars, there was the classic NULL, then tried "\r\d" and turns out they were bad chars. 0x5c was found later to be a bad char too.
We found the pointers using msfpescan mostly, immunity debug and some plugins to see if they were SafeSEH modules or not.
The SEH exploit buffer is as follow :
[encoder] [payload] [junk] [ret] [stub] [jmp] [se handler]
The ret version :
[encoder] [payload] [junk] [ret]
The SEH ret pointer is quite interesting as how it is generated.
Since 0xc0000000 points after 0x80000000, it's a kernel pointer, it will trigger an exception for sure ;) .
0x01 in the rest of the address is to make sure we don't have NULL characters.
And finally rand() to have a different signature for the ret address each time.
The direct ret overwrite pointer is a "call ecx" since ecx points to our buffer ;) .
For the people wanting to have more details on SEH exploits, I advise you reading Peter Eeckoutte's great serie ;) .
m_101
Link to the exploit module : SteinBerg MyMP3Player .
Link to Peter Van Eechoutte's Blog : Peter Van Eechoutte's articles
