5 ms·

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

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 13y ago
Not everything is equally exploitable.
- lawnchair_larry 13y ago
  It is when the non-ASLR Dropbox dll is injected. That's the point.
  - wtallis 13y ago
    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 13y ago
      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 13y ago
        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 13y ago
        Losing ASLR on a single DLL does provide that very specific known-address code.
        Dylan16807 13y ago
        >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 13y ago
        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 13y ago
        >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.

Dylan16807 13y ago

Not everything is equally exploitable.

lawnchair_larry 13y ago
It is when the non-ASLR Dropbox dll is injected. That's the point.
- wtallis 13y ago
  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 13y ago
    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 13y ago
      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 13y ago
        Losing ASLR on a single DLL does provide that very specific known-address code.
        Dylan16807 13y ago
        >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 13y ago
        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 13y ago
        >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.