3 ms·

Can you explain why allowing apps to ship with a JIT compiler be a security issue?

by Jyaif 7y ago

acdha 7y ago
Think about what a JIT compiler means: it's allocating memory, writing to it, and then executing it. That's also what malware does so if you give third parties access to that functionality you have the immediate problem that the number of people who can make a mistake which gives native code execution goes up dramatically and that any attempts to restrict it in the future will risk breaking previously-working apps — think about how many years Adobe was able to slack because nobody wanted to break Flash even though it was a huge source of security bugs affecting most people on the Internet.
Someone 7y ago
A common attack method is to overwrite the stack or some buffer and then somehow make the CPU run the bytes written as code (https://en.wikipedia.org/wiki/Buffer_overflow#Exploitation https://en.wikipedia.org/wiki/Buffer_overflow#Exploitation, https://en.wikipedia.org/wiki/Buffer_overflow#Heap-based_exploitation https://en.wikipedia.org/wiki/Buffer_overflow#Heap-based_exp...) A common mitigation to that is “write xor execute” (https://en.wikipedia.org/wiki/W%5EX https://en.wikipedia.org/wiki/W%5EX) From that page: ”Without such protection, a program can write (as data) CPU instructions in an area of memory intended for data and then arrange to run (as executable) those instructions. This can be dangerous if the writer of the memory is malicious.” JIT compilers are collateral damage to that mitigation; they have to write bytes to memory and then make the CPU run those bytes as code, and W^X doesn’t allow that.
- saagarjha 7y ago
  FWIW, switching memory from RW- to R-X (which is still W^X) is also not allowed unless you have certain, easier to get entitlements.
saagarjha 7y ago
Apple's security model for iOS, as far as I can tell, is to be able to analyze all executable code in applications at review time. Being able to dynamically generate code does not work with this policy.
vbezhenar 7y ago
Apple libraries use private APIs but developers must not use them directly. If you allow developers to execute arbitrary bytes, they can submit app which does not call private API but will be able to call them later after approve. JavaScript is safe, because it can't call C API, but arbitrary JIT engine is not.
fragmede 7y ago
Sandboxing a JIT compiler is impossible to do perfectly, so there will always be the possibility of a sandbox escape, allowing the device to be jailbroken; but alsio for bad actors to take control of the device.

Can you explain why allowing apps to ship with a JIT compiler be a security issue?

by Jyaif 7y ago

Can you explain why allowing apps to ship with a JIT compiler be a security issue?

Think about what a JIT compiler means: it's allocating memory, writing to it, and then executing it. That's also what malware does so if you give third parties access to that functionality you have the immediate problem that the number of people who can make a mistake which gives native code execution goes up dramatically and that any attempts to restrict it in the future will risk breaking previously-working apps — think about how many years Adobe was able to slack because nobody wanted to break Flash even though it was a huge source of security bugs affecting most people on the Internet.

Someone 7y ago

A common attack method is to overwrite the stack or some buffer and then somehow make the CPU run the bytes written as code (https://en.wikipedia.org/wiki/Buffer_overflow#Exploitation https://en.wikipedia.org/wiki/Buffer_overflow#Exploitation, https://en.wikipedia.org/wiki/Buffer_overflow#Heap-based_exploitation https://en.wikipedia.org/wiki/Buffer_overflow#Heap-based_exp...) A common mitigation to that is “write xor execute” (https://en.wikipedia.org/wiki/W%5EX https://en.wikipedia.org/wiki/W%5EX) From that page: ”Without such protection, a program can write (as data) CPU instructions in an area of memory intended for data and then arrange to run (as executable) those instructions. This can be dangerous if the writer of the memory is malicious.” JIT compilers are collateral damage to that mitigation; they have to write bytes to memory and then make the CPU run those bytes as code, and W^X doesn’t allow that.

saagarjha 7y ago
FWIW, switching memory from RW- to R-X (which is still W^X) is also not allowed unless you have certain, easier to get entitlements.

saagarjha 7y ago

Apple's security model for iOS, as far as I can tell, is to be able to analyze all executable code in applications at review time. Being able to dynamically generate code does not work with this policy.

vbezhenar 7y ago

Apple libraries use private APIs but developers must not use them directly. If you allow developers to execute arbitrary bytes, they can submit app which does not call private API but will be able to call them later after approve. JavaScript is safe, because it can't call C API, but arbitrary JIT engine is not.

fragmede 7y ago

Sandboxing a JIT compiler is impossible to do perfectly, so there will always be the possibility of a sandbox escape, allowing the device to be jailbroken; but alsio for bad actors to take control of the device.