Sure, but it still means that the OS has to decide who is allowed to do it and to what extent. Sophisticated worms like Stuxnet would be much harder with strict W^X for example, since CVE-2010-2568 and the like would be much harder to execute.
Capabilities are a way to control that, and the point being that only responsible proven applications get the certificate, hence how it all goes on iOS.
You're making the assumption that "responsible" is something provable, but that is not the case, it is specially not easy to prove software is secure from tampering its behaviour.
Nonsense, there's no "system wide implications". Mappings are per process, and W^X is just a strategy to help harden individual processes, not the entire system. There's no herd immunity here.
JITs do not grant the ability to bypass any OS/system sandboxes. The lack of W^X doesn't do that, either. If a process opts out of W^X, such as to enable a JIT, it's voluntarily making itself less hardened, but at the end of the day this isn't any more meaningful than the program being allowed to be written in, say, C, which also voluntarily reduces the processes security hardening.
No, you're not understanding mine. Nobody builds an OS/system expecting that every executable is perfectly well behaved with zero bugs and zero ill intent. Applications are allowed to run code. JITs just run code in that same process. They are already limited to what the process was already allowed to do in the first place.
And my point about C is literally that even without a JIT, applications can still have arbitrary execution vulnerabilities.
A JIT intended to run untrusted code as part of a sandbox, like a browser, is a big risk. But that's because of the untrusted code part, not the JIT. By comparison, something like a Python or Java JIT is as near as makes no difference completely risk free. The JIT is working on exclusively "trusted" code. Same basic concept applies here with this database usage.
Yes, but your claim is that applications can still have arbitrary execution vulnerabilities only on operating systems that allow dynamic executable code.
I am refuting that statement by showing that not allowing dynamic executable code is not enough. It is irrelevant to that end that you can mitigate ROP by other means.
If a process is allowed to execute code, it's always allowed to execute arbitrary code as well. Those two are fully intertwined, be it via dynamic executable code, ROP chains, because it has an interpreter, or because the initial binary itself already is the malicious payload in the first place.
To the OS those are all identical scenarios, it's irrelevant what caused the arbitrary code execution to happen.
Comments
Maybe, but surely there are users who are willing to trust all users of their db instance.
The issue is that it restricts from locking-down and securing the system with Write xor Execute memory. So it has system wide implication.
https://en.wikipedia.org/wiki/W%5EX
W^X is typically per mapping, not per memory page and does not interfere with JIT compilation.
Sure, but it still means that the OS has to decide who is allowed to do it and to what extent. Sophisticated worms like Stuxnet would be much harder with strict W^X for example, since CVE-2010-2568 and the like would be much harder to execute.
It has to do that anyway?
Only if it wants to allow Writable Memory to become Executable, or basically, allow JIT.
How do you propose preventing that without a check?
Signed binaries with the proper assigned OS capabilities.
Yes, but with JIT, you can't really verify what the application does upfront. That is the entire point.
Capabilities are a way to control that, and the point being that only responsible proven applications get the certificate, hence how it all goes on iOS.
You're making the assumption that "responsible" is something provable, but that is not the case, it is specially not easy to prove software is secure from tampering its behaviour.
For that there is bytecode verification as intermediate step, and if you want to go crazy with security, hardware memory tagging with capabilities.
Which at this point most companies would rather save money and forbid JIT altogether.
Note that mainframes and micros have JIT environments that aren't at the same safety level as regular desktop PCs.
For example,
https://medium.com/@dhemanthc/ibm-i-architecture-how-timi-an...
Nonsense, there's no "system wide implications". Mappings are per process, and W^X is just a strategy to help harden individual processes, not the entire system. There's no herd immunity here.
JITs do not grant the ability to bypass any OS/system sandboxes. The lack of W^X doesn't do that, either. If a process opts out of W^X, such as to enable a JIT, it's voluntarily making itself less hardened, but at the end of the day this isn't any more meaningful than the program being allowed to be written in, say, C, which also voluntarily reduces the processes security hardening.
You don’t understand OP’s point because you’re assuming vulnerabilities don’t exist. That is utter nonsense.
No, you're not understanding mine. Nobody builds an OS/system expecting that every executable is perfectly well behaved with zero bugs and zero ill intent. Applications are allowed to run code. JITs just run code in that same process. They are already limited to what the process was already allowed to do in the first place.
And my point about C is literally that even without a JIT, applications can still have arbitrary execution vulnerabilities.
A JIT intended to run untrusted code as part of a sandbox, like a browser, is a big risk. But that's because of the untrusted code part, not the JIT. By comparison, something like a Python or Java JIT is as near as makes no difference completely risk free. The JIT is working on exclusively "trusted" code. Same basic concept applies here with this database usage.
Only on operating systems that allow dynamic executable code.
ROP https://en.wikipedia.org/wiki/Return-oriented_programming
The page lists a long list of defences.
Yes, but your claim is that applications can still have arbitrary execution vulnerabilities only on operating systems that allow dynamic executable code.
I am refuting that statement by showing that not allowing dynamic executable code is not enough. It is irrelevant to that end that you can mitigate ROP by other means.
If a process is allowed to execute code, it's always allowed to execute arbitrary code as well. Those two are fully intertwined, be it via dynamic executable code, ROP chains, because it has an interpreter, or because the initial binary itself already is the malicious payload in the first place.
To the OS those are all identical scenarios, it's irrelevant what caused the arbitrary code execution to happen.