How can Heap Pollution cause a security flaw

Question

I came across this rule in the CERT Secure Coding Standart for Java. Heap Pollution. I understand this can cause the programm throwing an exception at runtime, but i can't understand how this could cause a security issue like dos or something. Could someone explain a scenario where an attacker could exploit a heap pollution?

Answer 1

An attacker would need to be able to create an arbitrary object. If you expose Java Serialization for example this is possible. You can construct object from Java Serialization which wouldn't be valid in term sof generic and can thus cause exceptions to occur.

However, there are more serious problem to worry about such as deserializing objects which could execute code in ways that were not intended. Unfortunately some common libraries allow this. e.g. http://www.darkreading.com/informationweek-home/why-the-java-deserialization-bug-is-a-big-deal/d/d-id/1323237

Answer 2

In theory parameterised types could be accepted by trusted code from untrusted source (could be through serialisation, but also just untrusted code). In theory values passed indirectly could behave differently when called with methods on a common supertype (notable toString (may have unexpected escape characters or may change value) and equals (may lie or a malicious implementation may alter the argument object)).

In practice this does not happen. The Java library parameterised types are generally untrustworthy themselves. Trustable parameterised types of untrusted objects are uncommon, and where they are used there is typically an implicit checked cast even when using methods from Object.