7 ms·
JIT compilation is unsecure.
by roschdal 25d ago
JIT compilation is unsecure.
- dennis16384 25d agoIt is the core of ClickHouse for example, for many years. Is it secure enough in your opinion?
- sebzim4500 25d agoMaybe, but surely there are users who are willing to trust all users of their db instance.
- asdfsa32 25d agoThe 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 https://en.wikipedia.org/wiki/W%5EX
- PhilipRoman 25d agoW^X is typically per mapping, not per memory page and does not interfere with JIT compilation.
- asdfsa32 24d agoSure, 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.
- orf 24d ago> Sure, but it still means that the OS has to decide who is allowed to do it and to what extent It has to do that anyway?
- pjmlp 24d agoSigned binaries with the proper assigned OS capabilities.
- asdfsa32 24d agoYes, but with JIT, you can't really verify what the application does upfront. That is the entire point.
- deleted 24d ago[deleted]
- pjmlp 24d agoCapabilities 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.
- asdfsa32 24d agoYou'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.
- pjmlp 24d agoFor 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-and-slic-enable-hardware-independence-82aea3f2dae3 https://medium.com/@dhemanthc/ibm-i-architecture-how-timi-an...
- kllrnohj 24d agoNonsense, 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.
- asdf88990 24d agoYou don’t understand OP’s point because you’re assuming vulnerabilities don’t exist. That is utter nonsense.
- kllrnohj 24d agoNo, 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.
- asdfsa32 25d agoYou're entirely correct because JIT requires violating Write xor Execute security policy. This is the reason on iOS, it is limited to Apple shipped software. https://en.wikipedia.org/wiki/W%5EX https://en.wikipedia.org/wiki/W%5EX
- shakna 25d agoThe wiki page mentions this is only a minor problem. Because everyone just writes, then switches and executes.
- codethief 24d agoGrapheneOS heavily restricts JIT usage, too: > - Android Runtime Just-In-Time (JIT) compilation/profiling is fully disabled and replaced with full ahead-of-time (AOT) compilation. The only JIT compilation in the base OS is the V8 JavaScript JIT which is disabled by default for the Vanadium browser with per-site exception support. > - Dynamic code loading for both native code or Java/Kotlin classes is blocked for nearly the entire base OS. […] > - Dynamic code loading for both native code or Java/Kotlin classes can be disabled for user installed apps via 3 exploit protection toggles: […] https://grapheneos.org/features https://grapheneos.org/features
- norir 24d agoAs someone who has written a jit compiler, I am puzzled by the claim that jitting requires write/execute permissions. When I have written a jit, I loaded some memory with read/write permissions using mmap. Once I filled in the generated code, I mprotected the region to read/execute before executing. The drawback to this approach is there can be some bloat because you can only mprotect at page granulariy so a jitted function that only takes say 10 bytes to represent would take up a full page in memory, but this is extreme and in practice, the overhead is unlikely to be worth worrying about.
- JackSlateur 24d agoIn rust, is jit equivalent to an "unsafe" block ?
- pjmlp 24d agoMachine code is insecure, we should all run interpreted code in a formally verified interpreter. Alternatively, only allow for the execution of cryptographly signed static linked binaries, this naturally includes the interpreter above.
- genxy 24d agoIf we are sprinkling formal verification on things, we can sprinkle it on a JIT.
- bastawhiz 24d agoBut then we'd have to admit that it's not the JIT that's a problem, it's the lack of guardrails and analysis features in the machine code interfaces that higher level languages expose!
- pjmlp 24d agoOnly if it goes through verified bytecode, and the set of instructions is provable. The JIT must also only be allowed to call into specific code, controlled by the runtime, and nothing else.
- stevefan1999 24d agoSo what, are you willing to go away from von-neumann architecture where instructions are data and data are instructions, i.e. the instruction-data hominocity that underpins JIT compilation? Are you willing to go to a pseudo-Harvard architecture where the ability of JIT compiling is soft locked by other means like VM or strong code authentication or policy protection, which is what Apple is doing. Fun fact: even Apple themselves have JIT. JavaScriptCore on iOS has JIT, it's just that the App Store policies forbid any application submissions with JIT or trying to mmap/mprotect an executable region. There used to be apps on TrollStore that runs JIT
- stevefan1999 23d agoTypo: it is Homoiconicity, not hominocity. I typed too fast
- kllrnohj 24d agoNo, it isn't. JITs don't grant capabilities abilities an equivalent interpreter doesn't already have. Allowing code execution allows code execution, that's it, that's the entirety of it.
- Ohentis 24d ago[dead]
- MaxBarraclough 24d agoThere's more to it than that though. Defects in JIT logic can lead to nasty low-level bugs. Plain old interpreters, especially if written in a safe language, are unlikely to have similar issues. This is important when the input code is untrusted. JIT bugs are a major source of browser vulnerabilities.
- kllrnohj 24d agoJITs are an attack surface in that process. They are still restricted to things that process was already allowed to do, no matter how badly implemented the JIT is. In this example usage, one would hope that authentication already happened before the JIT processed the command. So an authorized user can attack themselves is the only realistic risk, which is hardly significant
- MaxBarraclough 24d ago> JITs are an attack surface in that process There's plenty of scope for harm just within the process, even ignoring the possibility of escaping the process. In the case of a database server, essentially everything of value takes place within the database process (or processes). That process presumably has both access to the raw database data, and network access. We wouldn't want it sending data to an attacker's server. > one would hope that authentication already happened before the JIT processed the command We'd hope, yes, but SQL injection issues are still somewhat common. Also, an organisation might trust their DBMS to enforce permissions, and a JIT bug is the kind of thing that might allow non-permissioned data access. A DBMS should be hardened against malicious queries, just as a browser should be hardened against malicious JavaScript. In web browsers, the numbers show JIT compilers are a major cause of security issues. I don't know if there are hard numbers on JIT engines causing security issues in DBMSs though.