The application is still exposed to the first found vulnerability, even after several updates. So…likewise…I do not further care about a responsible disclosure process with Photodex, it’s just a waste of time!
My newly discovered issue, is quite easy to exploit. For those of you who are interested, here’s a short review of the discovery and exploitation process. By the way the application contains several other security flaws. Let’s expose’em all ;-)
When opening the application help via the menu, the application loads the location of the help file from the file “proshow.cfg”. If the file “proshow.phd” also exists the values are crosschecked.
So basically it’s a buffer overflow vulnerability triggered by some malformed input which leads to EIP control:
The vulnerability can be triggered by copying a “proshow.cfg” / “proshow.phd” configuration file with a manipulated ”cpicHelpFile” identifier to the application directory and after launching the application by manually navigating to the application help via the menu:
But what happens here ? The vulnerable code snippet:
Let’s examine the different parts: The application first loads the “cpicHelpFile” value from the configuration file, and directly uses that string as an argument for the ExpandMacroFilename() function without a proper input validation:
The ExpandMacroFilename() function then copies the string byte by byte:
And fills up the stack:
So far, the malformed string did not overwrite anywthing useful. The string is again used as an argument for the Windows HelpFile - System “hh.exe”, which is executed using a Kernel32.WinExec call:
That’s the reason why the triggered vulnerability will always show a msgbox from the hh.exe stating that the help file couldn’t be found. Anyways I gnore this message for this demonstration.
At the end of the vulnerable code part, the ESP is moved directly into the overwritten part of the stack and ret’ed…
…which means full application flow control:
Now an exploit can be developed as usual. A look at the next stack frames shows that there is a pointer to the beginning of the input string at ESP+C4 (yes this is just one way, there are several others):
Great, just need to find an instruction somewhere in the code to jmp or call this part. A quite good location to look for a matching instruction-set is the if.dnt application file, because it’s not protected by Rebase, SafeSEH, ASLR or NX and it’s always delivered with the application installer, which should serve a quite reliable exploit - ignore the .dnt extension here - it’s just a renamed .dll file:
The mona.py script reveals a useful instruction set @ 0x101af2ba:
which jumps directly to ESP+C4 and executes the code starting at this position. Side-Notice: We’ve got only 244 bytes of space for shellcode, beacuse the application terminates the copy-process at some point.
Now the same shellcode already used in my firts exploit can be used to launch a calc.exe:
inserted into the proshow.cfg:
and into proshow.phd:
And finally this leads to a reliable way of shellcode execution - working fine on Windows XP SP3 and Windows 7 SP1 x64