Is standard Java immune to memcpy security flaws like the recent open ssl heartbeat flaw? [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 9 years ago.

Improve this question

Recently, the library openssl has been revealed to have a serious flaw that enables attackers to read up to 64KB of memory.

http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html

The cause seems to be due to the use of memcpy and not cross checking the size of the input provided by the attacker.

If we assume standard libraries (not calling out to C), is Java immune to these types of security flaws?

To be more specific about type of security flaw, I'm not referring to trusting user input, but specifically bounded memory access.

Answer 1

Java is safer, because it doesn't use pointer arithmetic, does bounds checking, and doesn't (normally) allow one to access arbitrary chunks of memory (see sun.misc.Unsafe !).

However, similar problems could arise, in principle, if one reads and writes bytes from an array, ByteBuffer, etc according to offsets provided by an untrusted client. The problem is much reduced, because one can only attack data within the bounds of that array (or similar container) rather than data in arbitrary adjacent objects.

Even with Unsafe, one would typically be, uh, Safe, because one tends to use it for allocating and accessing a very specific set of performance-critical objects, rather than the entire application (including encryption keys, passwords, etc).

The fundamental problem is trusting user input, and that can happen in any language, and a whole variety of contexts, e.g. SQL injection.