3 ms·

Software defense techniques are getting more sophisticated and capable but software is getting far more complex compromising many of these defensive techniques.

Software defense techniques are getting more sophisticated and capable but software is getting far more complex compromising many of these defensive techniques. For instance JITs provide vital performance increases but require memory pages which are marked as execute and write which degrades the effectiveness of many memory corruption protections. What we have achieved is that if you are willing to keep things simple and give up much of the modern world (e.g. JITs) you can build far more secure software than what was possible in the past. What we have done is extend the realm of the possible in both the direction of security and vulnerability (e.g. before TrustZone it wasn't possible to leverage TrustZone to exploit a kernel).

charleslmunger 10y ago
For a jit, can a page be marked read only and executable after it has been set up?
- EthanHeilman 10y ago
  It can be, I'm not sure how it would help since the JIT would want to continually write to that page.
  - cvwright 10y ago
    The idea is that the JITed code is executed much more often than it's (re)written, right? So each time the JIT (re)compiles the code, it can call mprotect on the target page to allow writes and disable execution. Then after it's done, it calls mprotect again to disable writes and allow execute.
    - EthanHeilman 10y ago
      The shell code is in the code which is compiled. 1. Put shell code in a string in some js, 2. get browser to JIT js and thus write the string that contains the shell code to an execute page in memory, 3. exploit a vulnerability and point the instruction pointer to the location of the string which contains the shellcode. Normally, i.e. outside of a JIT, this wouldn't work because the string would be saved to a non-executable page.
      - cvwright 10y ago
        Ah, so it's not that you inject your shellcode directly onto an exectuable page, but instead you get the JIT to create it there for you. That makes sense. Thanks!
oconnor663 10y ago
Is it fair to say that JITs are usually restricted to memory-safe languages, which don't rely so much on machine-level defenses? I guess you're losing something if you load a C library into your Java program, because exploits in the C library can do more damage now. But at the same time, having the majority of your code in Java is probably a win for security?
- EthanHeilman 10y ago
  The idea is to leverage heap spraying[0] in the pages to write shell code which can then be triggered from another vulnerability in the program. This shell code could live in some string in a chunk of javascript. Thus, this technique does not need to violate the memory safety of the JITTed code. This can be partially mitigated using constant blinding[1] but it isn't perfect. [0]: https://en.wikipedia.org/wiki/Heap_spraying https://en.wikipedia.org/wiki/Heap_spraying [1]: https://www.internetsociety.org/doc/dachshund-digging-and-securing-non-blinded-constants-jit-code https://www.internetsociety.org/doc/dachshund-digging-and-se...

charleslmunger 10y ago

For a jit, can a page be marked read only and executable after it has been set up?

EthanHeilman 10y ago
It can be, I'm not sure how it would help since the JIT would want to continually write to that page.
- cvwright 10y ago
  The idea is that the JITed code is executed much more often than it's (re)written, right? So each time the JIT (re)compiles the code, it can call mprotect on the target page to allow writes and disable execution. Then after it's done, it calls mprotect again to disable writes and allow execute.
  - EthanHeilman 10y ago
    The shell code is in the code which is compiled. 1. Put shell code in a string in some js, 2. get browser to JIT js and thus write the string that contains the shell code to an execute page in memory, 3. exploit a vulnerability and point the instruction pointer to the location of the string which contains the shellcode. Normally, i.e. outside of a JIT, this wouldn't work because the string would be saved to a non-executable page.
    - cvwright 10y ago
      Ah, so it's not that you inject your shellcode directly onto an exectuable page, but instead you get the JIT to create it there for you. That makes sense. Thanks!

oconnor663 10y ago

Is it fair to say that JITs are usually restricted to memory-safe languages, which don't rely so much on machine-level defenses? I guess you're losing something if you load a C library into your Java program, because exploits in the C library can do more damage now. But at the same time, having the majority of your code in Java is probably a win for security?

EthanHeilman 10y ago
The idea is to leverage heap spraying[0] in the pages to write shell code which can then be triggered from another vulnerability in the program. This shell code could live in some string in a chunk of javascript. Thus, this technique does not need to violate the memory safety of the JITTed code. This can be partially mitigated using constant blinding[1] but it isn't perfect. [0]: https://en.wikipedia.org/wiki/Heap_spraying https://en.wikipedia.org/wiki/Heap_spraying [1]: https://www.internetsociety.org/doc/dachshund-digging-and-securing-non-blinded-constants-jit-code https://www.internetsociety.org/doc/dachshund-digging-and-se...