Post AMGegontk1U6m7fzI8 by lunch@cybre.space
 (DIR) More posts by lunch@cybre.space
 (DIR) Post #AMGe8Hpdp7jafX1eGO by avalos@mstdn.social
       2022-08-07T00:14:01Z
       
       0 likes, 0 repeats
       
       JIT or not, there are ABSOLUTELY NO differences whatsoever in terms of security. None at all. Literally the same.In JIT'd code, security lies on the compiler. The compiler must perform checks in the compiled code to make sure it doesn't access what's not supposed to.In interpreted code, security lies on the interpreter/runtime, to isolate code execution and make sure the sandbox restrictions apply.Security always relies on the implementation. Both JIT and interpreters have the same attack surface, and are generally insecure. Disable scripting if you really want more security. Thanks for coming to my TED talk.(Correct me if I'm wrong.)
       
 (DIR) Post #AMGegontk1U6m7fzI8 by lunch@cybre.space
       2022-08-07T00:20:13Z
       
       0 likes, 0 repeats
       
       @avalos I'd argue the potential for fuckups is worse for jitsif you write an interpreter in python and avoid edgy hacks it's pretty unlikely you'll accidentally allow buffer overflows or pointer type confusion that the code you're running will be able to abuse and escape its sandbox
       
 (DIR) Post #AMGewx1GxmMitBcmyO by avalos@mstdn.social
       2022-08-07T00:23:12Z
       
       0 likes, 0 repeats
       
       @lunch Except that most interpreters aren't written in Python, but in C++, which gives a lot of room for fuckups in the runtime.
       
 (DIR) Post #AMGj55v0A2YscbpWXA by niconiconi@cybre.space
       2022-08-07T01:09:26Z
       
       0 likes, 0 repeats
       
       @avalos When everything else fails and your have a vulnerable engine, memory safety mitigations by the OS would be the last line of defense - NX/W^X/PaX, ASLR (and more recently, CFI, by the compiler). While bypassing is often possible, but they still convert a trivially exploitable bug to a difficult one. For example, the most extremely form NX disallows the allocation of W+X memory under any circumstance, making code injection challenging (originally in PaX, but now systemd also has MemoryDenyWriteExecute, implemented via seccomp).When dynamic code generation is allowed due to JIT, these standard mitigations are either disabled or becomes largely useless, with many common techniques to exploit JIT's RWX memory, throwing away the lowest bar of memory safety by today's standard.Thus, with the same memory corruption bug, a JIT-enabled runtime is easier to exploit than a pure interpreted runtime (Though, disabling scripting is always better than disabling JIT).
       
 (DIR) Post #AMGj7r4pnV23SckI6K by niconiconi@cybre.space
       2022-08-07T01:09:59Z
       
       0 likes, 0 repeats
       
       @avalos When everything else fails and your have a vulnerable engine, memory safety mitigations by the OS would be the last line of defense - NX/W^X/PaX, ASLR (and more recently, CFI, by the compiler). While bypassing is often possible, but they still convert a trivially exploitable bug to a difficult one. For example, the most extremely form of NX disallows the allocation of W+X memory under any circumstance, making code injection challenging (originally in PaX, but now systemd also has MemoryDenyWriteExecute, implemented via seccomp).When dynamic code generation is allowed due to JIT, these standard mitigations are either disabled or becomes largely useless, with many common techniques to exploit JIT's RWX memory, throwing away the lowest bar of memory safety by today's standard.Thus, with the same memory corruption bug, a JIT-enabled runtime is easier to exploit than a pure interpreted runtime (Though, disabling scripting is always better than disabling JIT).
       
 (DIR) Post #AMGjcjJugeMKNeWMKm by niconiconi@cybre.space
       2022-08-07T01:15:33Z
       
       1 likes, 0 repeats
       
       @avalos When everything else fails and your have a vulnerable engine, memory safety mitigations by the OS would be the last line of defense - NX/W^X/PaX, ASLR (and more recently, CFI, by the compiler). While bypassing is often possible, but they still convert a trivially exploitable bug to a difficult one. For example, the most extremely form of NX disallows the allocation of W+X memory under any circumstance, making code injection challenging (originally in PaX, but now systemd also has MemoryDenyWriteExecute, implemented via seccomp).When dynamic code generation is allowed due to JIT, these standard mitigations are either disabled or becomes largely useless, throwing away the lowest bar of memory safety by today's standard. In some cases, making even non-JIT vulnerabilities more exploitable since W^X is switched off.Thus, a vulnerable JIT-enabled runtime is easier to exploit than a vulnerable, pure interpreted runtime (Though, disabling scripting is always better than disabling JIT).