2 ms·
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 poin
by tinco 10y ago
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.
- teacup50 10y agoThere 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.)