4 ms·

Although MS' reaction does appear to be irresponsible, a browser crash is hardly the worst security issue I can imagine. If that's all this guy is finding -- it

by sabat 16y ago

Although MS' reaction does appear to be irresponsible, a browser crash is hardly the worst security issue I can imagine. If that's all this guy is finding -- it's all he mentions in his post -- then this sounds more like security for security's sake than anything practical.

ximeng 16y ago
I don't know the details, but a fully attacker controlled EIP sounds likely to be exploitable doesn't it? Possibly data leakage from the browser, maybe arbitrary execution if the attacker is lucky. This sounds likely at the least to put an attacker in a better place to socially engineer a user into installing malware.
- daeken 16y ago
  If you can control EIP, you can run arbitrary code, period. It might be difficult depending on whether ASLR is in use or not, but it can always be done.
  - ximeng 16y ago
    Doesn't this assume you can get the code you want to execute into memory? And that the page it ends up in is marked as executable?
    - daeken 16y ago
      Short answer: No Long answer: It depends on what you define as arbitrary code execution. In a good number of cases, you can use ROP to execute whatever "code" (made up of little bits of existing program code repurposed for your needs) you wish, and accomplish whatever you want to accomplish. In many cases, this is finding your "real" code and setting memory protection such that you can jump into it. In effect, if you have control over EIP, you've already owned the system; it might not be easy to do everything you want to do, but it's effectively always possible.
      - ximeng 16y ago
        Interesting, thanks. According to Google, ROP is return-oriented programming, where you build up a program by jumping to near the end of existing executable subroutines. The control flow comes from corrupting the stack with a list of the addresses of this code. The example here: http://cseweb.ucsd.edu/~hovav/dist/sparc.pdf http://cseweb.ucsd.edu/~hovav/dist/sparc.pdf uses a stack overflow. I'm not sure how this would work with just an arbitrary EIP though. Seems to me you need a bit more than that.
viraptor 16y ago
It's not all that he's reporting, he's just assuming some hacking knowledge I guess. Every time you see a crash which is caused by jumping to some unknown address, there's a pretty good chance that the crash is exploitable - but you can't tell that easily without going through the source / poking around the binary. Basically in many cases the jumps into non-code areas mean that some buffer overflowed (or some pointer got corrupted) and overwrote the stack frame return address. As long as you can control what was overwritten, you're likely to be able to point at the data you supplied yourself (back at the stack with some text you control). If that condition is true, you can provide new code for execution straight from html - that means the crash is exploitable. Then again, even if you can't see how is that specific crash exploitable, it doesn't mean it isn't. For some time double-free crashes were just bugs. Then someone found out you can manipulate the pointers in possible later reallocations. What I'm trying to say is that every crash caused by user supplied data should be looked at from the "might be exploitable in the future" perspective.
- rphlx 16y ago
  > Every time you see a crash which is caused by jumping to some unknown address, there's a pretty good chance that the crash is exploitable No. It's not 2001. Modern MS (and UNIX) operating systems and compilers use NX, stack guarding, and addr randomization to make stack/heap overflows pretty difficult to exploit. Not impossible, but statistically unlikely. Run-of-the-mill C programming errors in a web browser are hardly automatic remote sploits now. > every crash caused by user supplied data should be looked at from the "might be exploitable in the future" perspective. OK, I agree with this, but out of principle, not because there's a high chance it's remotely exploitable.

by sabat 16y ago

ximeng 16y ago

I don't know the details, but a fully attacker controlled EIP sounds likely to be exploitable doesn't it? Possibly data leakage from the browser, maybe arbitrary execution if the attacker is lucky. This sounds likely at the least to put an attacker in a better place to socially engineer a user into installing malware.

daeken 16y ago
If you can control EIP, you can run arbitrary code, period. It might be difficult depending on whether ASLR is in use or not, but it can always be done.
- ximeng 16y ago
  Doesn't this assume you can get the code you want to execute into memory? And that the page it ends up in is marked as executable?
  - daeken 16y ago
    Short answer: No Long answer: It depends on what you define as arbitrary code execution. In a good number of cases, you can use ROP to execute whatever "code" (made up of little bits of existing program code repurposed for your needs) you wish, and accomplish whatever you want to accomplish. In many cases, this is finding your "real" code and setting memory protection such that you can jump into it. In effect, if you have control over EIP, you've already owned the system; it might not be easy to do everything you want to do, but it's effectively always possible.
    - ximeng 16y ago
      Interesting, thanks. According to Google, ROP is return-oriented programming, where you build up a program by jumping to near the end of existing executable subroutines. The control flow comes from corrupting the stack with a list of the addresses of this code. The example here: http://cseweb.ucsd.edu/~hovav/dist/sparc.pdf http://cseweb.ucsd.edu/~hovav/dist/sparc.pdf uses a stack overflow. I'm not sure how this would work with just an arbitrary EIP though. Seems to me you need a bit more than that.

viraptor 16y ago

It's not all that he's reporting, he's just assuming some hacking knowledge I guess. Every time you see a crash which is caused by jumping to some unknown address, there's a pretty good chance that the crash is exploitable - but you can't tell that easily without going through the source / poking around the binary. Basically in many cases the jumps into non-code areas mean that some buffer overflowed (or some pointer got corrupted) and overwrote the stack frame return address. As long as you can control what was overwritten, you're likely to be able to point at the data you supplied yourself (back at the stack with some text you control). If that condition is true, you can provide new code for execution straight from html - that means the crash is exploitable. Then again, even if you can't see how is that specific crash exploitable, it doesn't mean it isn't. For some time double-free crashes were just bugs. Then someone found out you can manipulate the pointers in possible later reallocations. What I'm trying to say is that every crash caused by user supplied data should be looked at from the "might be exploitable in the future" perspective.

rphlx 16y ago
> Every time you see a crash which is caused by jumping to some unknown address, there's a pretty good chance that the crash is exploitable No. It's not 2001. Modern MS (and UNIX) operating systems and compilers use NX, stack guarding, and addr randomization to make stack/heap overflows pretty difficult to exploit. Not impossible, but statistically unlikely. Run-of-the-mill C programming errors in a web browser are hardly automatic remote sploits now. > every crash caused by user supplied data should be looked at from the "might be exploitable in the future" perspective. OK, I agree with this, but out of principle, not because there's a high chance it's remotely exploitable.