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).
"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.
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.
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...
How exactly has Stanford had its business impacted due to a security breach? I'm only thinking in terms of people wanting to apply, and I can't imagine how that'd be a deterrent.
To go a little further - at a glance, it's not clear if they've been fined yet or not, but either way there's soft costs to all of this - being in the news in a negative light, some patients will go elsewhere, their insurance premiums are going to go up as a result of the breaches, etc etc.
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.
You can quibble about the numbers; the article doesn't come out and say it but the exact number may have been subject to some accounting shenanigans (probably the fully-legal kind, but that still leaves leeway). But it did cost them, both money and reputation.
That said, I tend to agree with your general point. But companies don't quite get off entirely without consequence... it's just rare enough that it's more like a bolt from the blue than a reliable penalty.
> 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.
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.
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)
It does, because the attacker has no means to enumerate. Having the means to enumerate the address space always defeats ASLR (called an info leak). Without that, the attacker has to blindly specify what address they want to write to. Without ASLR, these are static across the same versions of a given app on different systems, so shooting blind isn't a problem. With ASLR, that option is removed.
Most malicious software uses fixed-offsets, so any kind of ASLR makes all this not work. And while it's possible to search the address space, in practice this is actually quite hard, even for 32-bit.
If you guess a wrong address, the process crashes.
With a fork-based server, you don't care much about that. Every time you connect, you get a fresh new process - with the same addresses as the older copies even.
So brute-forcing those is more viable than a browser where you probably won't have more than 1 or 2 attempts per user.
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?
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.
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.
> 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.
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?
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.
It's possible they're using an older version of MSVC or an alternative compiler. I don't think /DYNAMICBASE is on by default in VS2005/2008 and it's definitely not on by default in MinGW GCC.
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.
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?
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.
>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.
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.
>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.
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.
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.
This is true, but meaningless, because an attacker is going to craft an exploit that targets the Dropbox DLL specifically.
I think you're thinking an exploit is something which is tried against different processes until one of them turns out to be vulnerable. That's true for some kinds of exploits. But in this case, we're trying to point out that an attacker is going to exploit the Dropbox DLL's certain sequence of code.
I'm thinking about exploits that only have a limited range of motion. They need code to perform part of the action for them, that they can take advantage of. You can't just use arbitrary code for that, you need code that is vulnerable in very particular ways.
The assumption with rop exploits is that the targeted library will support any arbitrary sequence needed. So far, this seems to be a generally valid assumption.
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.
'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...
"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."
That’s odd. I know highly literate people from all of the above, and I’ve never heard any of them misuse less.
Usually the highly literate folks misusing less are from Germany, the Netherlands or Scandinavia. It’s jarring when I hear or see it in otherwise erudite discourse.
Now, I know many native speakers of English in the US and various commonwealth nations that are unaware of the distinction. So I suspect you’re right on the larger point that this particular persnickety rule is dying in the vernacular everywhere. But I’d love to see your source for this rule not being universal in formal speech or when written.
Which mentions the 'rule' started to get pushed around in the 1800s, though 'Less has always been used in English with counting nouns.'
I suppose we'll always be stuck with this ambiguity in English since there's no formal authority to tell us how we should speak/write.
From my own observations, having grown up in Australia and since moved to the US, I must say the common practice is notably different, I almost never heard anyone say fewer in Australia, but have noticed that many Americans (like the poster here) seem to be on a crusade to ensure less isn't 'misused'.
So is this a sign of that horror of horrors, the destruction of the English language by modern speakers who can’t be bothered to learn the rules of the grammar?
Unsurprisingly, no. As it turns out, this whole notion that fewer is countable and less is uncountable has been traced back to 1770 by the Merriam-Webster Dictionary of English Usage. And it wasn’t a rule back then, but rather a preference of a single author, Robert Baker. (That’s not to say that no one agreed with him, only that no one else seems to have put it in print back then.) So it’s not that modern ne’er-do-wells are ruining the language; at worst, they’re returning it to an earlier state. The OED attests countable less in 1481, derived from an Old English usage attested by no less a personage than King Alfred.
All right. So less used to be fine with countables. Then a dude came along and said he wasn’t fond of that, and his opinion eventually got codified into a rule. But, as MWDEU and the Google results point out, countable less remains common, despite the widespread acceptance of this rule outlawing it. Now, to me, that suggests that the rule that less can’t be used with count nouns is spurious.
Summary: The idea that less can’t be used with count nouns isn’t well supported; it’s a rule that hasn’t ever been strictly followed, especially for count nouns that can be perceived as masses. Groceries lend themselves to perception as a mass, so it’s no surprise that “10 items or less” is favored now, just as it has been historically. Please stop complaining about this.
You're forgetting that not everyone here is from an English speaking country. If you can understand the point he was trying to make, that should be good enough for you.
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.
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.
https://en.wikipedia.org/wiki/Address_space_layout_randomiza...