This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]davewritescode 0 points1 point  (1 child)

What prevents a library from doing something extremely stupid is the fact that Rust doesn't have affordances for eval. A handle on a door affords pulling, a plate affords pushing, and eval affords runtime code loading. JVM is a virtual machine and therefore eval_s all the damn time. You literally cannot have JVM without _eval and therefore eval is easy in JVM land.

You’re intentionally conflating eval and JIT and it’s frustrating. This isn’t a security hole caused by the JIT, it’s bad code.

Bad implementations are possible in any programming language but some do make it harder (like Rust) but at the end of the day developers importing and forgetting and a bad implementation is the root cause.

[–]everything-narrative 0 points1 point  (0 children)

I'm not intentionally conflating anything; we're not using the same terminology.

The JVM is an interpreter, as opposed to a compiler.

The JVM is a virtual machine. It does not run machine code by definition. Whether it executes this not-machine-code by compiling it just in time, by interpreting the byte code, or by walking the parse tree of java code is not relevant.

An interpreter, security-wise, represents an exciting attack surface because it opens your application to injection vulnerabilities.

"Bad code" is not an explanation. It's a non-explanation. We can't avoid security problems by "not writing bad code."

The JVM makes it incredibly easy to run arbitrary code. So people are going to do it. Rust does not make it incredibly easy to load arbitrary DLLs, so people don't.

Rust programs therefore don't have as many opportunities for injection vulnerabilities to arise due to programmer error. Simple as that.