6 ms·

I would suggest that the security issues in Java are due to bugs in the various JVM implementations, which are likely written in C, right? Not to say that Java

I would suggest that the security issues in Java are due to bugs in the various JVM implementations, which are likely written in C, right? Not to say that Java is going to eliminate all bugs. However, it should eliminate all bugs to do with, e.g., reading/writing out of the bounds of an array and resulting in RCE due to bugs introduced in the application code. Reading/writing out of the bounds of an array will still be a bug, but not one that allows arbitrary code execution (at least not in the same way as it may for a language like C.

MichaelGG 12y ago
And many of them, from a quick glance, are actually due to complicated sandboxing policies. That is, RCE was an explicit feature, but they found it hard to get right. In fact, one of the first real security holes I've ever found was in 1.0 version of the CLR. You could load a function pointer to an un-JIT'd function, then later on use that to safely jump to other code. This is technically a RCE, but the user has to be executing your code first anyways. That is, if the CLR and Java didn't set out to run "partially trusted" code with no help from the OS, these wouldn't have been problems at all. Other languages like C, Ruby, etc. simply don't have this "partially trusted" concept so there's nothing to attack. (Well I guess things like Native Client or VMware qualify, but they're at a better abstraction later than JVM or CLR permissions.)
- seanmcdirmid 12y ago
  When I was an undergrad at UW, I engineered a vacuum bug that took advantage of a JDK1.1 bug in constant pool verification to suck out the user's in memory environment configuration (so like PATH variables and such). http://www.cs.cornell.edu/People/egs/kimera/flaws/vacuum/ http://www.cs.cornell.edu/People/egs/kimera/flaws/vacuum/ But most security holes these days are not flaws in the JVM/CLR, but logical errors made in the application; e.g. allocate a buffer and reuse it, this says nothing about memory safety at the VM level at all! And at that, no one really trusts JVM security anymore, preferring to sandbox the entire operating environment in a heavyweight or lightweight VM.
  - MichaelGG 12y ago
    Neat! In 2003 I was writing an obfuscator for .NET, leading me to explore quite a bit. It was fun. But app level bugs aren't what gives Java a bad name, are they? When someone says, like the GP, that "what about Java, that's got tons of security issues", that's almost certainly from its use as a browser plugin. Otherwise everyone would be saying the same about every language out there.
    - seanmcdirmid 12y ago
      We found lots of bugs in Microsoft's Java implementation at the time; they offered us lots of money for our test suite but Brian wanted to do a startup :) Anyways, if you want to break something, you can usually get there with fuzz testing (but these days, most sane organizations will fuzz themselves). Ya, when people say Java is insecure, they usually mean the Java plugin has insecure interfaces. As the browser + Java becomes increasingly rare, it fades from our memory. There is nothing insecure or secure about the language, memory safety actually works...but its only one small part in having a secure environment. I worry about Rust, it pushes the safety card much more aggressively, but in reality without full on aggressive dependent typing, they'll only be able to guarantee a few basic properties. The language won't magically make your code "secure", just a bit easier to secure.
      - pcwalton 12y ago
        > I worry about Rust, it pushes the safety card much more aggressively, but in reality without full on aggressive dependent typing, they'll only be able to guarantee a few basic properties. Our analysis of the security benefit of Rust comes from two very simple, empirical facts: 1. Apps written in memory-safe languages do not have nearly the same numbers of memory safety bugs (use after free, heap overflow, etc.) as apps written in C and C++ do. 2. Memory safety issues make up the largest number of critical RCE bugs in browser engines. > The language won't magically make your code "secure", just a bit easier to secure. Of course it won't magically make your code secure. Applications written in Rust will have security vulnerabilities, some of them critical. But I'm at a loss as to how you can claim that getting rid of all the use-after-free bugs (just to name one class) inside a multi-million-line browser engine in a language with manual memory management is easy. Nobody has ever succeeded at it, despite over a decade of sustained engineering effort on multiple browser engines.
tedunangst 12y ago
Many of the Java security bugs are in Java code. Relevant to this discussion, "Jetbleed". The many other SSL breaks in Java. A variety of issues involving deserialization of untrusted data, ala Rails yaml bug. Bugs in the JVM itself are more the exception than the rule.
- diroussel 12y ago
  What is jetbleed? Searching google for it brings me back to your comment!
  - diroussel 12y ago
    Ah it, was called JetLeak -- http://blog.gdssecurity.com/labs/2015/2/25/jetleak-vulnerability-remote-leakage-of-shared-buffers-in-je.html http://blog.gdssecurity.com/labs/2015/2/25/jetleak-vulnerabi...

MichaelGG 12y ago

And many of them, from a quick glance, are actually due to complicated sandboxing policies. That is, RCE was an explicit feature, but they found it hard to get right. In fact, one of the first real security holes I've ever found was in 1.0 version of the CLR. You could load a function pointer to an un-JIT'd function, then later on use that to safely jump to other code. This is technically a RCE, but the user has to be executing your code first anyways. That is, if the CLR and Java didn't set out to run "partially trusted" code with no help from the OS, these wouldn't have been problems at all. Other languages like C, Ruby, etc. simply don't have this "partially trusted" concept so there's nothing to attack. (Well I guess things like Native Client or VMware qualify, but they're at a better abstraction later than JVM or CLR permissions.)

seanmcdirmid 12y ago
When I was an undergrad at UW, I engineered a vacuum bug that took advantage of a JDK1.1 bug in constant pool verification to suck out the user's in memory environment configuration (so like PATH variables and such). http://www.cs.cornell.edu/People/egs/kimera/flaws/vacuum/ http://www.cs.cornell.edu/People/egs/kimera/flaws/vacuum/ But most security holes these days are not flaws in the JVM/CLR, but logical errors made in the application; e.g. allocate a buffer and reuse it, this says nothing about memory safety at the VM level at all! And at that, no one really trusts JVM security anymore, preferring to sandbox the entire operating environment in a heavyweight or lightweight VM.
- MichaelGG 12y ago
  Neat! In 2003 I was writing an obfuscator for .NET, leading me to explore quite a bit. It was fun. But app level bugs aren't what gives Java a bad name, are they? When someone says, like the GP, that "what about Java, that's got tons of security issues", that's almost certainly from its use as a browser plugin. Otherwise everyone would be saying the same about every language out there.
  - seanmcdirmid 12y ago
    We found lots of bugs in Microsoft's Java implementation at the time; they offered us lots of money for our test suite but Brian wanted to do a startup :) Anyways, if you want to break something, you can usually get there with fuzz testing (but these days, most sane organizations will fuzz themselves). Ya, when people say Java is insecure, they usually mean the Java plugin has insecure interfaces. As the browser + Java becomes increasingly rare, it fades from our memory. There is nothing insecure or secure about the language, memory safety actually works...but its only one small part in having a secure environment. I worry about Rust, it pushes the safety card much more aggressively, but in reality without full on aggressive dependent typing, they'll only be able to guarantee a few basic properties. The language won't magically make your code "secure", just a bit easier to secure.
    - pcwalton 12y ago
      > I worry about Rust, it pushes the safety card much more aggressively, but in reality without full on aggressive dependent typing, they'll only be able to guarantee a few basic properties. Our analysis of the security benefit of Rust comes from two very simple, empirical facts: 1. Apps written in memory-safe languages do not have nearly the same numbers of memory safety bugs (use after free, heap overflow, etc.) as apps written in C and C++ do. 2. Memory safety issues make up the largest number of critical RCE bugs in browser engines. > The language won't magically make your code "secure", just a bit easier to secure. Of course it won't magically make your code secure. Applications written in Rust will have security vulnerabilities, some of them critical. But I'm at a loss as to how you can claim that getting rid of all the use-after-free bugs (just to name one class) inside a multi-million-line browser engine in a language with manual memory management is easy. Nobody has ever succeeded at it, despite over a decade of sustained engineering effort on multiple browser engines.

tedunangst 12y ago

Many of the Java security bugs are in Java code. Relevant to this discussion, "Jetbleed". The many other SSL breaks in Java. A variety of issues involving deserialization of untrusted data, ala Rails yaml bug. Bugs in the JVM itself are more the exception than the rule.

diroussel 12y ago
What is jetbleed? Searching google for it brings me back to your comment!
- diroussel 12y ago
  Ah it, was called JetLeak -- http://blog.gdssecurity.com/labs/2015/2/25/jetleak-vulnerability-remote-leakage-of-shared-buffers-in-je.html http://blog.gdssecurity.com/labs/2015/2/25/jetleak-vulnerabi...