VUPlayer 2.49 Playlist Parsing Buffer Overflow

It's been a looong time since my last post. As I wrote in the previous post I have had a busy schedule with final exams right on my tail and my career ending project requiring some extra attention as well. Fortunately everything went as expected and I can finally proudly announce that MoreNops.com is back at full throttle. Alongside updated content, I also changed the organization and design of the site a little bit. I added a site in top of the blog so that access to previous work, profile and contact are easier to find. In this aspect, any feedback is welcome and I'm open to suggestions. Openings aside, like we have done in the past, today we will review a recently disclosed exploit to keep learning more about the inner workings of our daily use software and the security threat that sometimes can become for our systems. The bug in question is a stack-based buffer overflow in the parsing of files in VUPlayer 2.49 as stated by this advisory from Secunia. In this particular case, the vector attack that we will follow is crafting a malicious ".asx" file which, as stated here, is a simple XML metafile linking to a windows multimedia files. In this particular case we will make (ab)use of the HREF parameter inside the statement to overflow a stack based buffer where the name of the referenced file will be stored. This vulnerability clearly illustrates the risk of two different functions handling the same data in diferent structures, particularly strings. We will divide the analysis in two parts; in the first part we will see how a function takes care of parsing ".asx" files and storing them inside an object and in the second part we will see how the dynamic nature of this object will allow us to redirect execution to a arbitrary address. Now that the procedure is clear, let's get our hands dirty. The function that parses ".asx" files (and presumably others as well) begins at 0x004B9B20. The function basically takes a path directory pointing to the file to parse and proceeds to parse it. Basically it looks for the '<' and '>' delimiters and copies characters as long as it can read from the file. This read-while-something-to-read nature will allow us to write almost as lengthy as we want as filename in the HREF= filename parameter. A little more reversing revealed some interesting details about the inner workings of this parsing process but that's irrelevant to the exploitation process and that's in the hands of the reader. All we need to remember from this step is that we can store a name as long as we want inside an object in memory. At this point let's focus in the juicy function that will gives us control over the execution. This function begins at 0x004532A0 where after setting up a exception handler and allocating space in the stack it proceeds to copy in a local variable the name of the file to be played which we referenced using the ".asx" file, this is where the object we created earlier comes into play. Since we could store an arbitrarily long file name inside the object and this is now copied in a stack buffer of fixed length using a function that doesn't properly check the length of the source and destination buffers ( lstrcpy() in this case), we can use a overly long name to bypass the 1012 byte length that leads to the ret value stored in the stack. Here is the disassembly for the vulnerable function: 
.text:004532B8                 sub     esp, 4DCh       ; make space in stack for local vars
.text:004532BE                 push    esi
.text:004532BF                 push    edi
.text:004532C0                 mov     [ebp+var_4C0], ecx
.text:004532C6                 push    1               ; int
.text:004532C8                 push    0               ; Offset
.text:004532CA                 push    0               ; Count
.text:004532CC                 push    0               ; DstBuf
.text:004532CE                 mov     ecx, [ebp+var_4C0]
.text:004532D4                 call    sub_456160
.text:004532D9                 mov     al, String2
.text:004532DE                 mov     [ebp+Filename], al
.text:004532E4                 mov     ecx, 40h
.text:004532E9                 xor     eax, eax
.text:004532EB                 lea     edi, [ebp+var_3EF]
.text:004532F1                 rep stosd
.text:004532F3                 stosw
.text:004532F5                 stosb
.text:004532F6                 mov     ecx, [ebp+var_4C0]
.text:004532FC                 mov     edx, [ecx+4]
.text:004532FF                 mov     [ebp+lpString2], edx
.text:00453305                 mov     eax, [ebp+lpString2] ; local stack variable
.text:0045330B                 push    eax             ; lpString2
.text:0045330C                 lea     ecx, [ebp+Filename] ; name of the file
.text:00453312                 push    ecx             ; lpString1
.text:00453313                 call    ds:lstrcpyAWell, it's been great fun to spend some time meandering with low-level stuff after a 2 month break. For the next establishment I will try to bring a remote hole that always has some extra I-do-it-over-the-wire excitement :). Meanwhile, know that I'm really glad I can do this again and MoreNops.com is back on track! See you around!
Update: The exploitation part of this review has been intentionally removed because as stated in the 400th Article of the Spanish Legal Code "La fabricación o tenencia de útiles, materiales, instrumentos, sustancias, máquinas, programas de ordenador o aparatos, específicamente destinados a la comisión de los delitos descritos en los capítulos anteriores, se castigarán con la pena señalada en cada caso para los autores." which basically means it's ILLEGAL to provide tools or keep tools, materials, instruments, etc...specifically developed to commit a felony.