5 ms·

A JIT will write to memory and then turn the executable bit on. https://en.wikipedia.org/wiki/W%5EX https://en.wikipedia.org/wiki/W%5EX

high_byte 6y ago
you are implying this is the underlying cause for code execution exploit, it is not.
- Randor 6y ago
  Actually with the font exploits an interpreter would be quite a bit safer. Many of the font exploit chains work by creating line vectors that result in an infinity or NaN throwing a floating point error (with the SeH handler already being overwritten). When running this by JIT... all of this is occurring on the physical CPU. If the floating point calculations were occurring inside an interpreter then the SEH chain can be protected by SEHOP/SAFESEH and the interpreter could implement bounds checks and while retaining the NX bit on everything executing.
  - high_byte 6y ago
    a. closing one attack vector does not justify slowing down the entire world. b. you can have the jit compile with any bound checks as you suggested, so still not justifying an interpreter. the only reason for an interpreter is simplicity, once you have a jit there's no logical reason to go back. also when you say NX bit, you do know the interpreter is running code still. it's just doesn't have to be RW (actually jit don't either) which still allows for ROP. there has to be some very specific exploit for these things to have a dramatic effect (ie. can be vs. cannot be exploited) many times there will be several methods to exploit a vuln.
    - Randor 6y ago
      Well, I feel like you are arguing for JIT just for the sake of arguing. The topic we are discussing in this thread is "Interpreted is safer than JIT" which is absolutely true. Yeah, there are newer ROP mitigations coming down the pipeline, I agree verifiable execution flow remains a major problem.

5 ms·

A JIT will write to memory and then turn the executable bit on. https://en.wikipedia.org/wiki/W%5EX https://en.wikipedia.org/wiki/W%5EX

by throwaway33432 6y ago

high_byte 6y ago
you are implying this is the underlying cause for code execution exploit, it is not.
- Randor 6y ago
  Actually with the font exploits an interpreter would be quite a bit safer. Many of the font exploit chains work by creating line vectors that result in an infinity or NaN throwing a floating point error (with the SeH handler already being overwritten). When running this by JIT... all of this is occurring on the physical CPU. If the floating point calculations were occurring inside an interpreter then the SEH chain can be protected by SEHOP/SAFESEH and the interpreter could implement bounds checks and while retaining the NX bit on everything executing.
  - high_byte 6y ago
    a. closing one attack vector does not justify slowing down the entire world. b. you can have the jit compile with any bound checks as you suggested, so still not justifying an interpreter. the only reason for an interpreter is simplicity, once you have a jit there's no logical reason to go back. also when you say NX bit, you do know the interpreter is running code still. it's just doesn't have to be RW (actually jit don't either) which still allows for ROP. there has to be some very specific exploit for these things to have a dramatic effect (ie. can be vs. cannot be exploited) many times there will be several methods to exploit a vuln.
    - Randor 6y ago
      Well, I feel like you are arguing for JIT just for the sake of arguing. The topic we are discussing in this thread is "Interpreted is safer than JIT" which is absolutely true. Yeah, there are newer ROP mitigations coming down the pipeline, I agree verifiable execution flow remains a major problem.