The libaries you use can make you vulnerable too

TL;DR - I'm not saying Dropbox is vulnerable to denial of service based on its use of out of date OpenSSL libraries.  We didn't verify that and have no plans to do so.  This is more a cautionary tale for businesses who haven't thought of auditing their apps (or the libraries they depend on).

Audit your apps
So you've audited your application and found no vulnerabilities.  And that's good - you're in the top n% (where n < 10) of security programs out there if you are doing real security auditing on your applications.  But it turns out that it's about more than just the code your developers write.  It's the libraries your code uses too.

Vulnerable History
There's a rich history of applications being vulnerable through the use of vulnerable libraries.  For example, in CVE 2014-8485 all the reporting seemed to be that the program strings was vulnerable.  But that wasn't really the case.  Rather, it was libbfd that actually had the vulnerability - strings was simply using libbfd.

Another obvious example is Heartbleed.  Although the vulnerability was in OpenSSL, applications that used a vulnerable version of OpenSSL (compiled with DTLS heartbeats enabled) were also vulnerable.

Heartbleed has been patched - no more OpenSSL patches?
Unfortunately, Heartbleed wasn't the last vulnerability associated with OpensSSL.  There have been a number of OpenSSL vulnerabilities in 2015 alone.  Of those, CVE 2015-0209 is probably the most concerning since it is a use after free.  So far, there is no publicly working code execution exploit for this (and a working exploit might not be possible).  But that's not to say that the recent OpenSSL vulnerabilities don't matter.  Several are Denial of Service (DoS) vulnerabilities, abusing a null pointer dereference.  This means that software using a vulnerable version of OpenSSL would crash if one of these vulnerabilities were exploited.

Poor Dropbox...
Why am I talking about libraries now?  I came across this last week looking at an implementation of Dropbox for a client of Rendition Infosec.  As you may know, Dropbox and I have a rich, sordid history with Dropsmack.

While investigating the current version of Dropbox (3.10.11) we noticed that one of the support libraries (Qt5Network.dll, version 5.4.2.0) is linked with OpenSSL 0.9.8ze.  This version of OpenSSL was released in January 2015 and is two versions out of date.  We didn't try to exploit these any null pointer dereference vulnerabilities, but feel free to jump on that if you're interested.

OpenSSL 0.9.8ze vulnerabilities

So in this case, it looks like Dropbox developers rely on Qt5Network.dll, which in turn was linked with a vulnerable version of OpenSSL.  It's a difficult environment indeed for developers who desire to code securely.  Not only do you have to ensure that the libraries you use are up to date, but you also have to ensure that all the libraries they use are also up to date (recursively).  This is why having a strong application security program in house (or via trusted partners) is so critical.  I would dare say that Dropbox has more application security resources and wider distribution than most organizations who publish their own software for internal or external use.  If it can happen to a major software vendor, it can happen to you too.

Remember to audit your apps (and the libraries they use) regularly.