
Dropbox disables ASLR on Windows - timpattinson
http://codeinsecurity.wordpress.com/2013/09/09/installing-dropbox-prepare-to-lose-aslr/
======
tlrobinson
ASLR = Address Space Layout Randomization

[https://en.wikipedia.org/wiki/Address_space_layout_randomiza...](https://en.wikipedia.org/wiki/Address_space_layout_randomization)

~~~
ash
Thank you! Search engines are spoiling us. Entire article about an acronym
that doesn't bother decyphering or explaining it.

~~~
spc476
I'm surprised that more people don't wrap such acronyms (or abbreviations) in
<ACRONYM> or <ABBR> tags (at least the first time it's used in a page or
article).

~~~
TazeTSchnitzel
Some wiki software even does that automatically!
[http://wiki.php.net/rfc](http://wiki.php.net/rfc)

~~~
spc476
There are issues with doing it automatically though:
[http://boston.conman.org/2003/11/19.2](http://boston.conman.org/2003/11/19.2)

------
onehoof
"Dropbox" and "Security" are pretty much opposing terms. Remember this is the
same company that when faced with a login bug, chose to disable password
authentication so that anyone could log in as anyone else instead of shutting
the service down until it was fixed.

~~~
api
Name one company that's gone out of business because of a security problem, or
even had their business significantly impacted. I can't. I'm sure if you dig
you could find one, but I'm not aware of one off the top of my head.

Until this sort of thing matters to users, nothing will change.

~~~
jlkinsel
Let's see...

TJ Max, UBS, Knight Capital, Heartland Payment Systems, Visa, Sony (already
mentioned, but it's my fave), Stanford, Countless other hospitals, e-commerce
vendors, banks, and other organizations that handle payment or personal
information.

If you want to say "name a startup that's gone out of business because of a
security problem" I'll let you away with that. There's still instances, and
I'd love startups to pay more attention to security, but I know reality as
well...

~~~
Permit
What was Knight Capital's security problem?

~~~
jlkinsel
Last year when KC shot themselves in the face, they were running trading algos
that hadn't been well tested. When dropped into production, things blew up
fairly quickly.

I probably should have left it off the list, it's more of a
compliance/procedural issue than purely infosec.

------
scott_karana
> 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.

For those particularly worried.

Still disturbing, but this seems to point to technical concerns.

~~~
jcampbell1
Does ASLR do anything for the 32-bit address space? It seems like you could
enumerate it and find libc in a few seconds. I am mostly talking out of my ass
here, as I am no expert on these subjects.

~~~
revelation
If you can execute code, you could certainly do that, even on 64 bit.

The problem is executing code in the first place. There are other mechanisms
in place that can prevent a crash to turn into direct code execution (NX-bit).
To circumvent those, you can use Return Oriented Programming (ROP), where you
prepare the stack such that you jump into a loaded library or other
(completely innocent!) code in memory. The problem then is that you need to
know where the code you want to jump to resides in memory, and thats where
ASLR comes in. With ASLR, modules are randomly allocated in memory and an
attacker can't predict where code he wants to jump to resides at.

(ROP is a pretty fascinating topic in itself. The problem is essentially that
you are given a bunch of assembly, and your task is to figure out how to use,
combine it into _gadgets_ that emulate generic computing functionality (pop a
value from the stack, push a value to the stack, call a function, ..) such
that you can build your shellcode from those gadgets)

------
lawnchair_larry
That's very bad. It's been a long battle to stomp out ASLR-breaking modules
from browsers. Vendors who do this undermine all of that.

------
timpattinson
Comments from /r/netsec thread here:
[http://www.reddit.com/r/netsec/comments/1m25gi/installing_dr...](http://www.reddit.com/r/netsec/comments/1m25gi/installing_dropbox_prepare_to_lose_aslr/)

------
andyjohnson0
I know very little about ASLR. Anyone care to comment on possible reasons why
Dropbox would disable it?

I find it hard to believe that this is a deliberate attempt to weaken client-
side security, so its more likely that they are using some legacy code that is
somehow incompatible with ASLR. But ASLR has been in Windows since 2007, pre-
dating Dropbox by about a year, so they either developed ASLR-incompatible
code after the feature was live or the problem is in a third-part component.

Any other explanations? What problems can ASLR cause?

~~~
wepple
if a single dll loaded by dropbox hasn't been compiled with /DYNAMICBASE to
instruct the OS to allow ASLR, Dropbox will have some reliable memory
addresses available to an attacker, often defeating the purpose of using it on
anything.

Perhaps they're using an old or unusual linker?

~~~
andyjohnson0
I understand about the /DYNAMICBASE flag, but I has hoping to understand why
they would choose to not set it.

My assumption is that they disabled it for stability/reliability reasons that
are specific to their application, and I was further hoping to understand what
kind of bugs could be triggered by having ASLR enabled. I've written plenty of
C and C++ over many years and can't think of any bugs that I've introduced or
found where assumptions about address place layout were involved.

Since we're talking about Windows, I assume they're using Visual Studio and
its linker.

------
Theriac25
Why is it even possible for DLLs/applications to disable ASLR by themselves,
shouldn't that be decision for the OS or admin?

~~~
asveikau
> Why is it even possible for DLLs/applications to disable ASLR by themselves

Compatibility with old apps. There is software out there in the world that
relies on the address space not changing, either deliberately or due to bugs.
You could argue that they shouldn't do that, but people get pissed when their
stuff doesn't work with the new Windows. The most cautious thing they can do
for these apps is make it opt-in. (I believe the default may be different for
amd64? Not sure..)

> decision for the ... admin

I believe the policy is also a system setting, and maybe even you can override
the value in the PE header this way.

------
yalogin
Interesting. The option /DYNAMICBASE seems to be the default (to support
ASLR). Which means they explicitly disabled it. Wonder why? Are they doing
something that needed ASLR to be off?

~~~
taspeotis
We have an application that builds with a variety of misconfigured options (by
modern standards). We fix 'em when we see 'em.

It's a result of upgrading from VC++4, to VC++5, to VC++6, to VS2003, to
VS2005, to VS2008. They're set by the project upgrade wizard, for
compatibility reasons.

Which is not to say that Dropbox didn't manually set the flag, I'm unsure if
/DYNAMICBASE is set or unset for the sake of compatibility.

------
Dylan16807
So it doesn't disable ASLR outside of this dll, right? The process is already
loaded; it can't un-randomize.

~~~
lawnchair_larry
It doesn't need to. The attacker can just target the dropbox DLL now, which is
more than enough to execute a payload. Having 1 module inject itself without
ASLR means you may as well not be running ASLR on the process at all.

~~~
Dylan16807
Not everything is equally exploitable.

~~~
lawnchair_larry
It is when the non-ASLR Dropbox dll is injected. That's the point.

~~~
wtallis
I think the point was that the attack surface of the Dropbox DLL is not
necessarily the same as the attack surface of an entire web browser running
without ASLR. Do you have reason to state otherwise, or are you just trying to
say that you think the Dropbox DLL is so full of vulnerabilities that it would
always be the easiest attack vector even for a process that didn't use ASLR at
all?

~~~
aparadja
I think the idea is to still find your vulnerability in the browser as usual,
but abuse the unrandomized Dropbox DLL for executing the payload.

So, the DLL isn't directly attacked. It's simply used to circumvent ASLR.

~~~
Dylan16807
Abusing it _how_ , though? Trying to piggyback on a return opcode is one
method that would work, certainly, but if you're using a narrow exploit you
don't get to be very choosy, and there are many attacks that require very
specific known-address code. Losing ASLR on a single DLL is not nearly as bad
as losing it on all DLLs.

~~~
doug11235
Losing ASLR on a single DLL does provide that very specific known-address
code.

~~~
Dylan16807
>Losing ASLR on a single DLL does provide that very specific known-address
code.

I don't know how to respond to this. The word 'specific' means something. If
your exploit needs a certain sequence of code, and the little dropbox hook
doesn't have it, then the exploit's not going to work.

~~~
doug11235
Yes, you are right - if dropbox doesn't have it then it won't work. But you
imply that it most likely won't have it. And what myself and perhaps others
are saying is it most likely will.

The DLL in the blog post is listed as 128KB, out of interest I looked at it
separately and I see a .text section with a size of 0x132df bytes. That
section will be mapped as executable and every byte in it is potentially
useful. Intel doesn't require instruction alignment, has variable length
instructions, and several different opcodes map to the same instruction in
some cases. The probability of not finding the instruction sequences you need
to successfully land an exploit is almost nil.

Additionally, this is loaded in a browser. The hardest part about browser
exploits these days is defeating ASLR. Finding DLLs that aren't compatible
with ASLR that can be loaded has been one of the main methods of defeating it.

Successful exploitation often requires chaining several vulnerabilities
together to get what a single vulnerability would even a few years ago.
Anything that can easily be leveraged in that chain is a problem and needs to
be addressed.

~~~
Dylan16807
>The probability of not finding the instruction sequences you need to
successfully land an exploit is almost nil.

I don't know about that. Ignoring the mapping of opcodes for a moment, 128K
random bytes will probably not have any particular three-byte sequence, and
almost definitely won't have anything longer. And opening the DLL it appears
to have vast quantities of 00, FF, and CC. There is a lot of repetition,
lowering the attack surface.

I'm willing to bet that if you restrict yourself to attacks that need specific
instruction sequences, and not just a return opcode, a healthy majority will
fail on this dll.

I agree that this is a problem, but that's largely because some attacks can
work with nearly any function. It's still a lot less of a problem than turning
off ASLR entirely.

~~~
jbri
Well, it's not 128k random bytes, a large chunk of that is compiled executable
code. That weights things very much towards sequences of opcodes that achieve
something when executed.

------
trurl42
It seems like git-cheetah and the 7-Zip shell extension exhibit the same
problem. MinGW doesn't enable ASLR by default, which might be the reason for
that.

------
caiob
how about less acronyms?

~~~
lutusp
>how about less acronyms?

Or, better, how about _fewer_ acronyms?

~~~
daave
That's a rather US-centric remark.

'less' is an acceptable comparative for both countable and uncountable nouns
in all modern dialects of English _except_ for US-English, where it's strictly
expected that fewer be used for countables.

Perhaps caiob is from the UK, Australia, India, South Africa, New Zealand...

~~~
timthorn
It's not acceptable in the UK:
[http://www.telegraph.co.uk/news/uknews/2659948/Tesco-to-
ditc...](http://www.telegraph.co.uk/news/uknews/2659948/Tesco-to-ditch-ten-
items-or-less-sign-after-good-grammar-campaign.html)

~~~
daave
Hardly sounds definitive. From your link:

"There is a debate about whether the word should be 'less' or 'fewer'," a
campaign spokesman said. "Saying 'up to ten items' is easy to understand and
avoids any debate."

and

A Tesco spokesman said: "The debate about what is right has been going on for
years now, and I still don't think we know if 'less' or 'fewer' is correct."

------
sitkack
I have always suspected dropbox was a rootkit trojan. Ever since the founder
said that it was open to sifting through users data for copyright violations.

~~~
immad
Citation Needed.

~~~
toomuchtodo
This is the closest thing I could find googling for 45 seconds:

[http://www.pcworld.com/article/226280/dropbox_a_file_sharers...](http://www.pcworld.com/article/226280/dropbox_a_file_sharers_dream_tool.html)

[https://news.ycombinator.com/item?id=2483053](https://news.ycombinator.com/item?id=2483053)

------
SilliMon
What's most worrying about this is that Dropbox is injecting itself into
processes like NotePad++ and Firefox that have nothing to do with shell
extensions.

Either this is lazy coding, or there is some malicious intent to spy.

~~~
elehack
They use the standard file open dialog, which in turn supports shell
extensions.

