| Wiki Markup |
|---|
Client code can trivially access {{public}} {{static}} non-final fields. Neither reads nor writes are checked by a security manager; further, newly setnew values cannot be validated programmatically before they are stored in the field. Classes loaded by the same or different class loaders can access each others' {{public static}} members; further, unless appropriate protection is installed code from any class can access {{public}} members of any classes loaded by class loaders in the delegation chain of the current class's class loader. For example, consider Java applets \[[Sun 2008|AA. Bibliography#Sun 08]\]: |
...
Replacing the function table gives the attacker access to the XPathContext. The XPathContext is used to set the reference node for evaluating XPath expressions. Manipulating it can allow XML fields to be modified in inconsistent ways, resulting in unexpected behavior. Also, because static variables are global across the Java Runtime Environment (JRE), they can be used as a covert communication channel between different application domains (for example, through code loaded by different class loaders).
Note that this vulnerability was repaired in JDK v1.4.2_06 (or whatever).
Compliant Solution
This compliant solution declares the FuncLoader static field final and treats it like a constant.
...