Hacker News Reader

Comment by pcwalton | Hacker News Reader

> But as we all know Java has been riddled with code execution bugs.

Most of those are of the form "malicious code delivered as Java applet can break out of the JVM sandbox". That is, they crucially rely on running untrusted code. By contrast, the threat model here involves attackers subverting existing, trusted code. Memory safety holes in Rust overwhelmingly rely on bizarre carefully crafted code that nobody would accidentally write.

There are some exceptions: Java is affected by serialization issues along the lines of the Rails YAML vulnerability, for instance. But most of those don't apply to Rust either for various reasons.

View on HN

Another source of Java bugs is improper input sanitation when untrusted input eventually feed into various interpreters like embedded JavaScript or SQL. That, of cause, can happen with any language, but at least with Rust it is much harder to accidentally call into some framework that exposes an interpreter capable of arbitrary code execution.

True enough, definitely with untrusted code your surface is that much larger. What I remember from the few JVM bugs I looked at is that they were always at points where the JVM would call into the operating system or otherwise interact with native code. I would imagine Rust code might be vulnerable at those same points, though obviously much less easily.

There are basically three major classes of Java code execution bugs:

1) Bugs in native code (generally image processing, compression, etc). This code tends to be derived from existing libraries, and so shares common vulnerabilities.

2) Bugs in sandboxing when running untrusted code. Java's sandbox model is fundamentally flawed and I don't believe it can ever be secured.

3) Executing untrusted external user input within the JVM context, e.g., by evaluating external data using your internal scripting language that has access to the JVM or relies on JVM sandboxing.

Of those:

1) Not much you can do, but issues are relatively rare.

2) Can be avoided by not running untrusted code in a JVM-enforced sandbox (applets are dead, sorry).

3) You'll be fine if you steer clear of libraries that even go near eval() of untrusted user input. The culprits here are serial offenders due to architectural/design issues, and are easy to avoid (e.g. Apache Struts.)

Reply on news.ycombinator.com