Dropbox disables ASLR on Windows
codeinsecurity.wordpress.com
codeinsecurity.wordpress.com
https://en.wikipedia.org/wiki/Address_space_layout_randomiza...
Until this sort of thing matters to users, nothing will change.
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.
The two free games were nice too. They gave us choices from top rated titles.
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...
I probably should have left it off the list, it's more of a compliance/procedural issue than purely infosec.
They had an issue with deploying....supposedly:) They still haven't come out and said exactly what the issue was.
http://www.healthcareitnews.com/news/stanford-reports-fifth-...
sony
rsa
epsilon
saic
tricare
tjmaxx/marshalls
lifelock
hannaford
U.S. department of Vet affairs
For those particularly worried.
Still disturbing, but this seems to point to technical concerns.
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)
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 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?
Perhaps they're using an old or unusual linker?
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.
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.
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.
So, the DLL isn't directly attacked. It's simply used to circumvent ASLR.
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.
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.
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.
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.
Or, better, how about fewer acronyms?
'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."
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.
It seems there's a wikipedia article on the dispute: http://en.wikipedia.org/wiki/Fewer_vs._less
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'.
http://motivatedgrammar.wordpress.com/2008/09/30/10-items-or...
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.
http://www.pcworld.com/article/226280/dropbox_a_file_sharers...
Either this is lazy coding, or there is some malicious intent to spy.