Home > Vulnerabilities > Installing Dropbox? Prepare to lose ASLR.

Installing Dropbox? Prepare to lose ASLR.

Dropbox has become a daily part of my life. I rely on it to synchronise data between my growing set of devices. But how much of an impact does it have on the security of my system? I decided to find out by digging around in exactly what it does to my machine, or more specifically, the processes running on it.

The first thing I want to check out is what modules are loaded into various processes. Tools like Dropbox like to extend the functionality of other programs using shell extensions, which are nothing more than specially designed DLLs loaded into process memory. Let’s see what we’ve got…

Dropbox Files

Interesting! Looks like we’ve got two extension DLLs, one 32-bit and one 64-bit. These are likely used to add extra context menu options when right-clicking on files. Now let’s find out where they get injected. For this, we’ll use good ol’ trusty Process Explorer. By going to Find ยป Find Handle or DLL, we can search for the DLLs in running processes.

Dropbox DLL Injection

It looks like it’s being loaded into processes that have windows created, which implies it’s probably an AppInit DLL, but it turns out not to be the case – the registry key doesn’t contain that DLL. This implies that there’s something more active going on, and that Dropbox actively selects which processes to inject into. I may be mistaken here, I’m not sure. Either way, though, it’s a little odd that it chose to inject into Notepad++ and other innocuous processes.

(Update: thanks to zeha and 312c on Reddit for pointing out that it’s likely injected via the standard file browser shell, due to the Dropbox icon in the favourites list)

The biggest problem becomes clear when you take a look at the module in a running process. In this case, it’s Firefox:

Dropbox in Firefox

Notice that the Dropbox extension DLL doesn’t have the ASLR flag set. This means that any vulnerability in Firefox becomes a lot easier to exploit, since the Dropbox module provides an unrandomised anchor for a ROP chain. Ignore PowerHookMenu.dll here – I’m aware of that issue and have notified the developer, but it’s infrequently seen on people’s machines so it’s not so bad.

Let’s just quickly verify that the DLL isn’t ASLR enabled at all, by checking the DLL characteristics flags in the file…

ASLR disabled for DLL

Definitely not enabled.

Anyway, the take-away issue here is that Dropbox arbitrarily injects an ASLR-disabled DLL into various 32-bit and 64-bit processes, causing significant degradation in the efficacy of ASLR across the entire system. With no ASLR, an attacker could craft an exploit payload that utilises executable code within the injected DLL to product a ROP chain, leading to code execution. This is significantly problematic in high-risk programs like web browsers and torrent clients.

I notified Dropbox of this back when version was the latest version, but got not response. I’ve since tried again, but had no luck. I’m hoping that going public will give them the kick they need to get it fixed. In the meantime, a good mitigation is to install EMET and set a policy to enforce Mandatory ASLR. All of this was re-tested against Dropbox 2.0.22, with versions of both the 32-bit and 64-bit DLLs. The operating system used was Windows 7 x64 SP1.

Update: Brad “spender” Spengler (of grsec fame) has noted that the latest version of Dropbox has ASLR enabled for the 64-bit DLL, but still doesn’t on 32-bit.

Update 2: Dropbox responds: “Our engineers are aware of this issue and actively working on fixing it. Unfortunately, I can’t give you an exact timeline that a fix will become available. If you have any additional questions or concerns please let me know.”

Update 3: @_sinn3r has done some awesome work on the exploitability of these issues, over at Metasploit. Definitely worth a read.

About these ads
  1. September 9, 2013 at 23:43

    That’s an interesting find, but some other questions arise about why they chose not to enable ASLR. Have you also checked to see if the Dropbox executable attempts to access any of the remote processes to access the dll? It could be laziness in their part or wanted to avoid getting flooded with emails of their AV’s considering Dropbox a Virus because it used the combination of WriteProcessMemory/CreateRemoteThread to find the location of Dropbox dll..or something..

    • September 9, 2013 at 23:51

      I honestly think they just didn’t think about it. That’s often why you find such DLLs around the system. As I noted in an update, they’re likely just shell handlers and therefore don’t mod the process internally. I haven’t taken a proper look though – need to get IDA on it and have a dig around.

  2. September 10, 2013 at 05:20

    Have you considered looking into the box.com application? They tout increased security and compliance with goverment & education. Specifically they work with Internet2 and various higher level of learning groups.

    • September 10, 2013 at 08:27

      I’ll take a look at it when I get chance, assuming it’s free to download.

  3. September 10, 2013 at 12:36

    Well you can download files from the web directly in your Dropbox with this app:


    Thats the awesome thing about Dropbox

    • September 10, 2013 at 12:40

      Except that’s not really a solution – you’re just avoiding the primary mode of access that the official program provides. The solution is for Dropbox to fix their crap.

  4. Dropbox Wall of Shame
    September 10, 2013 at 12:52

    Unfortunately, if this has been around for a long time it just proves, once again, that Dropbox does not seem to get it when it comes to security and privacy. It’s sad that Dropbox is so famous and yet “callous” when it comes to how it treats its users.

    The more such issues are made public and shared, the better for everyone. Thanks for the detailed post.

  5. September 10, 2013 at 20:44

    Last I looked the real reason Dropbox needed to do this is because it statically compiles the Python runtime into it. Dropbox is written in Python. As we know from many other presentations on the subject, JIT runtimes often need ASLR disabled.

    • September 10, 2013 at 21:49

      I don’t see how JIT and ASLR are incompatible. You can still build and manage executable heaps that are affected by ASLR with no problems. If Python is defficient in this manner (I’ve never heard anyone say that it is) then we have a very serious problem – I’ll have to dig into it.

      That said, according to PEiD, CFF Explorer, and IDA, it was compiled with Microsoft Visual C++. I don’t see any references to Python in there. Furthermore, the extension DLLs that are injected contain native COM objects, which definitely weren’t written in Python. It seems you’re incorrect about this Python association.

  6. Abe
    September 12, 2013 at 10:16

    Parts are written in Python, other parts are not.

  7. September 16, 2013 at 20:34

    ASLR should not impact JITd code, so long as you ‘do it right’ – here’s a paper that discusses the issue from an NX perspective http://msdn.microsoft.com/en-us/library/bb430720.aspx (and more)

    FWIW, I have never seen issue wrt ASLR and JITd code, but certainly seen issues with NX and JITd code.

  8. mr none
    June 8, 2014 at 01:43

    I always go with the lil guys, once a large herd of sheep join in a fad, like dropbox, i am out.
    Besides, I never undertood why one would use someone elses cloud and not there own at home or on a shell, etc etc.
    Funn, how once you went public, you got some confirmated answers

  1. September 10, 2013 at 01:15
  2. September 10, 2013 at 15:01
  3. September 10, 2013 at 16:36
  4. September 10, 2013 at 17:38
  5. September 12, 2013 at 17:09
  6. September 13, 2013 at 21:16
  7. September 15, 2013 at 03:55
  8. September 16, 2013 at 18:33
  9. September 16, 2013 at 23:34
  10. September 17, 2013 at 13:09
  11. September 18, 2013 at 12:37
  12. September 21, 2013 at 20:52

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

Join 1,270 other followers

%d bloggers like this: