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.
