I wouldn't call a RAM scraper an exploit. ASLR isn't an effective protection against a program that reads from memory. Driver signing in newer versions of Windows is a more appropriate protection but will still fall short of stopping a motivated attacker.
1. If I make more than approx $106k a year, I cap out on paying FICA.
2. As far as I know, everything I buy at places like Amazon costs the same regardless of where I live (with in the US).
3. Many financial incentives are provided as a percentage instead of a raw dollar amount e.g. 401k's are usually matched by percentage, raises are often a percentage increase.
Are you serious? National security != fighting terrorists. From Wikipedia for the lazy.
> National security is the requirement to maintain the survival of the state through the use of economic power, diplomacy, power projection and political power. The concept developed mostly in the United States after World War II. Initially focusing on military might, it now encompasses a broad range of facets, all of which impinge on the non military or economic security of the nation and the values espoused by the national society. Accordingly, in order to possess national security, a nation needs to possess economic security, energy security, environmental security, etc. Security threats involve not only conventional foes such as other nation-states but also non-state actors such as violent non-state actors, narcotic cartels, multinational corporations and non-governmental organisations; some authorities include natural disasters and events causing severe environmental damage in this category.
> So your arbitrary code is running as admin - what more could a security flaw in the bundled installshield get you?
In the days of Antivirus products and executable whitelists, the "elevation of privilege" may be getting arbitrary execution as any user. Of course trustedinstaller.exe or whatever that has a valid Microsoft signature can run, why shouldn't it? No need to ship that file back home either for further analysis (as AV products like to do with unknown files), its a standard OS thing. Therefore my rootkit isn't burned either.
>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.
I don't see where that says they spy on each other. I only see bits that mention they spy on other countries of common interest e.g. China and share that data.
ECHELON is more relevant for this. (https://en.wikipedia.org/wiki/ECHELON) See especially the controversy section, which shows that the US was using the system for industrial espionage.
I read that article as explaining why a web application can't do crypto with javascript. As someone that knows almost nothing about browser extensions, can you elaborate on why one isn't a good idea for chrome?
The sections "How are browsers hostile to cryptography?", "What systems programming functionality does Javascript lack?", "What else is the Javascript runtime lacking for crypto implementors" cover issues you would encounter with browser extension cryto.
Ah yeah. I believe the usual terminology is such that "extensions" are javascript and "addons" are something native. You could probably do cryto well with an addon.. to the extent that it is possible to do an addon at all properly (honestly I have no idea there).
