Dropbox - ASLR = easier exploits

So my love/hate relationship with Enterprise File Sharing Services (EFSS, e.g. Dropbox) continues.   This week a researcher examining Dropbox discovered that Dropbox DLLs aren’t compiled to use ASLR.  My only question is why the heck not?

What is ASLR?

ASLR is address space layout randomization.  There was a time when an attacker would know the memory addresses where critical API functions (GetProcAddress, LoadLibrary) were located in memory for a given operating system.  This makes exploits easier (much easier) to write since you have predictable landing zones in memory.  When ASLR came along, these addresses were randomized at every reboot.  Attackers can still find the addresses of APIs in memory, but they have to work for it. That makes shellcode larger and as a result some buffers can no longer hold exploit code for certain exploits.  Even when a vulnerability is still exploitable, the attacker has to work harder to gain reliable code execution.

Why do we care?

Well, for this whole ASLR scheme to work, it has to be implemented every time.  When it isn’t implemented every time, the whole system starts to fall apart.  Just one non-ASLR DLL in a process gives the attacker an anchor point so they no longer need to search for their APIs in shellcode.

Note: I’m intentionally glossing over some details here, so if you’re a die-hard exploit dev, don’t flame me.  My goal here is to make this digestible so I stop hearing calls of “so what” from the masses.

So back to Dropbox…

Dropbox decided not to compile with ASLR. There are a stunning number of 3^rd party Windows applications that don’t use ASLR, but this usually doesn’t create a problem for other applications.  Dropbox is different though because it loads code into many different processes started by the user, including the desktop (explorer.exe).  Now if one of these applications has a vulnerability and the target user is running Dropbox, the attacker can deliver much more trivial shellcode to exploit the vulnerability because they know some static addresses.

Dropbox has apparently fixed this for x64 but not the x86 versions of their DLLs.  For those who may not be aware, you can’t inject an x64 DLL into x86 code (or vice versa).  This means that even if you are running an x64 operating system you are probably still running x86 applications (which will load the x86 DLL).

But can this really be exploited?

Under the right conditions, yes.  It requires a vulnerability in another service that loads the x86 Dropbox DLL first.  Then, the attacker must know that the victim is using Dropbox.  If they are on the same LAN this is pretty easy due to LANSync.  In any case, Dropbox should know better and should be built with ASLR enabled.

Thanks to Graham Sutherland for posting the results of his research.

http://codeinsecurity.wordpress.com/2013/09/09/installing-dropbox-prepare-to-lose-aslr/