3 ms·

If Java memory safety is so good, why does NullPointerException still exist in the language?

pcwalton 11y ago
I'm not talking about NPE (though I would be happy to elaborate on how not having null pointers also reduces crashes in the wild). I'm talking about exploitable and/or non-type-safe memory safety problems. Writing in Java is an effective way to reduce remote code execution vulnerabilities over writing in C. Statistics have shown this over and over again.
- hyc_symas 11y ago
  The very fact that NPE exists, in a language which doesn't have pointers, running on a JVM that doesn't have pointers, is evidence that the entire model of "doesn't have pointers" is a sham. The reality of computer architecture is that data resides in memory, memory is an array of bytes, and bytes have addresses (i.e., pointers) and denying this fact is impossible. Even in a pure pointerless system like Java. And if there are pointers in the system, somewhere, anywhere, they are exploitable. Remote code execution vulnerabilities in C are less a feature of the language syntax and mostly due to the abysmally poor C library, which is regrettably part of "C The Language" - but no one forces you to use it - there are better libraries. Also, it's an artifact of implementation - just as Java's supposed immunity is an artifact of implementation, not an inherent feature of the language syntax. Case in point http://www.trendmicro.com/vinfo/us/threat-encyclopedia/vulnerability/7033/oracle-java-se-remote-code-execution-vulnerability-cve20152590 http://www.trendmicro.com/vinfo/us/threat-encyclopedia/vulne... As for RCEs in C code - these would be easily avoided if the implementation used two separate stacks - one for function parameters, and one for return addresses. If user code can only overwrite passive data, stack smashing attacks would be totally ineffective. Again - there's nothing in the C language specification that dictates or defines this particular vulnerability. It is solely an internal implementation decision.
  - pjmlp 11y ago
    References are pointers.
  - pcwalton 11y ago
    > As for RCEs in C code - these would be easily avoided if the implementation used two separate stacks - one for function parameters, and one for return addresses. No. Increasingly, RCEs are due to vtable confusion resulting from use after free.
    - hyc_symas 11y ago
      Sounds like you're the one with confusion; vtables are not a feature of C. C++, sure, but that's a different conversation. Your point is invalid.

I'm not talking about NPE (though I would be happy to elaborate on how not having null pointers also reduces crashes in the wild). I'm talking about exploitable and/or non-type-safe memory safety problems. Writing in Java is an effective way to reduce remote code execution vulnerabilities over writing in C. Statistics have shown this over and over again.

hyc_symas 11y ago
The very fact that NPE exists, in a language which doesn't have pointers, running on a JVM that doesn't have pointers, is evidence that the entire model of "doesn't have pointers" is a sham. The reality of computer architecture is that data resides in memory, memory is an array of bytes, and bytes have addresses (i.e., pointers) and denying this fact is impossible. Even in a pure pointerless system like Java. And if there are pointers in the system, somewhere, anywhere, they are exploitable. Remote code execution vulnerabilities in C are less a feature of the language syntax and mostly due to the abysmally poor C library, which is regrettably part of "C The Language" - but no one forces you to use it - there are better libraries. Also, it's an artifact of implementation - just as Java's supposed immunity is an artifact of implementation, not an inherent feature of the language syntax. Case in point http://www.trendmicro.com/vinfo/us/threat-encyclopedia/vulnerability/7033/oracle-java-se-remote-code-execution-vulnerability-cve20152590 http://www.trendmicro.com/vinfo/us/threat-encyclopedia/vulne... As for RCEs in C code - these would be easily avoided if the implementation used two separate stacks - one for function parameters, and one for return addresses. If user code can only overwrite passive data, stack smashing attacks would be totally ineffective. Again - there's nothing in the C language specification that dictates or defines this particular vulnerability. It is solely an internal implementation decision.
- pjmlp 11y ago
  References are pointers.
- pcwalton 11y ago
  > As for RCEs in C code - these would be easily avoided if the implementation used two separate stacks - one for function parameters, and one for return addresses. No. Increasingly, RCEs are due to vtable confusion resulting from use after free.
  - hyc_symas 11y ago
    Sounds like you're the one with confusion; vtables are not a feature of C. C++, sure, but that's a different conversation. Your point is invalid.