Java 6 update 17 is out.
Looks like Sun 1up'd the ClassLoader class's protection against the Finalizer Attack.
For more information on the finalizer attack: Sun Secure Coding Guidelines v2.0 Chapter 4-2
The old ClassLoader implementation used the tactic described in the secure coding guidelines. It allows the attacker to create an instance of the class, which is not fully initialized. However a boolean flag field renders the object unusable, as all significant operations check the flag.
Apparently that's not good enough anymore.
The new version of the ClassLoader has a protect constructor (actually 2, but let's look at the one that corresponds to the one in the secure coding guidelines):
225 protected ClassLoader() {
226 this(checkCreateClassLoader(), getSystemClassLoader());
227 }
Which calls the static method checkCreateClassLoader:
175 private static Void checkCreateClassLoader() {
176 SecurityManager security = System.getSecurityManager();
177 if(security != null) {
178 security.checkCreateClassLoader();
179 }
180 return null;
181 }
So if the SecurityManager doesn't allow a SecurityException gets thrown even before the superclass (Object) constructor is called, and thus there will be no object reference to "steal" in the finalizer.
Interesting. Wonder if they'll update the Secure Coding Guidelines as well.
A few thoughts on Fuchsia security
3 years ago
2 comments:
Hey Sami,
It been a while since this blog post but have you ever come across any class (other than the ClassLoader) that uses this new technique?
Hi,
No, I haven't seen it anywhere other than the ClassLoader class. The Sun/Oracle Secure Coding Guidelines for Java has been updated since, but it only speaks of using a "initialized" flag that's set in a constructor and then verified when doing something sensitive.
Post a Comment