I’ve discovered another 0day Remote Code Execution flaw in a CNET.com Top10 software of its category, which has been downloaded more than 6 million times right now.

Affected Versions and CVSS

I’ve successfully verified the vulnerability in the following versions (but any older versions may be affected too):

  • Free Download Manager v3.9.3 build 1360 (latest)
  • Free Download Manager v3.8 build 1173
  • Free Download Manager v3.0 build 852

The CVSS score is 9,3 (AV:N/AC:M/Au:N/C:C/I:C/A:C) because there is a little bit of user interaction needed.

Technical Details

The application parses download requests, which are added to the download queue, but does not properly validate the length of the complete download queue object when it’s removed from the queue by the user:


The following function from fdm.exe (source file: Downloads_Deleted.cpp) is triggered on deletion:

This function reads the filename of the download object using CDownloads_Tasks::GetFileName into szFile and adds the whole URL value as a description (in brackets) via an insecure strcat() sequence to szFile during the queue deletion process.

Therefore the following Python script creates an arbitrary web server which sends an oversized filename value via a HTTP 301 redirect (just a simple trick to hide the payload, or which user would request it by himself 😉 ) to the download client and finally triggers the vulnerability:

If the complete name of the queued download exceeds the size of szFile (10000 bytes), strcat() writes outside the expected memory boundaries. The above Python script creates a download object of about 8000 bytes, but since the applications strcats this value about two times, you get a download queue entry of at least 16000 bytes which exceeds the buffer size of 10000 bytes. 

This results in a pwning crash:


The shown INT3 command at kernel32 in combination with the error message in ECX:

is just a hint of enabled /GS stack cookie protection, which might by bypassed (didn’t have a deeper look at this yet), but as the application is open source, it might be compiled without /GS protection too.

And there is also a second (local) way to exploit this vulnerability using the “Import list of downloads” function:


About the Disclosure Process

Now the sad part. Have a look at the disclosure timeline:

2014-02-20: Discovery of the vulnerability
2014-02-21: Vendor Notification #1 with preset disclosure date (2014-03-09)
2014-02-24: MITRE assigns CVE-2014-2087
2014-02-25: Vendor Notification #2
2014-02-26: Vendor Notification #3
2014-03-05: Vendor Response
2014-03-05: Vulnerability details sent to vendor
2014-03-09: RCE Security asks for a status update
2014-03-13: No response from vendor
2014-03-13: Full Disclosure according to disclosure policy

I’ve discovered this vulnerability on 2014-02-20 and notified the vendor with a preset disclosure date (2014-03-09) according to my disclosure policy a day later via email. No response. A few days later I’ve tried another way using their official web contact form. No response. Then I’ve tried it using their official forum directly to an admin who’s nickname is “Alex”. About a week later I received a very short response from Alex:

HI!Please send it to [*email censored*]. Thank you.

FDM development team

I’ve handed over the full vulnerability details including the vulnerable code part and the working PoC. As the preset disclosure date was set to 2014-03-09, I’ve asked for a status update on that date. Now guess…No response.

I thought, well let’s give them a bit more time to investigate. Now…a week later, I still haven’t received any notification about the vulnerability report, they haven’t even asked for an extension of the disclosure date.

One might think that the developers of a software like this actively care about their product security, but…well praise Full Disclosure 🙂

CVE-2014-2087: Free Download Manager CDownloads_Deleted:: UpdateDownload() Remote Code Execution
Tagged on:             

7 thoughts on “CVE-2014-2087: Free Download Manager CDownloads_Deleted:: UpdateDownload() Remote Code Execution

  • May 23, 2014 at 12:14 am

    I’m interested to see how you managed to get code exec on this. A while back I looked into this exact flaw and found that the stack overwrite managed to continually kill the process. I even had another guy (WAY smarter than me :)) take a look and saw the same thing. There’s a heap overflow in there too, but attacking that proved to be rather painful.

    • May 25, 2014 at 10:05 am

      The reason for the process termination in this case is the mentioned stack cookie protection. It basically checks if the stack cookie is still present (and unmodified) in the function epilogue. If you overwrite this cookie in a stack-based exploitation scenario to get control over a RET, the process will terminate, because the cookie comparison fails.

      In theory, there are multiple ways to bypass this protection – like e.g. triggering a SEH exception and since you have got control over the SEH chain (and in this case SafeSEH is disabled!), this might be used to get code exec. I did not have a deeper look at this yet, but I may take you up on that later :-).

  • October 1, 2015 at 10:16 am

    Thanks for the great work and providing insightful reading!!! I am actually a student taking a course on security and looking for a working POC of buffer overflow exploitation. I am very interested in your exploits on FDM since its difficulty matches our course materials. In fact, from a professional perspective, do you think this exploit is a good demo for undergrad level study? How should I start on trying out your exploits on my own? Like which OS are you running your exploit on?

    Appreciate your help!!!

    • October 1, 2015 at 9:00 pm

      The problem with FDM is about the stack cookie protection. So if you would like to exploit this vulnerability, you need to have a look at this issue first, which could be hard.

      Therefor I would rather recommend my exploit for CVE-2014-2206 (https://www.rcesecurity.com/2014/03/cve-2014-2206-getgo-download-manager-http-response-header-buffer-overflow-remote-code-execution/) to work on, because it is more straightforward.

      I develop each of my PoCs and exploits on a customized Linux system, but since its Python it should run on Windows too. Just take the CVE-2014-2206 exploit and go through the exploit development process step by step using my article and voila 😉

      • October 4, 2015 at 6:42 am

        Thank you so much! I will look at that article to find out more. BTW, according to my understanding, for these exploits, I would still need a VM to run a Linux system right?As I am using Win 7 which should have fixed the problem.

      • October 4, 2015 at 4:31 pm

        Hi Bro, I have looked through the GoGet exploit but I guess I can’t use it because Professor is asking us to do the exploit on an open-source software. GoGet does not seem to be the case according to my research. Anyway, thanks for your recommendation, I will try look for other exploits based on open-source software.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.